Monster Munchies: Postmortem

Monster Munchies: Postmortem

During our 21 month stay at the Southern Methodist University Guildhall students are required to participate in three different team game projects.  In each of these projects students develop a unique game.  My first experience as an Assistant Producer began when my team, composed of 5 students, started development of a game called Monster Munchies , a 2D platformer in which the player controls a small monster named Hungr.  Hungr must eat monsters smaller than himself in order to grow and avoid larger monsters that, in turn, will eat him.  We developed Monster Munchies over the course of 8 weeks, starting with the preproduction phase, progressing all the way through the release to manufacturer phase.  This blog reviews some aspects of what went well and what went wrong during development of Monster Munchies.

Several aspects of Monster Munchies development went very well.  These aspects include the use of Scrum/Agile practices, frequent testing, and appropriate scoping.  Scrum/Agile practices did several things that really helped the Monster Munchies.  First, Scrum/Agile helped the development team stay on track for delivering milestone requirements on time.  This is due to the fact that Scrum/Agile is a methodology that allows a high level of adaptability and visibility.   Every day a scrum meeting was held and developers observed what had happened since the last scum meeting, what was set to happen on the project for the day, and if other developers had run into any problems.  The development team learned though these observations and adapted accordingly.   Being able to adapt easily to development challenges allowed the project to progress smoothly.  Second, the use of a Scrum Board as an organizational tool was incredibly helpful.  The Scrum Board hung on the wall of the development environment and served as a physical, visual representation of all the tasks that needed to be done and in what order they needed to be completed.  The Scrum Board contributed greatly to project visibility because it was always within sight of every member of the team.

Another aspect of development that went well was that all members of the Monster Munchies development team participated in the frequent and rigorous use of various types of testing which included component, integration, and kleenex testing.  After the completion of a component, the team member that created this component would test it to make sure it met expectations.  If the component passed the test it would be integrated with other components required for the current milestone.  This integration would be tested by all members of the team.  All this testing allowed the development team to find and correct bugs, balance issues, and gave insight into whether the game was fun or not.    Kleenex testing involved bringing in a tester who knew nothing about the project to test the game.  The physical and verbal reactions the tester made while playing the game as well as the in depth feedback the tester gave after he finished playing the game was recorded and evaluated.  Kleenex testing gave the team valuable feedback about the game that only a person unfamiliar to the project could give.  This feedback allowed the team to make crucial decisions regarding the design of Monster Munchies and adapt accordingly, making the gameplay clear, easily to grasp, exciting, fun, and rewarding.

Monster Munchies Play Test Report

 Another aspect of development that went well was the use of appropriate project scoping.  The development team only had eight weeks to bring Monster Munchies to completion so scoping the project appropriately was paramount.  During preproduction the team streamlined and simplified game design as much as possible, eliminating any features that were not absolutely necessary to achieving the games goals and requirement.  Team members also strove to provide the most accurate task estimates possible so that the project could be scoped appropriately.  This focus on appropriate project scoping allowed the team to finish all their work on time and meet the strict and rigid milestone dates that the project was required to adhere to.

Not everything was sunshine and rainbows during development of Monster Munchies- we certainly had our fair share of storms and rainclouds.  Several aspects of development that went wrong included having a team member leave abruptly during the middle of development, having to physically change locations multiple times during development, and having unclear project requirements.  The biggest thing that went awry during development of Monster Munchies was having a team member leave abruptly during the middle of development.  This team member did not inform the team in advance that he was leaving the project and did not respond to any attempts of communication from team members after he left.  This behavior cause several problems for the team.  First, it put the project in jeopardy of not meeting alpha milestone requirements because the team member did not turn in key components he had developed prior to leaving.  Other team members had to quickly develop these key components so that alpha could be completed on schedule.  Having a teammate leave so abruptly was also demoralizing to the remaining members of the development team and left them feeling abandoned and hurt. 

Another aspect of development that went wrong was the fact that the team had to physically change locations multiple times during development.  It seemed like as soon as the team got used to its new “living arrangements” they had to move.  This constant shift away from familiarity was disorienting.  The multiple location changes also created a drop in team productivity.  This was due largely in part to the fact that team effort had to be redirected from working on components of the game to physically moving project resources from one location to another. 

The final aspect of development that went wrong was the team had to work with unclear project requirements.  During the preproduction phase of Monster Munchies the team developed a game design document based on requirements set by a particular professor.  Later when two new professors were put in charge of overseeing game development, the requirements for the game design document changed and the document had to be completely reworked.  Other project requirements were often unclear to the development team due in part to the fact that there were two teachers in charge who often defined requirements differently or answered questions regarding requirement definitions differently.  These unclear project requirements sometimes forced some team members to redirect time and effort allocated to developing the game to seeking clarification for project requirements.

In conclusion, like most projects, development of Monster Munchies had some aspects that helped facilitate smooth sailing and some aspects that caused rough water.  As first time developers, we as a team learned so much throughout the development of Monster Munchies.  We found that the use of Scrum/Agile practices can be extremely valuable for use in game development, testing frequently and rigorously contributes greatly to the quality of the game, and that scoping a project appropriately greatly helps developers deliver milestone requirements on schedule.  As a team we also discovered that it is important to be committed to the project and other team members, as a loss of a team member hurts the project and team morale.  We found that it’s important to have a stable location to work due to the fact that changing locations is disorienting.  Our final discovery was that having unclear requirements is detrimental to productivity.  All in all, the Monster Munchies was a great success: the game was exceedingly fun and as a team we all gained valuable development experience which we can apply toward the future success of our next project.

Monster Munchies Trailer