Game Postmortem

The Idea

This is my fourth game jam. In the past, I struggled because I tried to create games that were too creative, and had too many bells and whistles – I’m told this is called “overengineering.” So this time around, my goal was to be as un-creative as possible, and to create a very standard game in a well-established genre (but hopefully a game that was fun to play). When the Ludum Dare theme of “keep it alive” was announced, I decided that a tower defense game best fit all my requirements. A quick aside: Tower defense games seem to have gotten a bad rap ever since the invention of smartphones and the proliferation of copycat skinnerware tower defense games. To many people, the phrase “tower defense” conjures the same ideas as the phrase “match 3.” But that wasn’t always the case. I have many fond memories of playing custom tower defense maps made for warcraft 3. These maps varied wildly in terms of mechanics and themes, and they were HARD. I distinctly remember the feeling of having a maze of towers that felt impregnable, only to get utterly destroyed by a few brutal rounds.

As for the flavor of my entry, I was inspired by the film Ice Age to make the goal be to save a creature on the verge of extinction (but I went with a mammoth instead of a dodo bird to distance myself from that movie). I love silly themes like “cavemen,” so this was a great fit for me. I started jotting down some caveman-related puns, and the rest, as they say, is prehistory.

First Steps

At the top of my planning sheet, I wrote the following unit descriptions:

CAVEMAN: Standard inexpensive attacking unit. A paragon of culture and sensitivity.

CAVEWOMAN: Attacking unit that has the chance to stun enemies. Like a caveman, but more sophisticated.

CAVEMANSPLAINER: Increases the damage of nearby friendly units. Ugh, not this guy again.

MANCAVE: Slows down nearby enemies. Relax! Take a load off.

CAVETOWN: Attacks with very high splash damage. This is home!

CAVE PAINTING: Does not attack, but greatly increases your score. Leave some doodles to keep future archaeologists busy.

The entirety of the next 48 hours would be spent tearing my hear out, trying to implement and fix gameplay mechanics, just to get to the point where I could put these quippy little unit descriptions into the game. So it’s a bit ironic that I ran out of time and had to leave them out, but them’s the breaks!

As for the mechanics of the game, I recognized three main options: 1. Enemies traveled down a path and your towers would snap to specific locations along a grid, but not on the path

2. There’s no grid; You can build units wherever you want, just not too close to existing units and not on the enemies’ path (this is the “bloons” approach)

3. There is no enemy path, and instead you have to create a maze for enemies to go through using your towers (which snap to a grid).

I really like option 3, but that would need the enemies to have pathfinding algorithms so they could find a path through any maze, and I thought implementing pathfinding would be too ambitious in 48 hours. Of course, now I realize that pathfinding is a standard part of haxeflixel, and would have been super fast to implement. Oh well!

Between options 1 and 2, I actually tried implementing both at various times, but ultimately went with option 1. This was partly because I couldn’t get overlap testing for circular sprites to work very well, and I don’t think option 2 is very satisfying with square-shaped units. Though part of me loved the disorganized look of cavemen not snapped to a grid…

Creating a grid was pretty simple; I just used something like _caveman.x = (Math.floor((FlxG.mouse.x)/20))*20. I picked 20 pixels as a grid size because I often make games in 320x240 resolution with pixels doubled in size, and the map in my notes was 12x12; so 12*20 = 240, my maximum game height.

I created the dumbest possible solution for enemy pathing: I just hardcoded rules that said, "if you've gotten to this coordinate, go up, then if you've gotten to this coordinate, go left," etc.

Having our units attack was a matter of recording the time each unit last attacked, then comparing that plus an attack delay against the current global timer. For each enemy, if the enemy is in range (discovered by comparing a threshold against the absolute values of the coordinate position difference, for both the x and y axes) attack it and set the time the unit last attacked to the current time.

Programming Time Wasted

On thing that was quite tricky was making it impossible to build towers on the path or in the menu area. Eventually I solved that by typing in a tilemap in terms of ones and zeroes & using haxeflixel's tilemap overlap testing, though I wish I had figured out how to just import a map from an image instead, since that would have been much faster.

Something else quite onerous was that I had decided it was necessary to give the player a visual indication of how much health an enemy had left. I tried a lot of things: creating an hp bar for each enemy (which didn't work because an enemy flxsprite can't have a second flxsprite as a member), changing the color of the enemies so they got darker as they got more damaged (which only worked sometimes and failed other times) and other stuff. I eventually gave up, and instead figured out a way to indicate that enemies were being damaged. (Make a "dark" animation that plays for 10 frames, and make each unit constantly check to see if it has finished an animation; if so, go back to the "light" animation).

The Art

My first pass was a colorful approach, but I quickly scrapped that in favor of strict black and white. I would have loved to create menu buttons that fit the black and white scheme and showed off the different units you could buy, but didn't have time; the premade haxeflixel buttons were the best I could do. Since I knew the units would be 20x20, I made them have a width of 20 and a height of a big more than 20, because it looks cool if units in front cover up a bit of the units behind them. Unfortunately, I never had time to implement sorting the units into layers based on their y-axis position, but that will be something cool to work on in the future!

After drawing the first enemy, which kind of looked like Cthulhu, I decided it would be funny to make the enemies be the inverse

What I would work on if I develop this game further:

The units
Make new towers
Economy & tower balancing
Visual indication of enemy damage (hp bar?)
Visual indication
Pause button
Ability to destroy towers
Custom menu button images
Fix display bug in buttons (sometimes buttons appear down when they should look up, etc.)
Fix bug that prevents "you win" screen from showing
Correctly order appearance of units according to their y-axis value (So closer units appear "on top")
Walking animation for enemies; idle & attack animations for towers
Tower upgrades (maybe)
Fix tower prioritization of enemies
Circular tower attack reticules