I want to thank everybody who tried out my Ludum Dare #18 entry, Infiltrator. In particular, special thanks to those who took the time to comment and vote on my entry. You can still play/vote for my game right now, just click on the banner!

This was my second Ludum Dare, and despite the warnings from senior Darers plus my own analysis of my previous performance, I ended up making a few old mistakes and plenty of new ones. I’ll cover that in…

ChainedLupine’s post-mortem for Ludum Dare #18: Infiltrator.

First 12 hours – Friday night to early Saturday morning

Friday was relatively uneventful. When the theme was announced, I knew that a majority of the games were going to try to use enemies literally was weapons. I wanted to try a more subtle approach, in that the player would not have a weapon of his own save his cunning and speed. The first thing that popped into my head was an infiltration game which relied upon stealth. The player would never directly pick up and use a gun, but instead would have to use his wits to survive.

I didn’t even need to do much idea sketching; My idea was a top-down game, using beams of shadow as a place to hide, plus a visible sight cone that would indicate where the enemies were looking. More ideas naturally came from this: Doors that needed enemies to be unlocked, holes that they could fall into, mines to step on, automated sentries that could be reprogrammed and utilized against enemies, etc. It wasn’t hard to fill my notebook with ideas.

The problem was choosing ideas that would be doable in 48 hours.

I decided that this criteria was important for my game:

• Working game-play. I didn’t want a repeat of my LD#17 entry, where the game was visually complete but not very fun due to running out of time to implement core game-play.
• Having more than just one or two levels, but a complete map that folks could explore.
• Completed and stable bumper code. I call bumper code all the pre- and post-functionality of a game. Title screen, level selection and transition, etc.
• Finish art/sound early in the development cycle.
• Have a series of building blocks that I use in a level editor in order to construct the aforementioned wide and expansive levels.

All of these I accomplished save the second. I ran out of time, due to the abundance of ideas and the complexity of implementing all of the last requirement. Building blocks are nice and open up possibility, but I learned the hard way that Infiltrator was at its core a puzzle game. And a puzzle game is very difficult to do in 48 hours unless it’s very simple.

I started to write the code for the game. This wasn’t difficult, as it was fairly simple. The primary difficulty would be in fine-tuning the game-play so that it was fair but flexible enough. Within an hour, I had a simple level displayed onscreen.

I spent some time making pixel art. Creating the over-head perspective man character was going to be simple; I intended to reuse that sprite extensively by re-coloring it programatically. After animating the sprite, I created some basic level tiles. I probably spent an hour tops on both of these tasks combined, and I am glad I did. I would later have very little time to spend on assets.

At the end of the first day, I had most of the game-play mechanics in place. You could run around in the level, attract guard’s attention, lead them to each other, and then get them to kill one another.

At this point, I decided to sleep, to prepare me for the largest phase: Finishing the bumper code and adding the rest of the game-play mechanics.

Next eighteen hours – Saturday noon to Sunday morning

This was the gritty time. I had to write all of the game-play features and finish the bumper code.

Once I had the core level parsing system in place, I decided to create a “How to Play” tutorial level. Perhaps this wasn’t all that wise, considering how I would end up running out time on Sunday, but I knew that the game’s objectives wouldn’t entirely obvious from the start, and it would be good to give the player a fairly calm level in which to test the game-play mechanics out.

The bumper code was easy to do. Tedious, but I had already thoroughly tested the system for switching levels during the creation of such system. I added a timed-score mode that eventually would not matter much. Unfortunately, the timed mode didn’t fit in with the radical change of level design that occurred on Sunday.

By the end of Saturday, I knew had a really solid and fun game. I was quite excited, and my brain was filled with ideas. It was then that I started to consider switching from a linear game to a more exploratory style level design.

In the final hours of Saturday, I spent a lot of time implementing tanks. I wanted there to be a heavily-armored enemy that could not be easily lured to death by the player. It would require a massed effort in order to take down a tank, via scripted level objectives. I ran out of time to put these script hooks into place, and in the end just used the tank like a nastier, meaner form of a soldier. By having mines destroy it instantly, it wasn’t quite as deadly as I intended.

Final ten hours – Sunday morning to Sunday evening

For designing levels and basic tile-map editing, I used a program called Flan.

Here is a screen shot of the first level I made for Infiltrator:

I wanted to keep the game as data-driven as possible. So all level control logic occurs from the level itself. Two tile-maps are loaded. The first is the displayed level itself. This contains all the necessary collision/shadow information for the entire level.

Next is a control level. Tiles are placed in this level to control how the level responds. “h” is a hole, the crate icon places a crate, the “s”/”sg” tiles place soldiers (or soldiers with guns, respectively). Surrounding the enemy tiles are toggle logic for the enemies, such as their initial facing direction and what team they belong to.

The idea being that once all of this was in place, all I had to do was spend the last ten hours or so making levels. Unfortunately, I only realized during that final ten hours, I had over-allotted the amount of content and under-allotted the time needed to complete levels based upon it.

In the end, level design was my downfall. I had a great series of building blocks, but not enough time to assemble them together!

It also didn’t help that I made a few last-minute design decisions which required me to swap out of level-editing mode and back into coding. For example, I had originally intended the game to be linear. You just progressed from level A to level B, until level n, when the game would end. But as I was making levels, I realized that a more open structure would fit the game better. So in the end, I didn’t actually use much of the time-trial code which I had put into place on Saturday. Only the secondary levels which can be accessed from the main base are timed.

The only purpose for those levels ended up just score-related, when in reality, I had wanted to include a story and a set of objectives. But, again, too much I wanted to do, and not enough time.

So, that was that. I finished up the final levels, packed it up, and posted it on the web page as an entry.

What went right

• Actually finished it.
• Feature-rich game for such a short time.
• Emergent game-play made it fun, according to those whom I had test.
• Finished most of my objectives concerning this Ludum Dare.

What went wrong

• Too broad of a scope for a LD48 competition.
• Not enough time allotted for level design.
• “Wouldn’t it be cool if…” interfered too much with core objectives.
• Spent too much time testing out components that would never be fully utilized.

Tags: LD18, post-mortem