So it’s time to look back at my 48 hours of game-making, like many are doing. Let’s see what happened during the development of A Steampunk Axebot Supply Run.
What went wrong
The Theme – “It’s dangerous to go alone” was the one on the bottom of my list. Why would anyone vote for it, I thought, when there are so many interesting alternatives, like nihilism, or climbing? Why, indeed. I had nothing prepared whatsoever for this theme, and spent the first 2 hours panicking over what to do.
The Level – It occured to me only later that I could have made this in 2D, or using tile-based movement, either of which would have made creating this stuff considerably easier. Oh well.
Textures – As in “I don’t have any”. Adapting UVs is a grueling and time-consuming task,which I would rather avoid, and spend the time otherwise. Using the toon-shader for all 3d-objects was a great choice, but it would have been prettier with added textures. The terrain clashed with this. I couldn’t use the toon-shader on it (so far I know), and creating extra textures for it alone was not efficient.
Preparation – Slept too little the first day. Woke up at start-time (4am), but forgot to check the theme. Felt unmotivated and guilty for first 36 hours, bevofre I finally kicked into non-stop game-making mode.
What went right/not-so-wrong
Timelapse – It felt weird, at first, knowing that my every move was being recorded. But the video makes everything seem ultra-efficient :-)
Music – this one actually surprised me. I never really composed anything bigger, and I just aimed for something unobstrusive. I ended up with a sweet theme which fits the game awseomely, complements it, and people actually like.
The Title – No matter how good or bad this was going to turn out, “Steampunk Axebots” sounds awesome.
The Scoring system – Your profit is determined by several systems, which are based on enemies killed, health of the robots, extra fuel left, and over-healing. Each robot has an own pattern and unity set of enemies at different times, so it is quite challenging to figure out the best combination. I still haven’t.
The fuel gauge – The rockets can travel only for a limited time, before they crash. I intented this to stop players from hovering over the playing field or leaving it, but the time-constraint added another tactical layer. The rocket takes some time to reach its target, but once it passed a certain point, reaching the other targets would be impossible. It was however possible, that the robot you tried to heal died while you were on your way, meaning you had to carefully decide where to shoot. But since all robots converge on a central point later in the game, it became at that point possible to switch targets should something happen.
3D-models – My first though was a little knight, which I would have need to animate. Unfortunately, there was no time to either animate one or learn how to include animations in Unity (note to self: learn how to include animations in unity).
Biff-Particles – They are quite a good substitute for fighting-animations.
Healing-Particles – They look much better than I planned.
What I would have liked to add
More stages – which become increasingly complex and tell a story
A menu – Which I already had around, but no time,and no good reason (with only one level) to implement
No introduction screen – I always hates these. Dammit, I want to play the game, not read a novel! There are ways to start the game at once, and teach the player on the fly.
Destroyed robots and rockets – Which I would have added were it not for a game-stopping bug I encountered with only 40 minutes to spare
Having the title of the game appear somewhere in the first level – Like I did in Unstoppaball. I love that gag.
-Matthew
Matthias Zarzecki 