Vincent Slifer PPJ week 09 & Personal Post Mortem

This week was not the greatest, but not the worst week for me.  On a massive note, I got sick on Friday, which put me almost out of commission for Saturday and Sunday.  Other than getting sick, I was able to polish Popcorn Popper, Item Dodge, Ram the Planet, and Mechanized Warfare.  For Popcorn Popper, I added in the texture for the popcorn machine, increase the number of spawned popcorn to make it easier to fill the machine, as well as change the method that machine is simulated. In Item Dodge, I just change some colors to better fit the themes of the game and give the shooter a more recognizable model.  For Ram the Planet, I got rid of the power bar, as well as adding in assets to for the players to, more easily, recognize the speed that is supposed to be read.  For Mechanized Warfare, I changed the target selection so that the targets are now given a color overlay, rather than changing the material of the object itself.

New method for motion on Popcorn Popper

Ram the Planet

Positive Content

• Updated Popcorn Popper, Ram the Planet, Item Dodge, and Mechanized Warfare

Negative Content

• Was not able to get people to attend playtests
• Got sick

Work and Hours

Alterations (~2 hrs)
- Changed assets for Item Dodge to better read how the game plays
- Edited Ram the Planet so the sense of speed is better understood
- Made Popcorn Popper spawn more popcorn per button press for humans
- Edited Mechanized Warfare so textures show up before they are shot

Final Art Implementation (~1 hrs)
- Implemented final art for each game

Total Hours: 3 hrs

Personal Post Mortem
What went right
1. Iterative Design
A major part of the process for my games was the iterative design the games went through.  Planet Ram is the biggest example of this process.  Originally, the game allowed the players to move around in the space as they attempted to reach the goal.  This was found to be too difficult to both play and discern the goal of the game.  So, the game was changed so the players only had to just hold two buttons in order to win, reflecting on the original intent of the wacky nature the game was intended to have.

2. Influx of ideas
A major plus with a larger team was the new set of people that could provide in team feedback and ideas for the games.  For me, it was extremely helpful to have other members take an objective look at my own games, to provide concise feedback on what was originally envisioned versus what I had produced.

3. Cooperative Goals
A major element of successfully developing the game was that we were working together in each game.  What I mean is, each element of every game was designed to cohesively work together, to create a more consistent feel, rather than five different programmers designing separate games.

What went wrong
1. Playtesting
My own personal issue, I was not able to get people to playtest the game.  I was unable to get people to play the game on a local machine due to the fact I only have one controller, and I was unable to get people to go to the Drexel Ride in order to test it on the motion base.  This is more reflective on how I do not press people to go out of their way to do tasks that other people do not know if it would be fun or not.

2. Communication
This term, I was not as communicative as I previously was with others on the Slack.  I was more attentive of the slack, but I was more hesitant to actually communicate with others.  Again, this is more reflective of my hesitance to reach out to others and worrying about bothering others when they have their own work to do.  I did reach out to others when I absolutely needed someone else to complete a task, but otherwise, I tried to accomplish it myself to the best of my abilities.

3. Initial Team Growth
The start of the term was a little rocky, with the initial team growth.  We intended to continue with how we were operating from the previous term, but we quickly realized that with so many people, it was apparent that we would not be able to meet in person on Sunday.  There was also a major influx of catching people, from the other team, up to what and how team was doing things.  These issues, however, were not that troublesome because the teams, fairly quickly, assimilated into one.

Lessons Learned

• Work cooperatively
• Ideas and feedback from anyone is a must
• Take a critical look at everything
• Adjust to keep everything consistent

Cory Zicolella, Week 9 PPJ, Blog Post 9

Garnering Playtest Data - 5 hours
Editing Playtest - 1.5 hours

This week was pretty standalone from any other for me.  While I usually do many other extraneous things, this week was focused simply on getting all of the playtests we needed since we had to have 44, and we didn't get much testing on the motionbase this term.  A secondary objective I had was to get more footage for the video so I could edit it this week; while I did get the footage, the labs were full when I was available so I couldn't make the necessary edits.

Getting the playtest data was mostly done on the Wednesday group playtest where I spent 4 hours, and on the following monday where we reserved an hour to get even more.  I recorded testimonials of some people before and after their ride experience if they didn't mind being on camera.  I also had to edit the playtest for each of these sessions before they happened to make sure they were good (and in some cases, to streamline it).

That was all I really did this week.

Total Time Spent: 6.5 Hours

This is a personal post mortem, and as such I will be measuring my work I did against my team as a whole.  I personally think I was a great asset to Alien Arcade; I was part of the original team a term ago and my placement as a sound/idea person carried through to this term as well.  Of course I did other things such as modeling as well, but my main placement seems to have been unofficially in the sound & video department, and idea creation.  This all being said, there was definitely good and bad that came with this project.  I',m happy I got the chance to work on it, but given another opportunity, there are somethings I would change.

What went right?
1. Reporting to the team.
I always made sure I would report back to someone if anything I did was finished (along with a direct path to that thing), or if anything somehow was an issue.  This really helped the team I felt because I was capable of doing more than I thought (if I told someone I didn't have much to do), and the team also knew exactly what I had been working on, and when it was finished.  Some people didn't do this as well as me I feel, and certain games may have slipped slightly because of it--they were always fixed, but usually never arrived to class in the state they should have been in.

2. Democracy
It is a weird label, but honestly I have no other clue what to call it (maybe team synergy).  Whenever I had an idea regarding a game, or an issue I had with an existing facet of one, or even a trailer decision, I ran it by the team.  This made it so everyone was aware of whatever idea/issue I had, but it also made it fair as to what we should do with it.  This essentially made everything a team decision, which I feel is really important for morale; everyone feels as if they have a say and in the end as if something important was credited to them.  This occurred often when brainstorming new ideas (this method of thinking eventually led to Draw at Noon) or during what I call 'issue meets' where we go through every game and list what is wrong (this is how we agreed to handle certain bugs).

3. Documentation
Personally, I didn't do a lot regarding this, but I think the amount that I did certainly helped the team largely and made the necessary processes faster.  When i gathered all of the sound effects for use in Alien Arcade, I made sure to document all relevant copyright information as well as a brief description as to what the ound actually is.  This made it extremely easy for David to add this into the GDD later as well as the credits of Alien Arcade; and it also helped everyone else who was trying to put music into the game.  Aside from this, my changelog submitted both to perforce and slack whenever I did something was very succinct and included exactly what went in and where each time, making finding those things easy.

What went wrong?
1. Timeliness
I am really bad personally when it comes to working in a timeframe, specifically because I work the best under pressure.  That being said, I always got things in on time and never really failed to do a task that I was assigned to do for the week.  I simply waited a long while or put the assignment on hold until the ladder end of the week to do other things in the meantime because that's how I've always worked.  It wasn;t necessarily a detriment to the team, it just forced me to change over time--I went from working mostly Monday or Tuesday on the project to starting to work on Saturday for it.  In some ways, this can be a positive thing; but it took 8 weeks to get there and I feel as if nothing but good would come from having me start and finish things earlier.

2. Not Getting Enough Playtests
Being in charge if playtests for Alien Arcade, this falls heavily into my hands I feel.  However, a few others and myself always mentioned playtests to people and we never seemed to meet our quota like we did from last therm (which is probably due to the huge influx of team members).  This means both on and off the motion base too; we managed to get many playtests our final week, but that was a desperation attempt because it was really required in order to fix bugs.  If we had more testers in general, and specifically more on the motion base, I feel like a large number of bugs we discovered could be fixed, and the motion could certainly have been tweaked already.  This was probably largely in part to there needing to be 3 people free, and 2 xbox controllers to even do a single playtest at all.

3. Time Estimation
This almost goes hand in hand with timeliness, but I'm setting it aside because this was a large reason why things were handed in later than expected as well.  This term in particular, I ran into many computer issues (both on my personal computer and on lab computers) that caused my various tasks to slow to a slog.  Whether it be the computer i was working on not having enough ram to handle a certain edit I made, or my computer deciding to randomly slow until I needed to do a system restore, or simply having something take longer than expected; time estimation always was an issue.

Lessons Learned:

• Reporting to the team allows everyone to know what's going on
• Team synergy is really important in a large group project for morale
• Documentation, no matter the form, will always help a process
• Working under pressure can be good, but in team projects it is not usually the best
• Playtests are extremely important to working out the flaws of a game
• It seems that estimating slightly more time than needed wouldn't hurt anything amidst all of the computer issues I ran into this term

Angela Buchanan, Week 9 PPJ, Blog Post 9, GMAP 378

2D art, interface, texturing

I focused on refining the interface more this week. This included cleaning up instructions, adding missing elements, and reflecting any changes.

A big challenge for me this week was finding a way to the score and timer bar stand out. I tried a few different methods until I decided to try adding gradients to the sides. While it was a very simply solution, I felt it worked most effectively. My other methods seemed too bulky and thick compared the smooth gradient. Additionally, the gradients can be placed on-top of the dash as well, making the dash environment look less flat.

I also made some art to fill the blank space on the slot machine. Originally, before the aliens had their own console, that space was going to be used for slot instructions. Now it's just for decorative purposes.

Positive Content   

-  I don't expect to have to any more tweaking unless absolutely necessary.

- Found a nice, simple solution to make the time and score bar stand out more 

Negative Content

- Didn't work as much on the sell as I would have liked to

Work and hours

Instruction screen update (1 hrs)

Just a general update to fix changed instructions, add any missing ones, and fix any errors in previous ones.

Time and score bar visability fix (1 hrs)

My first method used a faded pixelated shadow effect, but I felt this looked to clunky and clashed with other interface elements.

The gradient also adds a stronger sense of space to the dash, so I decided to stick with that solution.

Slot screen art (.5 hrs)

The process for this went smoothly.I looked at some slot machines for minor influences, aside from that it was a simple asset to make.

Sell Tweaking (.5 hr)

I tweaked the sell as much as could with the amount of time I had remaining. I expect to do more next week, but the game tweaks had a higher priority.

Total Hours: 3 hrs

Post Mortem

Things that went right

- Overcame interface design challenges (Making things visual and quicker to understand)

Working on the interface was my biggest task for this project. The game heavily relied on players being able to quickly pick up and adapt to the instructions. At the same time, we wanted players to clearly know their progress.

This was challenging due to the chaotic nature of our game. With so much going on, good design is important to make the interface stand out. I knew without a good interface, the game would not be playable.

Taking feedback and using some of my own ideas, I felt I was able to establish a strong interface that has made significant developments throughout the term. Aside from some text instruction, the majority of our interface is visual, making it easy for the player to quickly grasp information.

- Managing more people

Communication is my weakness, regardless I felt I was able to communication more effectively this term with both the programmers and the artists. I managed to keep relatively up-to-date with instruction changes through the term and during meetings I encouraged the programmers to voice any needs or requirements for particular assets. 

As for the artists, I provided feedback when possible and helped direct some design decisions.
When asked for advice, I responded quickly.

Additionally I made it clear where all assets could be found and included direct file paths to assets during my updates.

- Produced a lot of work

The interface alone required a lot of components, updates, and changes. Along with that there was the slot machine (Another big project of mine) and the icons. Both tasks required a lot of attention and updates and took the majority of my time.

Despite this, I still managed to complete other tasks. Generally texturing, but I also took care of some basic modeling.

Things that went wrong

- Miscommunication and organization (Lack of firm leadership skills)

I prefer to have heavy influence over projects I work on, therefore I tend to lean towards leadership roles when possible. However, I struggle with effective communication and organization (The state of my desktop folders and desk support this fact),

I do feel that this negatively impacts the project.I did take initiative and attempted to prompt discussion on the art side of things, but the clarity of my words and lack of firm voice does not draw much attention.

Additionally, I felt folders could have been better organized and I could have contributed more documentation that set down a specific workflow for artists. I plan on relying more on reference documents like this for future projects to help add direction where my voice cannot.

- Insufficient planning early on (Game concept art)

I have mixed feelings when it comes to concept art. At the beginning of the project it contributed a lot to setting the mood, however many ideas expressed in concept did not make it's way into the game. Concept art also requires a lot of work, which takes time away from asset production.

During this term, there was game-flow concepts, which I ended up not assigning further as I felt they were not useful. I felt there was a strong disconnect concept and what was actually produced (alternatively, I felt there was also disconnects from ideas stated and concept produced).

Instead, I stuck to a reactive approach for assigning tasks. However, I felt I still should have set some side time aside to plan out and predict art assets ahead of time. I did some this, but not to the extent that I should have.

- Difficulties distributing work

This is partially due to the insufficient planning and organization, but I had difficulties assigning tasks.
Better communication while game were being built would have allowed me to create a stronger asset list that could've been in place sooner.

Additionally, the skill and style differences of artists made it hard for me to make decisions regarding task distribution.

Honestly, I'm still lost on how to effectively manage skill and style differences of artists. When you're working with deadlines, it's hard to make decisions for when assets need to be redone. Especially when those assets take a lot of time.

Xavier Smith, Week 10 Journal PPJ, Blog post w, GMAP 378

Content with Hours:

           

            Playtests and crunch time! This week was the busiest yet, another game I’m working on, RGB went into crunch time, so I spent the weekend until early Tuesday working on bugfixes and integration for a beta. That being said, I still managed to get a few things done for Alien Arcade this week

            Firstly were the playtests; I organized with the other section’s Team Lumpy Labs to host a joint playtest for both of our games at the motion base. Due to a few miscommunications however, we weren’t able to get enough playtests done, and so I scheduled for another one (with a fair amount of help from Joe Cory and David!) to get more playtests and find motion base bugs (3 hrs)

            Secondly, I did a bit of sprucing up on our sell presentation to reflect our latest build, and added a few more slides and talking points (1 hr)

            Finally, I made a few quick fixes on bugs we found from the motion base and tried to make the instructions for a few of the games a bit more coherent (1 hr)    

Content Positive:

- Got a lot of feedback from the playtests

- Fixed a few minor bugs

Content Negative:

- Didn’t have much time to work on the project due to RGB

Total Time Spent: 5 Hours

Personal Post Mortem

            Overall, this project proved incredibly draining. Most of the team and I were able to keep up with the project in the beginning, however the constant barrage of documentation, playtest requirements, and pressure to polish and add content while still keeping up with other classes took its toll on the team. Towards the end of development things started becoming strained between a few members due to the stress but we still tried our best to put out a decent game.

            

 What Went Right

1. Teamwork
As our team grew, we realized early on that we would need to change the structure of our team hierarch. To that end, I retained position of project leader, with John leading the programming team, and Angela taking charge of the art team. This proved to be a more efficient structure, especially for the artists as members were always clear on to whom they needed to speak to in order to get a task complete or a feature/art implemented. This also helped to ensure we did not repeat the mistake of the last cycle whereby members were unclear as to who was supposed to complete certain tasks resulting in the same work being done more than once. 

2. Content Generation
Despite time constraints and a few extenuating circumstances, the team actually managed to create more content than expected for this cycle. Halfway through the term our goal was to finish the project with roughly 16-20 mini-games; however we managed to finish with 22! One of the main reasons for this was having a dedicated programmer for functionality this cycle. Last cycle, functionality was done mostly by David and I. As a result, their ability to complete games was slightly hampered, and bug-fixes would be solved inefficiently as both programmers would occasionally work on the same problem unbeknownst to them. For this cycle, functionality was left entirely to John, who managed to complete all his tasks and still have time to implement a mini-game or two.  Additionally, our larger team size allowed us to work on more mini-games simultaneously, naturally resulting in more games being created. 

3. Documentation
In the previous cycle, most of the documentation was handled by David. For this cycle however, we managed to get more people on documentation, and so much more documentation could be done on a more detailed level. Due to the democratic process in which work was split up, not only did we ensure that no one member was overworked, but that each member got to work on something they actually had experience in or personally wanted to oversee. This proved to take a huge weight off the team’s shoulders (especially David’s) as we had the benefit of having more fair and even workloads while still being secure in the knowledge that all tasks would get done by the appropriate deadline.

What Went Wrong

1. Playtests
Playtesting was a more significant part of this cycle, with a much higher volume of playtests required for the game this time around. Due to the nature of booking the motion base as well as the necessity of 2 Xbox controllers and at least 2 players, gathering playtests for Alien Arcade has always proven difficult. While we managed to scrape up enough testers to meet quotas, each playtest cycle proved challenging to say the least.

2. Time Estimation
As a fair amount of our team members were in their senior year, enrolled in multiple production classes, or both, many members suffered from large workloads for this quarter. As a result, underestimating the time taken for one of our numerous deadlines would cause a serious setback, requiring no small amount of work to catch up and get back on track. As we are still fairly new to game development, these underestimations happened frequently enough to become a recurring problem throughout the project.

3. Clarity
One recurring complaint we received about the game was a lack of clarity for a few of the games. Due to the hectic pace of the game and our large library of mini-games, creating consistent, clear and concise instructions for each mini-game proved a persistent issue for the game. While the game now features a significantly more readable and consistent HUD complete with concise controls and instructions, we were still never quite able to figure out how to reach the level of clarity we wanted for every game within the project. 

Lessons learned
• Documentation can be very helpful in keeping track of goals and progress
• Setting aside time to test games is just as important as setting aside time to develop them.
• Team synergy can have a significant impact on morale
• Increasing team sizes eases workloads, but can make team management significantly more complicated

Riley Stewart PPJ 8 Post-mortem

Right?

1. Good variety of games

With variety of mini games being used, there was alot of creative freedom for each individual developer do test their idea. having a a basic framework for development to work off of, the developers had complete creative freedom over the game they developed. this helps prevent development from growing stale, and if for some reason the game cannot go forward, it's less of a loss to the developers.

2.Wide variety of drexel ride movement potential

With the variety of minigames available, it allows the developers to use the rides capabilities in unique ways. the movement of the ride can vary greatly between games. One game, you move as a mech walker, the switching to an interdenominational spaceship. Possibilities are endless, and there is full freedom for developers to find and test  these possibilities.

3. basic framework for development

After we hammered out the bugs of the system, a basic framework for development was created. This streamlines and makes development simple, allowing developers to simply drop and apply this framework onto the games making implementation incredibly easy.

Wrong?

1. Work schedule

This is a personal issue. My schedule for this term was fairly strict, with other heavy production classes this term and working 30-40 hours a week. This prevented me from efficiently being able to produce work on time, as the only easily workable days were late Tuesday and late Wednesday. being so, alot of my work was implemented the week after it was intended.

2. Communication

Communication was difficult, as it took a while to setup slack. even so, alot of people were very unresponsive, leading to alot of confusion with development and assembling assets. This was a bit more efficient and worked out later on, but not fully fixed.

3. changing game concepts.

During development, alot of the minigames were changed alot from their initial concepts. this led to alot of the assets having to be changed as soon as they were made, or even scrapped completely. this was very frustrating and confusing during development. For my personal work, alot of the assets I created were scrapped, such as the initial stello says, cardboard cutouts, and the ufo model.

Resolving for future projects

Now the major hurdles are understood and worked on, development as a whole is far more streamlined. with alot of communication going on between the team members, any issues one developer has, such as art, programming, and design can be communicated with all other members of the team.

Lessons for future projects?

• There's always a way to solve a problem in development
• t's a challenge developing these games, even with the small scope and a basic framework, it's still a full game that needs to be developed
• COMMUNICATE
• get the ideas down early to speed up development and prevent wasted time and work

Vincent Slifer PPJ Post Mortem

What Went Right
1. Created Multiple Games for the Motion Base
The primary goal of the project was to successfully develop a game designed for use on the motion base, and I felt that this was accomplished fairly well.  Throughout the weeks, the team worked together in order to create and implement a diverse amount of games to experiment with the different motions of the simulator to create vastly different experiences for each game.

2. Created a Method to Integrate Games

A fairly important aspect of our game was that it was composed of mini games.  We needed a methodology to integrate everyone's games with a minimal interruption with anyone else's work.  We developed a fairly simple system of just creating our own sub folders to sort our games, but it was a good methodology to find assets needed in a quick manner.

3. Collaboration

A very important aspect in team projects.  I felt that everyone worked well together to make the project.  Everyone expressed their ideas to each other at meetings and brainstormed to create new ideas on how the mini games would be presented.

What Went Wrong

1. Version Control

Whether it was an issue with our system for hosting the builds or people updating the build at inopportune times,  there were a few issues with keeping the build updated.  From my experience, Perforce, itself, gave me a lot of trouble and headache.

2. Communication

While the team worked fairly well in collaborating together, there were some issues in communicating with each other.  Some members, including myself, did little to minimal communications on the group slack, and sometimes communicated in methods not fully available to the group.

3. Work Ethic

The team decisively separated members to fields that best suited their abilities, programmers program and artists create art, but the distribution of work seemed off.  From my experiences, I felt that I did not accomplish a lot.  I was able to program the mech game and had a little extra time to test an idea for another mini game, I felt that other members had taken up more of the responsibilities.  While I am grateful that they were willing to take on tasks, I feel that I should have had more work to accomplish.

Moving Forward

Essentially, the group needed a definitive leadership role to keep track of tasks and group focus.  The group needed someone dedicated to assigning tasks for each game, and figuring what needs to be done on a less loose schedule of just one week to complete your task.  The leader role would also aid in keeping members in touch, ensuring people were in open communication or could easily get a hold of them no matter what.  In the end, someone dedicated to being in a leadership role would vastly improve the effectiveness of cooperating with each other and keeping track of individual assignments.

Lessons Learned

- Communicate everything with members

- Ensure lines of communication are open

- Learn how to use the hosting service(s)

- Do not work on projects in the early AM

Angela Buchanan, Week 12 PPJ, Blog Post 8

Personal Postmortem

What went right?

-       Collaboration

The modular structure we’ve set up for our game has made it very open for a collaboration of ideas. I felt that it was great that we were able to use our initial individual concepts to test the process of making a game work as one consistent game, despite have such broad differences in the initial ideas.

We could have started with a fresh batch of game concepts, but I felt it was a beneficial experience for our team to take on the challenge of adapting games that were not initially designed for Alien Arcade. Since we were able to make it work effectively, I feel that it proves that our team is adept at collaborating with people whose ideas and goals are diverse.

I also like that we have built a space that is open to taking risk with little loss. Our game gives us the opportunity to try experimental ideas without worrying too much about failure, since losing a min-game is not as significant of a loss of losing an entire project.

-       Team Development

Initially, we had a lot of issues coming together as a development team. But over the duration of the course, we have all learned from our early mistakes and have made significant progress in creating a more efficient workforce.

While we still run into the occasional mistake or miscommunication error, they tend to be minor in comparison to our early issues. I am also confident that our team has the awareness needed to improve our work habits for a smoother run next quarter.

Not only have we improved functionally, but we have also grown together personally. We all take pride in the work we have accomplished together and have significant respect for each other.

-      Strong Aesthetic presence

On the art side of things, I’m personally proud of the theme we managed to develop for our game. Since the beginning everyone was involved in narrative elements of our game, and we were all interested in the setting we wanted to build.

I feel the idea of space carnies is a great way to develop a humorous, devious species and the idea of abductions and captives adds a nice touch of fear for the player.

Aside from ideas, we also have great assets that can easily be used across multiple games. We also have a lot of artwork that is effective at communicated our concepts and is great for promoting our idea publicly.

What went wrong?

-      Communication

                  This was especially problematic early on. I felt in the beginning it was easily to get lost in what was assigned and who it was assigned to. I didn’t just have problems with this amongst the artists, but it was also an issue that occurred with the programming side of things.

                  Despite this being a major issue, I felt we handled it well as a team. I felt a lot miscommunication stemmed from our lack of organization, which we realize now and plan to address in the future.

-      Changes in Ideas

In relation to the miscommunication, I felt our ideas were hard to confirm as decided upon officially. I felt this was especially prominent regarding themes for mini-games. I feel like this was primarily due to a lack of a well discussed asset list or Gantt chart.

I felt task priority was also hard to establish within the team. There were some tasks that were in higher needs of completion than others. There were also tasks that I felt were high priority, but after working on them and handing them off, I realized their priority wasn’t as significant as I once thought.

For example, the bodybuilder asset was viewed as a high priority when being made. But after his completion, I realized that the efforts put into him should have been applied to other assets first. However, he has gained a lot of popularity, so it was not a full loss.

-      Deadlines

I struggled with this personally. Unfortunately, the bulk of my class assignments this term were due early in the week and demanded a lot of attention. Combined with preparing for co-op, I had a chaotic, unpredictable schedule.

This combined with the miscommunication and organization issues early on in the project, led to a lot of assets being built the night before class. While it was relative easy to just roll the implementation of assets over to next week’s sprint, I would have preferred to have my assets completed earlier.

This was not only an issue of mine, but an issue experienced by other members of the team.

Moving forward and how do we fix these issues for future projects?

The majority of our team, including myself, agrees that a lack of organization was our biggest downfall. We thought perforce, meetings, and slack would be enough to manage an effective workflow for our project. Unfortunately, we were wrong.

In reality, we should have been making use of organization tools such as Trello. Even if it would not be our primary source of communication, it could serve as a guide for tasks assigned. There would also be no confusion as to what ideas were “official”, for tasks in Trello could be viewed as confirmed.

Despite the lack of organization, we still managed to pull ourselves together as a team and make great progress while acknowledging our mistakes and learning from them.

Lessons learned for future projects?:

-       Record everything major stated in meetings and keep it posted it in an easily assessable location.

-       Map out a detailed list of assets early on and actively communicate changes that are made to that list.

-       Always use organization tool, such as Trello, even if you think your current communication methods are fine.

-       Always ask others about the current state of things, especially if it directly involves your work.

Cory Zicolella, Week 12 PPJ, Blog Post 8, Personal Post-mortem

What went right?

1. We successfully created a system capable of pooling selected mini games

The primary focus when this game was initially pitched was to create a platform in which you can select games out of a pool and play them; secondarily we were to use the base code from our initial 10 week development period to use as a foundation for most future game ideas.  Considering we have a wide unique array of motion in each mini game, I would say that this venture has been successful.  The code base for driving, flying, sudden jerks, and bipedal motion are all included in our current build, with a WIP idea for boat physics--these things cover most groundwork for code that we would need.

2. Collaboration

Despite every person approaching the beginning of this term with unique ideas, each person was able to neatly collaborate on this game, partially due to the doors it opens.  Half of our tech demo games from week 3 were used in Alien Arcade, and the team was able to incorporate changes easily and without debate.  Those that didn't get to incorporate games had great input into the current build at hand and didn't fuss about ideas they weren't partial to.  If there was a problem at any point, the group addressed it simply and found out a way to solve it, together.  I'm fairly certain there were no points in which there was a disagreement between us, and the work we accomplished really speaks towards our willingness to function together.

3. Capable of Solving Issues Efficiently

It is no secret that despite everybody's best efforts, there simply were issues that we had to deal with over the term.  We are only human after all, and when these issues arose they were always either highlighted to the responsible party and dealt with post-haste, or it was mentioned to the entire team at which point we split off to fix whatever went wrong.  This was the case in multiple cases; when the work on the Mech Game was delayed, when I accidentally created 3D models (instead of cardboard models), when everyone was still cranking out new resources with only 2 weeks to go.  All of these issues were dealt with very well and this is just me speaking from the art end--I'm sure that the coders handled many more issues (One I'm aware of is the motion base bug).  Because we were capable of this efficiency, it allowed us to complete alot more in our allotted time.

What went wrong?

1. Lack of a Gantt Chart

I think this is pretty straightforward.  Had the team been referencing a Gantt chart or other similar project management, we wouldn't have had to be confronted in the 11th hour to stop making new resources/adding to games.  We could have adhered to a strict schedule and been aware of what we needed in the weeks ahead.  Granted, we ran into a few hefty bugs that took awhile and inevitably some portions would run into other weeks--but it would without a doubt have kept us all on the same page, instead of meeting once a week and delegating tasks randomly based on current progress.

2. Communication

In the early onset of this project, we communicated via email.  Needless to say, this was disorganized and worked horrible, especially with Drexel's email system: some people just wouldn't get group communications because their mailbox was full, and others just wouldn't check.  After 2 weeks of this nonsense, we moved to Slack, which alleviated much of our communication issues to almost 0--to those who used it.  Many did what was asked of them regardless, but some didn't check the slack often or got notified when they should have been.  I was on constantly and almost instantly replied when I needed to, as for others I can't say the same.  Some people barely used the slack at all.  And communication mediums aside, sometimes tasks were garbled and confused, causing people to not do the right thing or nothing because they were unsure of what to do.  This happened very few times, but communication was surely a factor.  Communication issues will always ensure when there is teamwork though, and overall I think we did moderately well.

3. Work Ethic

This is a bold statement, I know-- and it surely doesn't affect everyone.  I can really only say this at a personal level, but sometimes my work ethic suffered.  Of course everybody has more than just this project to do, and I'm understanding, but most of the work for the majority of the term was completed seemingly last minute.  As time went on I got better with it, not doing all of my work on Wednesdays and instead having it finished by Monday night or Tuesday afternoons, but I certainly feel like others also waited a similarly long time (or longer) to complete their work.  Again, I only can accurately measure my time spent: I did complete everything I was assigned to do usually (unless surprises occurred that took more time).  I just work well under pressure, so naturally I wait in order to give myself that motivation.

How are these issues resolved for future projects?

The answer to this one is quite simple, I feel.  We'll most likely have laid out groundwork for what needs to get done so the team isn't delegating jobs on a per-week basis; it allows a better insight into our final goal.  Communication will always have somewhat of a rough road, but if we are more aggressive with standards or simply having people report in once a day it will probably solve all of the issues there.  As far as work ethic goes, that is up to the individual to fix.  To a certain extent team members can add pressure, but that isn't necessarily good or helpful for the team as a dynamic--ultimately it is up to each of us.  For me, I've already accepted that I need to complete my work sooner.  For others, it may be similar or it may come later.  Meetings will iron out most of the remaining team problems and enforce (what should be) these new policies to insure that we won't have to deal with as many problems next term.

Lessons learned for future projects?

The lessons that working together with Team VIIcious for 12 weeks have taught me:

• Most bugs, however large, are workable for your goal
• Communication is key to creating content
• Even though mini games sound easier than a single game, there is just as much work
• Version control is a lifesaver sometimes, even if Perforce is the devil
• Keeping momentum at a high is important for productivity
• If a team is able to collaborate, it makes teamwork so much more enjoyable

David Monteleone, Week 12 Journal PPJ, Blog post 8, Personal Postmortem

David Monteleone, Week 12 Journal PPJ, Blog post 8, Personal Postmortem

Communication, Team, Framework, Mini games, Motion base, Personal Postmortem, PPJ

Personal Postmortem

What went right?:

1)      Making a modular system to integrate plenty of mini games.

One of the main goals for the project was to create a system where games can be worked on in small teams and easily integrated into the entire mini game system. Through the use of modular scripting and not creating major dependencies, the team did this well. Moving forward, the team is now able to break out into small groups and create any type of motion mini game that you can dream. I saw this as an excellent breakthrough for the team and was happy to have been a part of it.

2)      Cooperation within the team.

Although the team suffered from a lack of solid communication, the group did get along as a whole. There were never any personal conflicts between individuals that cost us time. I’ve been in far too many groups where individuals end up hating each other by the end of the term. As of now, if the group moved onto next quarter, we have a solid relationship between everyone. I see this as being an excellent asset as friends work together better than enemies. We are definitely a team and work to motivate each other to do their best! As a leader in the group I worked to keep individuals motivated to do their work and wanted the best work from them.

3)      Recovering from a rough start.

I’ll be the first to admit that the team started out pretty rough. We we’re very confused and disorganized. The mini game concept lends itself to getting lost in many different ideas. However, around week 6 after having a serious group meeting, about getting our act together, the team recovered from its rough start and turned our Alien Arcade idea into a reality. Production ramped up, assets got finished, scripts were cleaned up, and real work was being done. I’m proud to have been working on a team that was able to fix so many problems and finish so strong. I’m not sure if my leadership was a part of the recovery, but I tried my best to help the group get out of this hole. I put many more hours than I needed into the game to bring it back up to speed.

What went wrong?:

1)      Communication between teammates.

From my perspective, the group suffered from individuals not keeping an eye on Slack. It also took a couple weeks to get the entire group onto Slack. People simply did not accept the invites to join the group even though they were sent when the group first started. Throughout the term there were situations were individuals would go quiet on Slack and not report where they were at on their tasks for the week. This resulted in myself having to pick up other peoples’ tasks. Sometimes people would do the same work and not realize two people had finished it. This is clearly unacceptable and the team will work to make sure that all individuals are accountable for communicating to the team next term. The leader of the group next term will assure that all teammates are in constant communication with the group.

2)      Version Control

From my view, the group struggled to use Perforce throughout the majority of the term. By the end of it everyone understood how to use it. Individuals were pushing changes that lacked .meta files. Teammates were working on the same files at once, which resulted in painful merge conflicts. The group spent more time than we should making sure that Perforce was taking our changes that we made to the game. For myself, after working through my work for the week it would sometimes take me an hour to properly get my changes into Perforce. The group eventually ironed out these issues, but it did keep our production slow in the beginning. In the next term a Perforce meeting will be held to iron out any issues that teammates having with using Perforce.

3)      Lack of a task assignment and management system.

The group used no task assignment and management system throughout the term. Tasks were assigned on a weekly basis and the team used the status report Excel file to figure out weekly tasks. There was a master task list in the Google Drive, but this was not updated regularly. This resulted in teammates not knowing when certain tasks had to be completed and the general timeline of the production was not set anywhere. I think this is one of our biggest crippling factors. I was very unhappy with the lack of organization we had this term. Moving into next term, the group will utilize Trello to fix this issue as it plagued us throughout the term.

Moving forward and how do we fix these issues for future projects?:

I know that the team will fix these issues in the next term. A clear leader will be assigned to the group through a voting process. Sometimes leadership roles were swapped throughout the term and there needs to be a clear leader to look to. The leader will be responsible for assigning tasks through Trello and making sure that all individuals are working on their assigned tasks for the week. There will be no lack of communication between group mates and the entire group will assure that. Before production ramps up in the next term, there will be a Perforce meeting to make sure that everyone working on the game understands how to use Perforce quickly and correctly. The group as a whole will be stronger and better. The issues that plagued us in the Fall quarter will not carry over to the Winter quarter. I will make sure of that.

Lessons learned for future projects?:

My personal lessons learned from this term are:

-          Modular systems are great!

-          Team cooperation is key!

-          Don’t have slow starts.

-          Make sure all teammates communicate.

-          Use version control to work for you, not against.

-          Use a task and management system!

Tags: Communication, Team, Framework, Mini games, Motion base, Personal Postmortem, PPJ