The point of this is both to describe my experience with the game as well as start to gain experience in writing Postmortem writing. I also want to have something to look back on later on in my life and to give readers a look into the past as my later writings appear. The point of a Postmortem according to eHow is usually to serve these four purposes: to review and discuss whether the project was successful, identify high points and accomplishments, point out important issues, and discuss problem-solving tactics and outline core takeaways. I will attempt to answer these four points one by one. If there are any comments or anything I can help explain, let me know. This is my first postmortem, haha.
Note: I haven’t actually read a postmortem before. I just wanted to write about my experience more than anything and if this isn’t anything like what a Postmortem should be. Well, I’ll figure that out eventually.
Parameters and Objectives:
  • Title: Cuddle Coddle
  • Type: 2D Platformer
  • Platform: Unity3D
  • Project Manager: Napoleon Martinez
  • Start Date: 11/14/2014
  • Completion Date: 11/15/2014
  • The project was an experimental game jam game based upon the theme of love. It was created for the USC Makers of Entertaining Games Association’s 24-hour game jam. The game jam commenced at 6:00 p.m. on November 14th, 2014 and ended at the same time the following day. It took place in SCI L103 at the University of Southern California.
  • The team consisted of four members in total: Lead programmers/game designers Napoleon Martinez (me) and Alex Ogorek, artist Chengyu “Lowrie” Fu and sound designer Nelson Thomas.
    • It should be noted for clarity-sake that Nelson Thomas did not participate in discussion or development of the game game, but merely worked as an outsourced agent of the game.
  • The game had no budget and no benchmark evaluation measurements other than periodic and tentative goals set by the team in terms of time such as “Let’s have a prototype by 12 p.m.”
  • Constraints of the project include:
    • Technological – The project team were working on SCI computers that were not there own and had technical limitations such as no access to installation of outside programs.
    • Skill – This is the first or one of the first games worked on by three of the four team members and should definitely be noted as such.
    • Time – The time to complete this game was twenty-four hours as noted above.
      • Note: This is by far the greatest and one of the only, if there is to be others, significant limitations listed.
    • Communication – In the lower levels of SCI, there  is no access to cell phone reception. This was mainly inconsequential but shall be noted. Constant communication with the outsourced sound designer, Nelson Thomas, was not maintained.

Performance Analysis and Assessment

The goals of the game were mainly to create a game that invoked the imagery, emotion, or some other aspect of love. Prior to the 24-hour game jam, the group had a 1 hour meeting at Leavey Library concerning the idea that we were planning on implementing during the game jam. Chengyu Fu presented an idea about a game about a mama bird feeding her children with love with the mechanic of dropping love to feed them.

  • The aesthetic desire was to create a feeling of motherly love and care for the status of the babies.
  • The dynamics would be created through the movement of the player through the space. As we began developing.
  • The mechanics would be moving through the space as the mama bird and delivering the love to the children.

Overnight and into the launch of the project, Chengyu created art assets for us to use in the game. Meanwhile, Alex and I developed a movement system for the bird using transformations with a simulated gravity rather than using Unity3Ds physics system (which probably would have been more ideal). We then proceed to develop a egg spawning system, a bird hatching system and a heart spawning system using prefabs. We created a heart gauge that tracks the happiness of the bird as well as a timer to track the growing up of the bird between the three stages of a baby birds life: egg, baby bird, lay two more eggs. This cycle would repeat until the player cannot keep up with the amount of eggs on the screen. We  created a system for the bird to collect the hearts using isTrigger in Unity3D and to switch models by essentially respawning a new sprite at the same location with the same variables (velocity, direction facing) as the old sprite. We did this to update the graphic to show the player that they have collected another heart (up to the maximum of three) . There may be a better way to do this as well (See issue 5 below). We used a similar system to create a system to show the baby birds crying if their heart gauge gets to below half.

Some issues faced with the game include:

  • Dealing with the continuity of velocity as the bird changed from one sprite to another.
  • Dealing with the breaking of the game when the game would try to spawn more eggs than the maximum allowed number of eggs. Using an array that sets each of the ten spawn locations as a place where an egg can be placed through true/false booleans allowed us to solve this problem.
  • Learning how isTrigger works in Unity3D. This took a bit of reading and was well worth it to solve a problem where the player model (mama bird) would have the physics of the heart push back and rotate it (which was not wanted).
  • Learning how to use a system that would switch models with different animations. E.g. mama bird flying with one heart vs no heart vs two vs three.
  • There may be a better way to change the sprite of an object without respawning it. I do not know how to currently do this and is something I would like to learn. I believe that the state system of an animation holds the answer to this question.
  • I believe there must be a better way to create the hearts as it stands the current object is not a solid object and thus cannot be held on platforms (see design changes #6). Although it did solve the problem of the bird having to pass through the heart and collect it without colliding with a physical object, causing the player object to spin.
  • Designing over twenty-four hours took a lot out of Alex and myself, the two that stayed overnight to program the game. Taking turns programming while the other took breaks to check on other teams in the room or to eat or check phone messages definitely helped to maintain a workflow while maintaining our energy levels. Definitely, the atmosphere of the room and the energy throughout as each of the teams worked next to each other added a nice energy to allow for oneself to progress.

Some design changes to the game during development include:

  • The game does not have the baby birds spawn in set locations, but instead has the eggs appear in randomized locations based on an array.
  • The game does not allow the mama bird to drop the eggs, but rather must deliver them by going to the location of the baby birds.
  • The game no longer has a counter that originally was programmed to track how long until the baby was sad. Instead, the new shrinking heart system was added in order to try and convey the sadness of the baby bird visually.
  • The game no longer has a counter that originally was programmed to track how long until the egg hatched. Instead, a new growing bar was added in order to try and convey the aging of the egg visually. This was then persisted to the growing of the baby bird in order to help the player understand the mechanic moving forward with the game.
  • The cloud system was not originally intended to be in the game. However, given the atmosphere of the game, we decided to apply the system we used in the game previously developed by Alex and myself, Altruistic Airdrop, into the game. We also mistakenly persisted the cloud generator into the final scene, but it looked nice enough that we left it.
  • Originally the hearts were going to fall down onto pre-made cloud structures. We opted, instead, to allow for the hearts to merely appear at random locations without cloud platforms.

Some things we definitely found useful is using Google Drive to transfer files such as art assets and sound assets to each other without having to go through flash drives or other such media.

Assessment and Takeaways

  • Overall, the project was a success. Certainly, given the time constraints, the success of the game can be held as high. I continued to build my Unity3D as well as C# skills. I learned to work together with an artist and sound designer, unlike my previous game which was mainly only created through Alex and myself. Given more time, implementing a better tutorial system would have been more ideal, given that currently our game relies on the player either picking up on the information during gameplay (which only works to a certain extent) or by reading the text in the start screen (which many players did not). Also, the game over screen would preferably be further polished. Overall, the main goals and systems that we wanted to build into the game were indeed built and created to a satisfying degree.
  • Additional development time would go into iteration and variation of the current game build. That is, the main mechanics of the game as planned were all constructed, which, from my perspective, shows that during this game development cycle over-scoping was not a problem. We created the game we set out to create and met our goal of making the game somewhat challenging, themed, and, from player feedback, fun.
  • Another thing I would have additionally liked to have created was multiple traversal levels using cloud platforms. E.g. a maze like setting with greater timers on the baby birds and eggs (or perhaps not).
  • Improvement on allowing for more interesting decisions would be something that I would like to achieve in further iteration or further game development cycles.
  • Another take-away would be in trying to work better on communicating with my sound designer as in this case it worked out that the sound was exactly what I wanted to hear, but I may not be so lucky next time (although I do trust in the work of Nelson Thomas and have no reason to not do so at this point in time, if ever).
  • Cleaner code would also be something to be improved upon in future game development. Our code was quite sloppy during the development of this game and learning better practices of organizing C# will be another personal goal of mine.
  • On a ten point scale, I would rate the overall success of this project at that of a 8/10. Nothing over the scope of our design was completed and there is definitely room for improvement, however, our goals were completed and an experience that I am personally proud of creating was finished.
    • Other aspects:
      • Communciation: 7/10
      • Management: 7/10
      • Implementation: 9/10
      • Teamwork: 10/10
        • Note: I think the team did fantastic and cohesively. I think it should be noted that I’m glad to have worked with this team and they each deserve recognition for their work on this game as well. [Insert clapping].
Share on FacebookTweet about this on TwitterShare on TumblrShare on StumbleUponShare on RedditEmail this to someone