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!

1 Game a Week – Week 4 (Stop Waiting for Godot Game Jam)

This weekend the Stop Waiting for Godot Game Jam is taking place. I was away for most of the week, so this seemed like the perfect opportunity to learn some Godot, make my 1 Game a Week game, and participate in a game jam all at the same time!

So with all of my excitement and ambition, I made a game where you eat your own shit and die.

I regret nothing

Why did I make this, when I could have made anything else? Well first, I tried to implement footsteps. When I tested them, I thought it looked like the slime was shiddin’. Then I thought it would be funny to add a fart sound. Then I realized that the game was basically designing itself. Now this game exists.

What went well

All joking aside, I actually like the game. I actually got to make a fun unique idea (although the idea of “eating” games isn’t original). It’s very simple (which is aligned with the game jam theme to “Keep it Simple”), and it’s kinda fun actually. I think if I wanted to expand the idea I’d like to add powerups like stomach medicine that stops you from shiddin’ for a few seconds. Maybe you could even pick up a bucket that lets you clean the shid from the level? There could even be a spoiled food hazard that makes you shid at twice the rate. But thankfully, I stopped at the game MVP.

What could have gone better

Honestly, a lot could have gone better. If I had a better idea I would have made it. I actually scrapped my first two ideas (a Pong clone and Sokoban clone) because I found implementing them boring, and I hadn’t quite gotten my head around Godot, so the code was a total mess.

This is a lesson I learned while making SPROUT. In a game jam, it’s sometimes worth dropping and restarting if the idea you’re making isn’t panning out. Thankfully the fart noises and the pure concept of this game entertained me, so I was able to find the motivation to finish the game this weekend. Next weekend I’m doing nothing and I’ll have my game finished for Friday 100% definitely.

Also, if I wasn’t making this game for 1 Game a Week, I actually would have given myself Monday to polish it too. But here I am, sticking to my deadlines. So the game definitely could have had more content or polish, but I’m pretty tired of working weekends.

What I learned

I learned a ton! How to make a simple game in Godot being a start, which was the point of the jam. I also feel like I’m starting to re-learn how to write code quickly to prototype mechanics. For a long time I’ve been focused on writing “good code” that takes ages to complete, but now that I’m making games in shorter time frames again I find myself getting used to the idea of making something quick and dirty.

While I’m not a huge fan of GDScript (or dynamic languages in general), I do like how I was able to setup input and movement code with very little difficulty. Also, the fact that Godot has a “move_and_slide” method that handles collisions and sliding against objects for you is absolutely fantastic. I’ll need to get something like that for Unity. I don’t want to spend a week on basic platformer mechanics again…

From a game design perspective, I also feel like I’m learning how important audio and sound is to an experience. This is carrying on from my experience with last week’s game where I played around with audio to make an underwater ambience scene. Adding a fart noise sent me down a path where I had fun and made this. So the context of the game led me down the path to developing these gameplay mechanics, instead of me coming up with the mechanics first.

Summary

I think the main thing I want to take away from this game is that I should give myself more room to make weirder projects. I should just throw shid at the wall and see what sticks. In saying that, I don’t want to make any more shid related games for the time being.

I’m looking forward to next week! I’ll take Monday off, but will give myself 4 days to make my next game. I think I’ll try to be weird with it, and will try to iterate more. I’ll also be back to Unity, so I’ll be in familiar game dev territory.

Thanks a lot for reading my post-mortem on my 1 Game a Week / Stop Waiting for Godot game!

As always, if you want to try out the game, the link is right here:

1 Game a Week – Week 4

eatin, shiddin and fardin

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!