Production: Personal Postmortem

What Went Right?

  • Communication with the programming team was good
  • Implemented multi scene loading, drifting, and speed surfaces
  • Finished the game without crunching during the last week
  • I got to spend some time trying to figure out graphics programming in Unity
  • We used Gitflow fairly successfully
  • Multi Scene Loading worked great and avoided a lot of merge conflicts

What Went Wrong?

  • I spent several weeks trying to figure out graphics programming without an end product relevant to the game.
  • We underestimated programming scope during the start of the project
  • The project file system is a mess with art folders and procedural generation code. The unity folder itself is named descriptively “P3” on the same level with “Reboot” which is a Maya project folder.
  • We didn’t get a high level of polish or juice into the game.
  • Unity physics was a pain at high player speed. The player would bounce unpredictably off walls or sometimes just shoot out of the game.

What Did I Learn?

  • Use Gitflow and some sort of multi scene architecture, even a basic loading script is better than merge conflicts.
  • Don’t trust Unity physics.
  • Overestimate programming scope at the beginning to help avoid the inevitable crunch later.

Some Other Thoughts

My biggest problem with the production courses is that producing a polished product is not an important end goal. It’s fun to make a scopier game that won’t be completely finished, but I would like to have a nicely polished game for my portfolio and for the experience of actually getting to fully finish a game. The scope can also discourage cool architecture or trying new things because it’s faster to use already known solutions.

Leave a Reply

Your email address will not be published. Required fields are marked *