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.
