Wilford - a post mortem

I recently participated in Ludum Dare, by making a game in 48 hours (or 72 if you want to work as a team) based around a theme chosen by the community. Creating a game in such short time challenges a person a lot. In this post I'll try going over the process, how I handled it and what I've learned.

Two choices

Things kick off at 3 in the morning in my timezone so I just got up at my usual time. This was the 3rd Ludum Dare I'd planned to participate in. The theme that was picked for Ludum Dare 47 didn't inspire me at all so I was very curious to see what the theme would be this time. It ended up being "deeper and deeper". This was a perfect theme in my opinion. It's simple and leaves a lot of room for interpretation.

When I discovered what theme turned out to be I immediately thought of 2 things.

The first was the 2nd level in a game I grew up loving - Battletoads. Specifically level 2. This level scrolls down vertically while the player dangles on a rope. The theme would be a great suit for my own take on this mechanic.

The 2nd choice was doing a top down game that controlled like Bomberman. I was thinking I could add some rogue-like elements in it. Just enough to make it interesting though not enough to make it an actual RPG.

I chose the latter option as I couldn't think of what challenges the player should face in the first option.

We don't need no plans

I've always had difficulty planning things out well beforehand. For all projects there are just so many variables that it feels impossible for me to keep track of everything. Often I tend to just throw myself into things instead and take one thing at a time. This works most of the time. Experience can mitigate the effects of poor planning - but it can't eliminate them.

All I had was a rough idea - a top down game where you could mine for gems, 3 simple enemies and an exit somewhere random in each level.

My previous entry, Eggbert, was a game I winged as well. I purposefully kept the game very simple and I ended up being able to adjust the gameplay while working and still have enough time to craft an overall experience. I thought "it worked last time, it'll work this time". Well...

Coding

I anticipated the most time consuming part of the project would be the code so I got started on that first. At first I tried to program the player's movement by having variables keep track of how much the character should be moved when a button was pressed and such. Then I realized that in the tool I use to make my games this was already done beforehand and could just be applied to the player character.

Everything in my game had to function in a grid as was often the case in older games. I'd decided that I wanted a mining theme in this game. The player would be equipped with a pickaxe that would both serve as a weapon and a tool. Because the pickaxe would work as a weapon the player would need to be able to determine the direction it was swung in so as to be able to hit the monsters. I thought of another classic game I loved called Startropics. In this game you could tap the direction button to change direction, and hold it in to move. I spent a lot of time trying to get this to work, and I kind of did. Unfortunately the movement was very restrictive. You had to first change direction with a tap, and then hold it in again to move. This made movement very cumbersome. By this time I had already spent way too much time on this and I decided to move on to other things instead.

Monsters

Of course a game is nothing without something to try and prevent you from succeeding. I decided on 3 enemies:

• Enemy 1 - walk around at random and bite the player when close enough
• Enemy 2 - an enemy that would charge at speed if it could see player in a direct line horizontally or vertically (like the tower piece in chess)
• Enemy 3 - a simple enemy that would shoot projectiles

Enemy 1 was rather straight forward. I just made it walk in a random direction at random intervals. I figured I'd implement the biting mechanic later.

Enemy 2 was the one I spent the most time on and eventually didn't include in the game. I programmed away and it was all very cumbersome to get working. I suddenly remembered reading about something called states. Basically it's where a character has different states that each have their own behavior and certain conditions to enter or leave a state. Here's some pseudo code to explain the behavior I intended:

I had everything working, except the line marked in red. I spent quite some time getting it to work and eventually decided I couldn't get it to work in time. For that reason I decided to throw this enemy in a corner and save it for another time.

The 3rd enemy would just be one that shot projectiles at the player. I reused the code from enemy 2 but instead of requiring a direct line, horizontally or vertically, I'd just have it shoot at the player in any direction as long as there was clear space between them. Since the player's movement in a grid system isn't that fluid I chose to keep the anger mechanic from above. When the enemy grew angry enough it would shoot, and go back to roaming randomly if the player went out of sight.

Level structure

The original plan was to have random level generation. I'd worked with this a little before and got it working so I figured I could implement it here as well. When I opened the tech test I did on this from a year ago I discovered I couldn't remember how things were put together (in concept yes, but not in code). I browsed around on the internet to see if I could find a quick solution. What I found was that I'd have random premade chunks of 5x5 tiles appear in the level. It was somewhat fast to implement, although due to time constraints I'd hardcode the chunks instead of making up a fancy system for it.

Crossroad

At this point I'd spent 95% of the time on coding the mechanics and honestly I didn't find the game that fun. I started to panic little bit. I wanted to have both a title, game over and score summary screen and at this point my game still consisted of nothing but colored squares and no sounds.

I briefly considered not finishing and participating, and instead offer my music writing abilities to someone else. As I was considering this I was contemplating about the future and how I'd regard myself if I gave up. That road felt incredibly unappealing. I've gone down that road many times when I was younger and I decided I wouldn't have it. It's normal for games to feel incomplete when made in such a short time span. I imagined the game appearing next to Eggbert on my Ludum Dare profile and decided that this future felt a lot more appealing so I decided to submit the game no matter how I felt about the quality of it.

Last sprint and design fun

If I recall correctly I had about 9 hours left at this point. Throughout the weekend I'd been contemplating who the main character would be. My initial thought was to just have it be a cat but I felt like that'd be a bit too generic. I spoke with a couple of friends here and there to get their suggestions. I knew I wanted the main character to be an animal you wouldn't typically see underground. Suggestions like lion, giraffe and others came up.

Eventually a good friend suggested it could be a kangaroo, and I suggested he could stuff the gems collected in his pouch. I wasn't sure though, a kangaroo would be hard to draw using just 16x16 pixels. After a while I figured why not just have it be a wombat instead? They have pouches too and they're cute. And that's how Wilford the wombat was born. Obviously he had to wear a hardhat. I added overalls as well because that's the first piece of clothing I think of when I think of hard physical labor.

All weekend I'd be listening to the work of David Wise who did the music for games like Digger T. Rock to inspire me. I quickly wrote some music that I felt hit the mood I wanted in the game, and added all the effects and such I wanted.

I needed some animals as the enemies and thought of the salamander and wasp (wasps may not be found in caves but it's my game so cave wasps are a thing now). I wanted them to have graphics for multiple directions like the player, but decided against it due to time constraints. I quickly traced the handdrawing seen above and added a title screen with instructions and an end screen showing how many gems were collected. Then made sure you could transition between them.

Lessons learned

Plan ahead

When I was contemplating quitting I could see how planning would've helped me not end up there. I now think back on conversations I've had with friends. You're not supposed to have the whole project in your head. Break things down and map them out one at a time. I've even done this in other contexts, but like anything in life: practice makes perfect.

If you struggle with something in life it's probably because you don't have the tools you needed. Someone else does. The chances of you being able to find a way to acquire these tools are very high. Personally I will probably take an online course in game design.

That said I'm very pleased to have actually finished the entry an submitted it. The reactions to the game have been overwhelmingly positive, which I hadn't expected. I didn't think it was very good, but peoples' reactions made me realize there was potential and I might just turn it into an actual game.

If you're still with me, thank you for coming by and reading through all this :)