For this Ludum Dare, @alucardx60, @emelia-k and I created El Escubo's Key Quest, a game about a cube in search of his house key. This is the first Ludum Dare we've entered using the Godot Game Engine. This, combined with the fact that we haven't entered the past three Ludum Dares, means that we were bound to have issues.

The Good

The best part about this game is that we made it, and we had fun doing it. Despite being in unfamiliar territory with a new engine, we managed to make a fairly decent game.

I managed to put in an options menu, complete with rebindable inputs. Godot made this process a lot easier than I expected.

The art turned out very good thanks to the work of @alucardx60! It has a pretty cohesive pixel art style. Just take a look:

We ended up with music that transitions based on the area the player is currently in, and it works and sounds really good thanks to @emelia-k. Only issue here is that the music might desync a little occasionally. It only has one track, and you can listen to it here: https://soundcloud.com/emelia-kaylee/aperipheral

The Bad

Of course, with any game, especially a game made in 72 hours with sleep-deprived developers, is going to have issues.

The game was intended to be more open ended, and we originally planned to have four areas. However, due to time constraints, we ended up downsizing a bit. We also intended to have a raft item, but that also got cut.

Due to a weird mistake, when the player changed the music volume, an ear-piercing noise would play. We found out that at full volume the music volume was set to 10,000. The maximum volume is supposed to be one. As it turns out, the volume slider internally stores the volume as an integer between 0 and 100. We forgot to divide by 100, so we ended up with this: (100 master volume × 100 music volume) = 10,000 total volume, resulting in ear-piercing noise.

We were also going to have sound effects, but eh, it's not a big deal.

The Ugly

Now it's time for the really nitty, gritty, and dirty stuff.

For a top down game with jumping, it would probably have been best to use 3D collision. I didn't. Instead, I ended up using 2D collision. Because 'jumping' in a top-down game doesn't really make sense on a 2D plane, I had to improvise. I ended up with two different layers of collision. One layer the player collides with all the time, while the other layer the player only collides with if they are on the ground. In this screenshot, the purple squares represent the ground layer that the player can stand on. Note how it is one-tile offset from the ground and makes level design confusing.

Godot's tileset system is a little weird and it takes too long to make a tileset. Instead of dealing with this, I opted to use the Tiled map importer, so that we could create levels with Tiled and import them into Godot. It works, but it ended up creating as many headaches as it solved. I will probably just use the built-in tile system in the future.

Since everything is 2d sprites or tilemaps, we had to layer everything so that things made physical sense. If something was on top of something else, it had to be drawn on top of that thing. We ended up with a bunch of y-sorting and a weird tile layer setup that made things stupidly complicated. That, combined with the decoration layers, and a layer for ladder collision, resulted in this monstrosity: Don't even try to ask what each individual layer represents, I've already forgotten by this point.

Conclusion

Despite the issues that arose, everything turned out pretty well all things considered. We look forward to using Godot in future, for both Ludum Dare games and actual, longer-term projects.