Once again, a Ludum Dare game compo has ended. This means I spent this past weekend creating a game from scratch, and even though it’s a simple thing, I think this is the first time I can say I created a more well-rounded game experience for Ludum Dare.

The result is called Escape Enclosures Expeditiously (or Escape Drill in the improved, post-Ludum Dare version), and it’s a simple puzzle-like isometric game where the player should to the exit of each map without being touched by one of the enemies.

It’s a short game – only 3 levels (plus an ending level). Here’s a video of a full playthrough with no deaths.

But of course, this being a post-mortem, what follows is some more information about the game development process.

I started development without much of an idea of what I wanted to create. My initial approach – which is fast becoming my common approach for Ludum Dare compos – is to just try something different for the sake of learning, rather than actually trying to create a full fledged game. This means that my emphasis is normally on the technical side of things – as long as it’s new to me – rather than on the fun. It sounds harsh, but that’s what makes it fun to me.

This time around, I had my mind set on using Unity to create a custom level editor to make game creation easier. I was inspired by several different things: Hitman Go, a surprisingly simple but ingenious twist on the Hitman series; isometric turn-based games to the likes of Final Fantasy Tactics, Tactics Ogre and Disgaea; and a series of tutorials of someone recreating Doom’s classic E1M1 level on Unity using a plugin of some sort, something that showed me how powerful custom editors can be in Unity.

My goal, however, was not really to create a game in itself, but to learn how to extend Unity in a way that allowed that kind of map to be created more easily. I ended up with enough time to actually create some gameplay, but it’s almost a side effect.

What went right

Using Unity: in a previous Ludum Dare post mortem I mentioned Unity as one of the sore spots of my experience (although it doubles as one of the pros too). This time around, it shows exclusively as a positive point. I was able to leverage my past experience with the platform (as little of it as I have), work on top of what I learned (and side projects as usfxr) and basically spend more time implementing things rather than learning how to implement them.

That’s not to say there was not much to learn. Quite the opposite. At any point in development, I had dozens of browser tabs open with the most random items from Unity’s references or random tutorials, blog posts, and questions/answers pages out there.

What’s more, my conclusion is that Unity is pretty powerful when creating custom editors and elements. I can see how the ability to customize your working environment can be a big boost for developers working on a game, especially on members dealing with content creation such as level design. Even if my level design solution was pretty ghetto (I had the worst method for painting tiles with different terrain types, for example), it was still a pretty important time saver.

I still feel a little weird with the platform. Its emphasis on what I can only describe as concrete elements, such as adding scripts to physical objects and using the 3d view for everything, is still what feels strange to me. That, and maybe the emphasis on global access to everything from everything and a lot of helper functions to query the level elements. However, I believe I’m slowly learning to ignore my impulse for abstractionism and just get stuff done as inelegant as I might think it is. My hope is that with time I’ll understand what’s the actual ethos of the platform for performance and correctness, but I know I’m still far from that point.

Using simple assets: this time I purposely used very simple assets. The only texture used in the game was a 256×256 noise texture quickly created in Photoshop, and all the 3d models were simple boxes spliced and reshaped into basic shapes using Blender. I get very easily distracted into doing mundane tasks such as making sure none of my vertices are duplicated and everything invisible has a proper name or something of the sort, so I’m happy I managed to not spend too much time doing complicated art. I only had to deal with broken normals twice!

Conclusion

Now, what went wrong? Nothing, I think. This was fun, and I learned a lot. Given more time for level design and testing, I’m sure I could come up with more, and better puzzles. But that’s true of every Ludum Dare, so that’s something I can live with.