This game was a submission to GMTK Jam 2024. The topic was “build to scale”. This was my first four day GameJam. It was a joined project with four people overall. You can also find the game on itch.io.
Making of #
In this post I want to share some details of the development process. I recommend giving the game a go before you continue reading. There are some spoilers in the Game Design section ;-)
Game Design #
The idea of the game is that you need to build up a tower using a robot to fight off hordes of enemies and collect resources.
Build to scale #
To honor the GameJam’s theme we wanted to have multiple scaling aspects in the game:
- building up the tower
- improving your robot to scale with increasing enemy difficulty
So we had two core parts of the game:
- The battle scene in which the robot has to face enemies
- The inside of the tower that is a shop view in which you upgrade the tower and the robot
Why build the tower? #
In an early version we faced the issue that buying tower upgrades was not really beneficial for the player. So why should they bother? Would they do it just for the sake of it?
We ended up on introducing a mechanic that forces you to upgrade the tower for every 5 robot upgrades bought in the shop.
We discussed other ideas of benefits the tower could provide but didn’t get around to explore those/felt they might not be strong enough. Some were:
- extending the range the robot could move away from the tower
- starting with very close zoom on the robot and zooming out more and more the larger the tower would become
Progression & scaling #
The enemies were supposed to start coming at the player a bit slowly in the beginning and then ramp up for a while without becoming completely unmanageable. This should scale with the player’s progress. Factors to measure the players progress we used are:
- Tower size
- Number of resources spent in the shop
Doing some research on functions used to scale game aspects, I found a nice post on the godot engine forum & a graphic calculator that helped me visualize different functions to use for scaling. I felt that an exponential function would lead to the player getting overwhelmed too fast. So I came up with using a logarithmic function. This ended up being a rather bad design choice. The enemies would trickle in too slowly at first, leaving the player a bit bored. However, then the rapid increase of the logarithmic function would kick in, often blocking the player from being able to return to the safe space of the tower. If the player was advanced enough though, they would manage this phase and afterwards the spawn rate didn’t increase much anymore. While I believe this felt nice after struggling for so long, it left things a bit boring and players were not likely get a game over after this phase (and we have such a nice dynamic “game over” animation!).
Project management #
In one previous 8h game jam we had explored a bit of collaboration. That instance we had decided to go for a mini-game collection linked by theme and a playable map. So everyone build their own project and at the end we combined them together. That had worked quite well. This time around we had way more time (4 days) and decided to go for one game with immediate integration.
We spent the first evening brainstorming ideas and coming up with way too large game ideas (we might explore them at some other point, who knows). We settled on a smaller game with “Vampire Survivor”-like mechanics.
We had a setup of four people: two doing programming, one focusing on arts and one person doing music and sound effects. For details on the music check out the following posts:
For programming, we did a mix of pair programming and then branching out on different topics.
We joined back for some pair programming sessions to design core mechanics or do some complicated late night coding.
We used git branches and pull requests to sync. Overall this worked surprisingly well.
Code-wise we had only little merge conflicts since we were able to work on mostly independent things.
The only thing that I found a bit annoying where merge conflicts in .tscn files,
especially the main level scene with the robot and tower was prone to these (although the robot & tower were in their own .tscn files).
We learned how to read these files a bit better but sometimes still had to fix things after merge conflicts.
Overall we produced 183 commits in 86 pull requests in four days.
Technical challenges & learnings #
We did upload a very early version to check if the Godot 4.3 WebGL export was working on itch.io. However, when we were 30 min away from the deadline and uploaded the finished game we realized that all the bells and whistles we added had significant performance issues. The background music was crackling, the game was lagging. Luckily, the deadline was extended by one hour giving us time to fix some of the issues.
As it turned out, the feature we used for the dynamic music generation didn’t work well in WebGL.
Seemingly, using AudioStreamInteractive or AudioStreamPlaylist causes the WebGL export to crackle.
The only way we could fix this in the short time was re-rendering all the audio files and using hard-coded audio files.
This resolved also some of the lagging. Overall we noticed that the game got smoother if you played a bit longer.