1 Game a Week – Week 8 (Ludum Dare 49)

Note: This post-mortem shows some solutions to the game’s puzzles. If you want to try figuring out these puzzle solutions yourself, please play the game before reading the rest of the post-mortem. I hope you enjoy!

Last weekend I took part in Ludum Dare 49, my first one since Ludum Dare 33 in 2015! Hard to believe it has already been 6 years since my first LD game jam. Realising how few games I’ve made in the last few years makes me wish I took part in Ludum Dare more, along with making more small games and prototypes, or doing 1 Game a Week earlier. Ah well…

I started the jam on Friday by looking at the different themes and trying to come up with ideas for each potential theme. I don’t think this is a bad idea in theory, but how I went about it wasn’t particularly helpful. I focused way too much on the theme and on trying to come up with an interesting interpretation rather than something I could execute. This meant that when the final theme was announced to be ‘Unstable’, I already had an idea for a game. Unfortunately, it wasn’t an idea I could do justice.

I spent Saturday and some of Sunday morning trying to create a game where you fly an airplane by controlling the left and right engine throttles. I wanted to make a game where controlling the plane felt unstable. In reality, you can technically fly some planes with just the throttles, but obviously it’s a lot easier (and safer) to use the control surfaces. I leaned too hard into the “simulation” feel, and the game was just dreadful to play. I had to pull the plug on it on Sunday morning and come up with a new game on the spot, I would have actually felt bad if people had to play this.

Hard Controls + Janky Physics = Bad Game

This was a risky game to make in such a short amount of time, and I’m sure it’s possible to release a good game with this idea. It’s essentially 3D Flappy Bird in a way, so a more arcady flight model could have helped. Even if I had the controls working though, I’d need to figure out the goal of the game and add polish all on Sunday. I really wasn’t enjoying myself at this point, so I scrapped the game.

There were only 10 hours left until compo submission hour, so I wasted no time making a new repo. I’m glad I made a template script earlier in the week that sets up a project skeleton and sets up a GitHub repo automatically, which saved me some time.

I wanted to make something with the simplest movement mechanics possible, so I elected to use a grid-based movement system since it’s trivial to implement. I actually got movement working and then the walls before I considered what the game was actually going to be.

Since the theme was ‘Unstable’, it made sense that there would be an unstable floor. But I think just having the floor collapse underneath you is boring by itself, so I had the idea that you need to shoot down the walls to get through the level, but doing so destabilizes the floor around it. If you walk on an unstable floor, it turns into a pit. If you walk into a pit, you need to restart the level! This took me 2 hours in total to make, since all that’s happening is I’m swapping out game objects whenever the player walks over a floor tile or a bullet hits a wall.

First Gameplay Demo

I actually thought this was fun by itself, but knocking down adjacent walls just felt like there was no strategy to it. The two other mechanics that I added are quite subtle, but I think they add depth to the gameplay.

First, I made it so if a wall collapses and there is a damaged floor tile beside it, it becomes a pit. This means that if a player just keeps on destroying adjacent walls, they won’t be able to just walk through them since the floor will have also collapsed.

The other mechanic was to make it so if you destroy a wall, the tile 2 spaces behind it is also damaged. This meant that which direction you shot the wall from would be important. The biggest problem with this game is actually explaining these mechanics, as it was difficult for a lot of players to figure this out. It could have been improved with better visual feedback and some smaller showcase and tutorial levels leading up to the bigger levels.

Level 1. Notice the extra floor tile being destroyed behind the wall.

Once these mechanics were implemented, all I had left to do was make some levels. For once, the programming was the easy part. I’m not that used to level design in general to be honest. Almost all of my games are arcadey and are set in an arena, or a ‘prototype’ level to show off the mechanics. I’ve also never made a puzzle game before, so this was all new territory for me from a game design standpoint!

My process for making the levels was to essentially just show off the mechanics that I implemented. For example, the second level was designed to show off the adjacent block breaking mechanic, as well as the mechanic where the tile 2 blocks behind the wall breaks.

Level 2. Notice that one failed run shows that the floor tile breaks 2 tiles behind the wall. While the other failed run shows what happens if you break a tile beside you while standing on that tile.
Level 2 solution. Notice that you need to shoot the top tile from behind, so that the tile breaks towards the top of the level instead of breaking the tile beside the flag.

I originally thought this was a good level to introduce the mechanics. But when players got to this level, a lot of them got stuck. I didn’t do a good job of explaining the mechanics. I’m sorry that they dropped the game at this point, at least this was a good learning experience for me.

I focused too much on showing off two different advanced mechanics in one level, instead of breaking them into 2 easier levels before they got to this one. Some players did figure it out though, and they seemed to enjoy the rest of the game, even though Level 4 was designed to be very difficult.

Outside of the difficulty curve, other criticisms were the lack of audiovisual feedback and background music. I fully agree that this is a valid criticism, I personally think music and audio is an underrated part of a game’s design.

If I had more time, I would have definitely put in background music and better audiovisual feedback into the game. I also would have changed the sprites for the damaged floor and pit, as they’re too visually similar and noisy. I think this would have actually made it easier for the players to learn the mechanics of the game. Having a floor collapse with a distinct sound effect and animation would have added context as to what was going on, instead of just a sprite change.

What went well

  • I was able to make a game in 10 hours that people seem to like.
  • I didn’t spend too much time on up-front design. I let my intuition and the jam theme guide my design decisions.
  • The art does its job and was quick to make. 1-bit is a great art style to go with for quickly developing a game solo.
  • I was able to implement the mechanics very quickly, leaving enough time for level design.

What could have gone better

  • I should have committed to abandoning the aircraft game earlier, I had very little time to make the game.
  • The lack of Music and SFX really kills the mood.
  • The difficulty curve is too high. Players were given difficult puzzles to solve without enough information on what the mechanics were.
  • More levels and mechanics would have really elevated the experience.

What I learned

  • For prototyping, I need to iterate ideas very quickly and fail fast. The aircraft game realistically should have been abandoned super early.
  • Bad tutorials or instructions can very easily prevent players from enjoying your game. A smooth difficulty curve and pacing is crucial.
  • Simple game mechanics can actually open up a lot of gameplay depth. If I was to just make block types that break tiles in different patterns, immediately that opens up a lot of different level ideas.
  • Some players will find a better solution to a puzzle than the one you intended. A rating system in the game could be a fun way for players to compete for better solutions. Alternatively, a “developer score” would be a fun goal for players to try and beat.

Summary

Despite the rocky start, I had a good experience with the game I released this weekend, and I also got a lot of great feedback! Unlike my other games for 1 Game a Week, I have a good idea on what to improve in this game. Thanks to everyone’s feedback and kind comments, I really feel like this would be a good game if it was expanded upon. I think I’ll make a bigger version of it at some point in the near future. I really forgot how much I enjoyed the Ludum Dare experience, I won’t make the mistake of waiting 6 years to release my next Ludum Dare game.

I want to thank everyone who played and rated my game so far, it’s been great! ❤️

Bonus Image! Original Level 2 design from my notebook

As always, if you want to try out the game (and rate it!), the link is right here:

RUIN ESCAPE

“Escape from a crumbling ruin, by ruining it even more!” A game made for Ludum Dare 49

Available now to play on your browser

If you wanna play around with the code, I also have a link to the GitHub repo if you click here!