My original plan was to make a game for the Compo format. I have participated in a some game jams a few years ago and I had always used Unity. Now I have my own game engine that I use for my tech demo projects, but for this Ludum Dare I decided to go with Godot 4.

When the "Limited Space" theme was revealed at midnight I began brainstorming.

My first idea was giving the theme a philosophical twist and making something out of the Augustinian theodicy: privatio boni, "evil is the absence of good" or "evil is nothing". I was thinking about the metaphore that a hole in a sock is not some kind of evil dark lord sitting where the hole is but the absence of sock. I thought about making a game where the lack of space is imaginary and the player had to figure that out.

This first idea went nowhere quickly, so I started thinking about doing something simpler. Then I had the idea of making a firework game where the player had a payload that can fit a limited amount of timed explosives (this is the part that fits the theme) and the goal would be to reach the end of a vertical labyrinth, and there would be different types of timed explosives. I had already practiced the physics part of this idea from Ian Millington's Game Physics Engine Development: How to Build a Robust Commercial-Grade Physics Engine for your Game book, which has example implementation code and a few exercises on fireworks, and it would be even simpler in Godot, since I don't have to implement all the physics engine code, all I had to do is apply impulses to the payload's rigid body. The reason I chose to use impulses and not forces is because I believe that impulses are more stable than forces in terms of simulation in a frame-by-frame based engine like Godot. In no time I had a working implementation of the physics part.

Now it was time to design how the player would arrange the explosives.

In the end I decided to split the timed explosives into explosives and fuses. The explosives would determine the impulse of the propulsion and the fuses would determine the delay until the next explosive in the sequence is detonated. The direction of the propulsion would be determined by the exhaust pipe the explosive came from. The player would place the explosives in the exhaust pipes, set an initial ignition fuse on one of the three exhaust pipes and then wire all the explosives together in the desired order with the desired fuses, each fuse would have its own delay.

By the time I came up with the design of the core mechanic it was already near the deadline for the Compo, so I changed plans and went for the Jam. I then realized I completely underestimated the complexity of implementing the wiring UI. The deadline for the Jam was nearing and I had only implemented the placement of the explosives and of the ignition fuses, but I couldn't figure out how to implement the dragging of the fuse wires. I was thinking about giving up on the game jam, but ultimately decided to try to aim for the Extra format deadline. In the end, I would be working on the wiring UI all the way until the Extra format deadline (disclaimer: I wasn't working on the game all day every day, but only a few hours per day).

I didn't have much experience with Godot, so what I ended up doing for the wiring UI was to manually write the code that decides how the wire tiles can be combined given a path. I was also going to implement a Dijkstra algorithm manually to have the wire follow the cursor, but thankfully I found out about Godot's AStarGrid2D class, which saved a lot of work. The only issue I ran into was that since AStarGrid2D was always computing the best path, the first explosives were always connected with a wire that went around near the center of the payload, thus not leaving any space to wire the next explosives. I came up with a simple workaround to this issue by implementing anchor points that the player could set while dragging the wires, so that the wire's path would always pass through the anchor points. In terms of AStarGrid2D, this means that now instead of computing a single path from the explosive's port to the cursor it computed multiple paths: from the origin to the first anchor point, then from anchor point and so on, and finally from the last anchor point to the cursor or the target explosive's port, and in the end all those paths would be combined into a single path for the wire. With this, the game was pretty much done.

Canceled stuff

I wanted to release an Android version of this game but ran into issues with the UI scale so I decided not to release it. I also wanted to make more levels but it would take time to calibrate them, so I only ended up releasing the game with one level.

Eye and ear candy for the explosions

With a few hours to spare and not considering worth it to invest them in level design, I added a particle emitter to the payload's rigid body that would emit particle in the direction opposite of the propulsion. I also recorded myself crushing a plastic bottle with the phone's recorder app, sped it up twice and used that as a sound effect for the explosion.

Music

Earlier this year I took up learning music theory seriously and finished Michael Miller's Music Theory book. I'm surprised how much easier it has become for me to quickly write a decent sounding song after learning music theory. I managed to compose a six measure long song in about half an hour. In the game it is a short loop that repeats over and over, but I don't find it too unpleasant to listen to even if it repeats. I think that this is because the song's notes are long and spread out. After analyzing it, I can say that it features a puzzle solving/focus mood, that it's written in the D Dorian scale, has a I-IV-V-ii-V-I chord progression for harmony, and is embellished with claps for percussion. This speaks to me that writing music really is more about following the rules of music than placing random notes like I used to.

Results

I submitted my entry very late and didn't have the time to rate and give feedback to many games, so I didn't get a score but I got some feedback. Thanks again to those who played my game and gave feedback. On a side note, I also want to thank my roommate, who was the first to play the game, for completely breaking the game and discovering mechanics I don't remember implementing. :laughing:

Usability issues

• Players having trouble figuring out how to lay fuse wires
• Players having trouble selecting the explosive port to start dragging a wire
• Players not knowing that each explosive only accepts one input and one output
• The editing interface is conterintuitive and setting the editing mode right requires too many clicks (can't edit fuses or wires without having selected a fuse or a wire in the palette even if pencil or eraser are selected, especially if the eraser is selected it shouldn't matter)

Technical issues

• Wire laying can bug out and crash the game
• The physics simulation is inconsistent, the same payload arrangement can result in different movements of the payload
• It seems that Godot doesn't have continuous collision detection, so it is possible for the payload to go through walls using the most powerful explosive and complete the level that way

Time spent

I kept track of how many hours I spent on making the game, but not too much in detail, especially during the implementation of the wire dragging UI. In total, I spent around 60 hours on making this game, most of it implementing the wire dragging UI. I spent 01:40 brainstorming and 02:25 implementing the physics part. I think I only spent about an hour on the music and sound effects. The tiles of the tileset for the game were made as I needed to implement their specific part in the game.