Ludum Dare 49 entry found here.
Play directly on itch.io.
Game source code found here.

Ludum Dare 49 ended at the start of last week and I wanted to take a moment to reflect on the game jam. This is my fourth time taking part in Ludum Dare, but third time seriously competing since restarting game development a year and a half ago. Now I think about it, Ludum Dare’s make a good unit of measure for how long I’ve been doing game development. When I started college in 2014, the drawbridge of game development was up and stayed up for five years. So I’ve been a serious game developer for 3 LDs now, or in standard units, 1.5 years.

Anyways.

Un’s Unstable Table was released to the world at 3pm, Monday afternoon, October 4th, 2021, for anyone that’s keeping record. The theme for this Ludum Dare was ‘unstable’. I’m always skeptical when the theme for releases because it’s always not the one anyone expects. But that’s not surprising considering the voting scheme favours everyones least-favourite positive vote. Our most favourite theme choices are probably the most contencious, whereas the ones we meekly accept as doable end up being the pool which we commonly all fall into. That’s my guess at least. Yet ‘unstable’ isn’t a terrible theme, and actually we generated a breadth of interesting possible games that would be worth exploring in the future. The one that really fell into place on the evening of the start of the jam was a play-on-words, a pun of you will, of interpreting ‘unstable’ as ‘uns table’ which then became ‘Un’s Table’. It still felt appropriate to build the theme into the game and not just the title, so the final game became Un’s Unstable Table. A 1-level fractal name it turns out.

I’ll give a short overview of the game, but the best experience would be to play the game yourself for a bit. This time our game is playable in the browser. The mechanic was inspired by pre-computer mapping technology used for war strategizing. Small figure models were made of soldiers and battle machines and moved along a terrain to keep track of everyone’s position. Generals usually pushed the models around with long sticks, presumably because the table was so big and it was hard to reach, not because it was fun. There’s a hilarious scene demonstrating an alternative way to push toy soldiers around in Black Adder. The idea was to blend this system with a real-time stategy mechanic and make the soldiers that are being pushed around actually shoot bullets and kill one another, turning the model into a reality. The instability of the game comes from the soldiers being physical objects, meaning that as you push them around the board they are liable to falling over, bumping into each other, or having flying debris floor them.

POSTMORTEM

So how did we do? At the time of writing this, we are at thirty-one reviews, with ten days left to go before the end of the review period. This means we have already exceeded our last review count and we haven’t being pushing hard to try and exceed it. In that sense, this has been our most popular game. For Ludum Dare 48, we barely managed to include audio into the game, leaving it until the last minute. This time, no audio made the cut at all. Overall what were the negatives? I think I’ll just list them:

1. We didn’t make a clear plan for audio implementation. I did record a large database of different drum and percussion instruments, but the recordings were crude to pre-process them in time to make any interesting game music.

2. The user interface of the game was messy and not thought out. There were bugs and visual glitches in the final release.

3. Unfinished mechanics such as riot-shield soldiers and flag-bearers which confused players because they looked visually different, but didn’t differentiate the game much.

4. Some levels were not playable for the way we had decided to make the real-time strategy mechanics work. After trying a few variations, we had settled on a periodic launch timer that meant every soldier would fire every thirty seconds. Other ideas were random soldier timers and random periodic timers.

Could we have done anything to avoid these issues? The main thing is that the negatives came from sporadic last-minute changes. last-minute changes is part of the organic process of making a game in such a short time period, but there’s a limit. For example, level 5 required a single soldier to be moved through a maze of other soldiers, which was a novel abstraction of our mechanic and harked back to level 1 that used a similar setup to teach the player to move soldiers. But it didn’t work with the periodic shooting system and left all the soldier encounters to be tedious and difficult. In the future, I would pre-define the types of interactions the game is going to have, and then use these as a set of constraints to build levels from. This means no adding of new mechanics to build new levels, but just working from the interactions you’ve defined at the start. For our game, the interactions could have been: pushable soldiers, two armies on either side of the table, obstacles, and first person with their flag-bearer knocked over loses. We made four interesting levels using these constraints.

The biggest time sink was working on the user interface. That didn’t just involve adding buttons, but dealing with scene transitions, level loading and unloading, and so forth. It wasn’t enjoyable to build. Saying that, I did like working on the Kim Jong-Un procedurally-animated talking face and it’s spewing of intimidating quotes. The game we did for Ludum Dare 48 didn’t have any menu-based user interface and that was much nicer to not have to worry about that. For future jams/games I’m going to think more about ways in which we can always avoid having menus. There’s a lot of games that do this now.

What about the positives? What did we think went well? Here’s my list:

1. We achieved a much larger game than any of the previous jams. Although we were about 3-4 hours away from completing every feature that we had wanted to, we almost scoped our game perfectly and knew our capabilities well.

2. Not only was the game larger, but the quality of the game was better than previous games. Attention to UI, textures, models, and post-jam screenshots meant that everything seemed polished and nothing felt like a placeholder asset or stood out of place.

3. We made a game that was fun! From watching people play the game, to reading reviews, to playing the game ourselves, I think we can conclude that the game has a replayable enjoyment factor. We failed with this in Ludum Dare 48 where we focused on the experience of the world the game was set in for most of the jam, and so when it came to deciding what the game was the player would do, the final result was rushed and unclear. Future note: it’s a game jam – make a game first.

4. Novel game idea. This doesn’t seem to be something we struggle with. Most of the first 6 hours of the jam was spent brainstorming ideas. We usually try to touch on a game that has a novel theme, an outlier interpretation of the game jam theme, and a new mechanic we haven’t seen in other games before. It seems like a tall ask, but we consistently have too many good ideas.

To conclude, it’s good to see that there is growth in our Ludum Dare entries. This only leaves me excited to see what Ludum Dare 50 will bring. I remember during Ludum Dare 47 we had just started to learn Unity and that was a major hurdle to overcome during fast game development. For the next jam, it would be nice to have worked on a new skillset that I’m hesitant with now, and bring this up to a level where I would be comfortable building something with it in 72 hours. This would avoid feeling like I’m just repeating standard game engine techniques I’ve already used in other projects.

Cheers.

---

All graphics and renders in this post were done by my brother.