Tiny Gods took a total of 19 hours to complete and was made entirely from scratch.
What Went Right
Schedule. Planning out my time worked well again, I spent a total of:
- 2 hours on initial concept, core mechanic, core mechanic consequences, game design
- 4 hours doing artwork
- 2 hours in core game code (movement, physics, messaging, enemy AI, world-state managment)
- 3 hours in the level-complete and level-transition logic
- 1 hour GUI programming
- 2 hours on music and sound effects
- 3 hours coding the ammo – planet influence feature
- 1 hour creating level (again, not nearly enough time here)
- 1 hour packaging-up entry, submitting entry
Total Production Time: 19 hours
Things I wanted to spend more time on: the artwork, the GUI, more levels, and a final boss battle
Tested Pipeline. Being familiar with all my tools helped tremendously — I’ve used this toolset (Unity, GIMP, GraphicsGale, Audacity) before, so I had a well-defined pipeline. I knew exactly what formats to use and I knew exactly what settings I needed to get everything into Unity without any issues.
Prefabs. In my first LD48 (#21), I burned a lot of time trying to figure out Unity’s physics engine, but now I use a “cheat sheet” to tell me when to use: Triggers, RigidBodies, Kinematic RigidBodies, and under what conditions OnTriggerEnter() works and when it doesn’t. Using Prefabs for everything worked amazingly well and saved a ton of time. I was surprised (and pleased) to find that instantiated prefabs (that were already saved in separate levels) would receive updates when the original prefab was modified. Near the end, I was adding AudioSource components to my single Planet Prefab (the shotgun reload sound) and every planet in every level got that update. I had always thought that level data really was just a set of metadata pointers, and this really confirmed it.
Early Artwork. Doing the Artwork first was a boon to my productivity — it really kept me motivated. I was able to use a single prefab for the player, monsters, bullets, and planets and then code around that. After words, it was just a matter of making more prefabs (or extending the code) for variations and then adding them to the collection in the WorldManager. Having a central “WorldManager” class worked really well too – this managed the game state, and managed most of the communication with other classes – this allowed me to have “lose coupling” because no class needed intimate knowledge of any other class. Using the SendMessageOption.DontRequireReceiver for all messages also allowed me to easily work from either the top-down or bottom-up and when “ends met”, it all worked out as planned.
Formulas & Binary Math. To determine an enemy’s strength by level, I used binary math on the level to pull out 4 qualities for its health, the amount of damage its attacks do, the speed of its bullets, and the frequency at which it shoots bullets. This worked out amazingly well, as the difficulty of the enemies has good variation (lots of ups and downs in the qualities per enemy), but also overall increase in difficulty. A simple set of formulas takes care of it, which saved having to enter and maintain all that data.
What Went Wrong
Pre-Dare Prep. I didn’t start my pre-dare prep early enough, so ran into extra work I needed to do on my personal website, plus extra work I had to do with my LD WordPress account, and lots of other little “odds and ends” that needed to be cleaned-up. This led to a lot of stress the night before the dare. Next time, I’ll start all my pre-work at least a week ahead of time.
New Untested Features. This time I wrote some features that I’ve never done before — namely the influence of the planets on the player’s ammunition type. This didn’t amount to a lot of lines of code, but it did result in lots of thought-time spent in trying to figure out, “oh, just exactly how am I going to do that?” I finally figured out that this just amounts to the planet sending out a Broadcast message to any “Player”-tagged object while that object is within its OnTriggerStay() — but figuring out that solution took three hours. Three hours for this one feature alone is FAR too much time when you only have about 20 hours total to get something done. My plan for resolving this in the future is to start maintaining “Unit Test” projects again (I used to do this extensively in DarkGDK) for ideas I come up with, that way I’ll be have a good idea how to code something up before being in a compo.