AMAZE Postmortem

With this post, the little saga of AMAZE will be over.

It's rather freeing to be able to move on to other projects, but I think it's good to give it a bit of closure first. Normally, when I make a postmortem like this one I list what went right and wrong with the project. However, very little went right, so I think it's better to focus on what I learned so that I don't make the same mistakes again. Without further ado, here's the list:

When handling things asynchronously, watch out for race conditions:

This is a big one. It's the source of the stupid crash bug that I can't fix. The issue lies in the engine's scripting. Specifically, the ability to put delays in script. Originally, scripts were executed synchronously, in a single frame. By adding delays to scripts, I introduced an asynchronous element that meant that multiple scripts could run concurrently. This quickly became a nightmare, and eventually led to the bomb crash. Specifically, a delay occasionally causes a bomb to be destroyed while a collision script involving it is running. Because the remaining script is now trying to mess with something that doesn't exist, the game crashes. If I'd just made the script activate a timer on the bomb, the script would run on one frame and naturally would be prevented from running unless the bomb existed. This is the method that I'm going to try next time.

Don't put off art/audio:

For that matter, I shouldn't put off levels either. Because I focused solely on the code for so long, the end of development was just a mad rush to crank out as many assets as possible, and the quality suffered accordingly. Had I been working on the assets throughout the process, the game would probably be much nicer now.

Entity Component Systems are great, but don't forget prebuilt objects completely:

ECS was probably the biggest success of the project, but I still screwed up with it. I made creating levels slow, and updating objects next to impossible by not having any means of making predefined object 'templates' that I could stick everywhere and modify as necessary. Not only did this make designing levels take a long time, it also worsened the final product's polish immensely. For instance, I wanted to make a little ding sound and some sparkles when treasure was collected. However, this would've required me to alter every single bonus in the entire game by hand! Seriously, I'm not even joking. Had I made prebuilt objects possible early on, doing this would've been trivial, and taken 2 minutes at most. Whoops.

Preparation is key:

This rule applies to basically everything related to this project. Had I decided on a concrete art style, the game would've looked better and I wouldn't have had the issues I did(Like how some sprites are top-down, and others are from a slightly angled perspective). Had I planned the engine out more from the start, I wouldn't have had to rewrite as much as I did and the game would have been finished quicker. Had I spent more time thinking not just about what to put in the game, but how to do so, I would've started with a much smaller scope. I could keep going for a while, but I think you get the idea. Without a clear direction, the project became a nasty mixture of ideas that didn't quite fit together right.

Start Small:

When making the first version of this engine, I shouldn't have tried for a major project. Instead, I should have tried to make a bunch of small, varied games. It would've given me a better idea of where my strengths and weaknesses lay, and I could have spent more time fixing and upgrading the engine.

So, you might be wondering what will happen next with the engine. To make things simple, I'm taking a mulligan. I'm going to rewrite the engine from scratch and try to apply all of the lessons I've learned this time around. I'm going to plan more, make more small games, and also try to practice art and sound more. Then, hopefully I can try for a major project around version 3. Finally, I'm going to try and be more open about my work. I'm going to set up a public repository for the project so that others can see and contribute to the project if they want. I'll write more about that soon.