Ludum Dare #27 postmortem: Core Defense

A game about defending the core

The 27th edition of Ludum Dare ended almost three months ago, but up until now I’m able to write the participation’s postmortem. A health issue pulled me away from the competition, and ultimately, from the blog too.

As you remember, the theme was ten seconds and as soon as it was announced, my brother and I started brainstorming ideas for a game that matched the theme as close as possible.

We ended up making a game prototype in which the player must defend a core during two minutes straight. Every ten seconds a new enemy spawns, immediately moving towards the core. If an enemy crash into the core, this will receive some damage. If an enemy hits the player’s character, this will lose a life. The game is won if both the core and player’s character survive after the two minute window.

The good

The source code is better organized compared to games from last participations. The idea of creating a gloabl object store worked very well for the times we wanted to modify the position or the movement of a given object based on the state from other objects.

A hash for storing the scoring information, character’s health status and other relevant data to feed the HUD is very useful, more if you want to modify the character’s health when it was hit by an enemy.

We have been careful not to use global variables at all. Despite that, these hashes can be used from almost any part of the codebase :). Moreover, the start, you won and game over screens are better implemented compared to other games we made. We also added sound effects for when an enemy hits the core and when the character’s destroys an enemy.

This improvements were only possible beacuse of the devotion and hard work my brother puts into trying to finish this prototype. I think he was resposible for 90% of all work done. Having been alone, I have had to abandon. Thank you so much @davix1228!.

Finally, we learned how to use a very useful concept on game development: Tweening. A tween is an object used for define automatic animations. In other words, when you define a tween for a given object, you define a starting point, an ending point and a math function which dictates how the object should move from the starting to the ending point. Tweens were used in-game to animate the enemy movements.

The bad

The first problem we faced right after the competition began was the lack of ideas. We spent all Friday night and all Saturday morning thinking but nothing came to mind. We hoped ideas will come after the sleep break but this wasn’t the case. It was Saturday afternoon and we still had no idea what to make.

The second issue was we couldn’t incorporate acceptable sprites to the prototype, just an improvised background. This prototype lacked sprites for the character, the enemies and the core. They are just color boxes and a circle in the middle of the screen for the moment.

Finally, we had a problem detecting collisions between the character and the core. We don’t know how to handle collisions when objects rotate on themselves. Probably, it’ll be something we have learn on the next Ludum Dare editions.

Lessons learned

Graphics and sprites are a fundamental part of videogames, they simply cannot be missing. Thus, I think is a good idea to add simple graphics and sprites to the game early on.

Regarding the issue related with the lack of ideas, I think this is happening not because ideas are not flowing but because we want to come up with the perfect idea. The solution is simple: brainstorm ten ideas and just pick one of them. Period. The sooner you do this, the better. The important thing is not to have the perfect idea but an idea, whatever it is, and turning that into a game in a weekend.

This time I wasn’t able to create the timelapse, but you can play the game here.