Post-Mortem: Gravitos

Summary

The original goal of Gravitos was to create a short 5-10 minute experience for a general market of teens and up. Since then Gravitos has changed a lot (its target market, its accessibility, and much more). Mistakes were made on the project, with some being corrected during development and some which will have to serve as lessons for the future.
My personal goal for the project was to create a game that looked simple upfront but that contained underlying depth. Unexpectedly, getting the game to be complex was the simple part. Diluting down the mechanics into easy-to-learn ideas took the most effort on the project.

3 Things that went Right

1. Updated Development Builds at the End of Everyday
   The team made it a goal to have a unified build of the game at the end of the everyday. The intention was to make make sure the team had an updated build of the game to work off of at the start of each work day; this was most important when team members worked on the same assets. This daily practice proved effective in keeping development assets organized.

2. Building Modularly
   After a concept pitch session with industry mentors, the team was encouraged to scope down the game to fit our remaining production time. The cast of enemies in the game was condensed down and the core mechanics of the game were simplified. These changes and many others made to the design were easy to implement because the team was able to remove modules as needed.

3. Design/Art/Script Falling Under One Person's Responsibility
   From the get-go, the team aspired to make sure that every member of the team had a share in each pillar of Gravitos’ development. This deep-rooted involvement in the game, meant that each team member specialized in a certain feature of the game. This also gave each team-member experience with each pillar needed in game development.

3 Things that went Wrong

1. Forgetting about User Feedback and Aid in Pre-Pro
   At the start of the development, Gravitos did not have a goal for accessibility. The team naively thought that users would instinctively understand how to play Gravitos without any aid. During development, mentors convinced the team to make changes that would make the game more accessible. These unplanned additions replaced a large chunk of the work schedule that was previously dedicated to implementing wishlist items.

2. Not Stress-Testing the Engine
   When it came time to build the game’s levels, low framerates, collision errors, and other technical issues hindered level development. Out of the originally planned four levels, two had to be cut because of time constraints.

3. Gravitos’ Feature Creep
   Features that were not originally detailed out in the design document found their way into the game. These added elements strengthened the design of the game, so this is more a fault of not having the foresight or experience to document these things during pre-production.

Outcome

Working on Gravitos has taught me a few things.

1. Having a unified workflow is a major contributor to success.

2. User accessibility is equally important as game complexity.

3. Know the limitations of the technology that you are working with.

4. Keep in mind the smaller design needs that are usually overshadowed by the larger features.

5. Great Design comes from constant communication.