My first game jam - Godot Wild Jam #88

After waiting too long, I finally decided to take part in a game jam.

I’ll write down my reflections from doing it for the first time, so this post will be much less technical than usual.

Spoiler: it was satisyfing, sparking creativity, novel expierence.

Since this is long article, readers who wants to get an essence can jump straight into Summary or Tips sections.

Game jams

A game jam is similar to a hackathon in classic software engineering - there is a set of rules, a theme or main topic, and a limited time to create a game, concept, or prototype.

Sometimes there is a prize, but in game jams people mostly use them to make connections and build a portfolio.

Godot Wild Jam

Advertised as the biggest and longest-running jam exclusive to the Godot engine. The rules are pretty simple - create a game during the jam, either solo or in a team. It starts on Friday, and there are 9 days to finish the game, followed by another week to rate entries from other participants.

There is a theme to follow, which is selected by voting on GWJ’s Discord. Apart from the main theme, there are three wildcards - optional “mini-themes” to follow.

In the 88th installment of the jam, the theme was Momentum.

Visit official page for more info.

My jam participation

The funny thing is that earlier this year, when I had a lot of free time, I didn’t decide to take part in any jam. Now, with a little baby to take care of and being constantly in a rush and exhausted, I decided to enter the jam.

Given that I had very limited time to work on a game - usually 1–3 hours a day, broken into a few parts - I decided to go solo, so I wouldn’t block other people.

As this was my first jam, my goal was simple: to submit something playable that at least one person would find fun. Given that I’m terrible at art and sound, I decided to focus on mechanics and the fun aspect, and do my best in the other areas.

The idea

The jam began on Friday at 22:00 my time, and I didn’t have time until late Sunday night to sit in front of the computer and start development. That was unfortunate, but I could still do some thinking during that time to figure out what to build.

There were two main questions to answer:

1. A game that would follow the theme.
2. A game that I could code into a playable experience in about a week.

I actually had a lot of ideas for potential games that followed the Momentum theme, but the second point was really where most of my ideas were thrown out.

I had a few ideas for a sci-fi game set in space, but when I asked myself questions like “do I even know how to start?”, I discarded them.

One idea I particularly liked was about a spaceship with a broken main engine that could barely change its course. The player’s job would be to use gravity assists to travel to the destination. Maybe another time :)

Finally, I decided to go for a game about driving a train. 2D, top-down, with one core mechanic: drive the train to the station without falling off the tracks. The idea was that if the momentum is too high on a turn, the train gets derailed. Okay… so the train would be a rectangle, rails are two straight lines… OK, even I can draw that.

After thinking about it for an hour or so, I still liked the idea, so I decided to go with it.

The plan

As I was working solo and the project scope was small enough, I didn’t bother with game design documents or other semi-formal ways of planning. I decided to start with a prototype of the main mechanic - falling off the tracks when speed on a turn is too high - and if I could get it done soon enough, then I would plan how to make it work by the end of the jam.

Developement

Core mechanics

Even though the game is basically built around one mechanic, I struggled quite a lot to implement it.

Partially because I’m still learning game development and needed to do some reading first about things I hadn’t used before, but also because, well, it was harder than I thought.

I started implementation on Monday, and if I recall correctly, by Wednesday I had a very rough, untuned implementation of it.

To make the game actually challenging, I needed to add some behavior that would force the player to go fast. At this point I didn’t want to complicate things any further, so I used the simplest tool - an arbitrary time limit to complete each level. In addition, to make it a little more difficult, the train has to be stopped within a designated area. These two things took me another day to prepare.

Other stuff

Then I spent the final days on level design, the intro and outro, the game-over screen, balancing the game, and finally export and testing.

I knew that after the core mechanic was complete there would still be a huge amount of work to do, but I still underestimated it. That’s why, in the list above, there are no sound effects - I simply didn’t have time to add any sound effects or music. That’s my biggest regret, but even now I don’t know which feature I should have skipped to make time for audio.

The bottom line is that mechanics are just one part of the game when it comes to the time required to build it - at least for me.

Finalizing

In the last hours before the submission window closed, I was doing ten things at once - fixing bugs, testing the web build, doing some last-minute small changes, etc. Overall, it was very stressful, but I still managed to submit the project in a playable state, which was one of my goals.

Reflections

Now is time for some after thoughts / retrospective and lessons the the next time.

Programming

Well, this was the part I had the highest confidence in before the jam started, and now I’m not so sure about my skills. The fact that I’ve been coding professionally for almost 15 years didn’t change the fact that I’m doing completely different things in my daily job. Game development is different, the programming language is different, the standard library is different, and as a backend developer I don’t program UI or anything visible in a graphical way - while in gamedev this is basically everything.

Usually, when programming, I follow industry standards for software engineering - not blindly, but only where I see the value. These include things like automated testing, breaking work down into small, reasonably defined chunks, etc.

During this jam, I forgot most good practices and just wrote code of questionable quality to get things done. I managed to get away with that because the jam lasted only a week, so the project was fairly small and I still remembered most of what I had written before.

There were times when I rewrote or refactored some parts to make bugs easier to find or as part of making a bigger change from a first draft to something playable. For future jams, I’d like to keep at least the same, or preferably higher, code quality.

I also could have been better prepared - setting up a GitHub repo in advance or learning how to use one of the game templates would have saved me a lot of time. I ended up doing part of the UI and menus myself, which took some time, and there was also a bug I didn’t find before submitting the game.

On the bright side, I’ve learned a lot.

First, on the Godot side, I had to learn how 2D pathing works and how to make the train follow a path - but only until it gets derailed, at which point it becomes a RigidBody2D.

Second, I wrote my first shader, which I’m very excited about, because it’s something completely new to me and I find it very interesting to learn. I can’t make my games look good by drawing beautiful characters, but maybe with shaders I’ll be able to make them look like finished products instead of “placeholder” art.

Lastly, I had to develop the entire game end to end. Up to this point, I had mostly worked on mechanics, prototypes, or demos. This time there had to be a core mechanic, level switching, and everything else needed for a complete game.

Game design

I didn’t put much thought into game design; most decisions were made intuitively, like deciding to add a time limit to force the player to go fast.

Now, I don’t necessarily think that if I had researched or learned more about game design I would have made different decisions during the jam, but there is one decision that I find interesting in retrospect.

Once I decided on the core mechanic and had it more or less implemented, I prepared a level switcher and started making some levels. The thing is, I didn’t even think about other types of progression or game loops - I just defaulted to a level-based game. I think that’s partly because it’s the most common approach and partly because I had at least some idea of how to implement it.

In hindsight, I still think it was a good decision for a jam game. I prepared four levels, each meant to be completed within a few tries, with increasing difficulty. I even received one piece of positive feedback specifically about the levels.

However, for this game to become something more than a three-minute jam game, level-based progression is not going to work. It would be difficult to add more levels that would keep the player engaged. I know this is partly because I’m also completely new to level design, but the only reasonable way to have, say, 20 levels without boring the player to death is either to make the game extremely hard in later levels or to add new mechanics as the player progresses.

I don’t want to do either - especially adding new mechanics, which would blow the scope of the game to a size I’m not comfortable with right now.

So level-based progression was a good choice for a jam, but now I’m planning to rework the game into a run-based one. The player would go through a semi-randomized track with a time limit, and the goal would be a high score. This can significantly increase replayability without adding new mechanics or designing more levels.

Whether that’s a good choice, time will tell, but at least I’ll learn some new things by doing it. And then I can say the game is more or less complete - leaving it at four levels wouldn’t give me that feeling.

Art and sound

WWell… this is the most problematic area for me. I just suck at art. I can imagine myself trying to compose simple music or prepare some sound effects, but drawing… that’s something I simply can’t do. I’d like to improve in this area, but it’s constantly deprioritized — maybe because it feels so hard that I don’t even know where to start.

Because of that, visuals and audio were not my top priorities during this jam, but I still wanted to make something at least remotely pleasant to look at. I thought I had done a decent job for a beginner, until I saw games submitted by others. Even though I know many of them were made by teams with dedicated artists, I still had the feeling that my “graphics” were not much more than placeholder blocks used for prototyping.

But that’s a good lesson too — if I want my games to look nice, I either need to significantly level up my visual skills or collaborate with someone more talented in that area.

As for audio, I did want to add some simple retro-style music with a free license and a few sound effects for the train and derailment. Unfortunately, my schedule was so tight that I simply didn’t have time to do it.

Rating games

After the submission period ended, developers turned into judges and playtesters. Everyone had to rate a few randomly selected games before gaining access to the full submission list. I managed to play and rate 24 games out of a total of 155.

Overall, I was surprised by the quality of the games. I honestly expected much worse results — probably because I was comparing them to what I’m personally able to develop in just a few days.

Of course, some games were unfinished (like mine), unbalanced, or difficult to learn, but overall, among those 24 games there were many that were genuinely fun.

There were even a few titles where I spent way more time than I initially planned, simply because the experience turned out to be enjoyable or because I wanted to see what would come next.

To give credit for the best games, here’s my favourites:

• Dillard the Drunk & Flasky the Flask find a Fridge - jam winner - I was expecting it to win, it’s just great, polished fun and original experience. Worth checking out! Also creators were so nice, that they made code open source, so I checkout the code to learn how to build such game!
• Frostsphere - #1 in Theme category. It took me few mins to figure out how to play, but after that really fun and great implemention of the theme.
• Welcome to the dungeon - really fun idea!
• Critical invasion - for the x-com vibe!
• Akikaze - for peaceful gameplay

Jam community

The community was incredibly welcoming and kind. Both on Discord and in the game comments, all I experienced was thoughtfulness and genuine kindness. My game was clearly unfinished and in a mediocre technical state, but when people pointed that out, it felt like honest, constructive feedback on how I could improve things — not complaints or negativity.

Given how much hate and how many unwelcoming communities exist on the internet, taking part in this jam was something I’d genuinely like to experience again. It felt like being part of a supportive community, even as a complete newbie like me.

My game results

My game Derailed received 22 ratings with average of 2.948, which give it 84th position, so almost in top50%. I’m very happy with that, especially looking at score breakdown:

Looking at the table above, my conclusion is that despite having a pretty ugly (graphics-wise) and deaf (no sound) game, I still managed to make it somewhat fun, and the idea fit the theme nicely. That’s a great result for a first attempt. If I had more time to add some art, or if I teamed up with someone, the final result could have been even better.

This is definitely a lesson for the future: to rank high in a game jam, a game needs all rated aspects to be in good shape, not just the core mechanic.

Apart from the ratings, I also received comments on my submission, and I’m very thankful for all of them. Some provided valuable, actionable feedback, while others simply said it was a fun experience — which genuinely made my day. For future growth, I think comments are the most critical part. Ratings give you a numeric overview, which is useful, but the real emotions and experiences of other players are what truly help you make better games in the future.

Summary

To sum up this rather long read, I highly recommend Godot Wild Jam. I don’t know yet whether other jams are similar, but for anyone considering their first game jam: don’t hesitate - just try it.

Without this jam, I wouldn’t have created Derailed or any other fun project in the span of a single week. The jam forced me to focus on delivery. Even though I didn’t manage to implement everything I wanted, the experience was still incredibly valuable.

The themes are also great for sparking creativity. A game about driving a train is not something I would have come up with on my own if it weren’t for the theme, so it’s a great way to push developers into unfamiliar territory.

I hope I’ll find the time to participate again. In fact, GWJ #89 starts today, but I have to skip this one - maybe #90. Time will tell.

Tips for first-time-jammers

Please keep in mind that I’m not a game jam veteran, but some of these points may still be useful to others.

• Prepare upfront. The game itself has to be developed once the jam begins, but some preparation can be done beforehand. For example: create a Git repository, research useful plugins, or choose a game template if you plan to use one.

  • If jam is hosted on itch.io, read about butler and how to use it, especially if you planning to upload multiple builds

• Be active on the jam’s Discord. There’s a lot of valuable information shared there during the jam.

• Share your progress on Discord (if you’re comfortable with it). This has two benefits: you can get early feedback, and people become familiar with your game, which increases the chance of receiving more ratings during the voting period.

• After the submission period ends, rate as many games as you can. This is a way to give back for the ratings you’ll receive, and it’s also a great learning experience to see what others managed to build in such a short time. A nice side effect: it’s a lot of fun.

• When rating games, leave constructive comments. I received a lot of valuable feedback, as well as heart-warming messages saying the game was fun to play. Well-written comments often encourage others to check out your game and leave feedback in return.

• To rank high in jam results, your game needs to be solid in all categories. Based on my rough estimates, if my graphics and audio scores had been closer to my average scores in other categories, my overall position would have been significantly higher.

• If possible, provide web build. People (myself included) tends to rank games with web builds more often, because it’s more convenient and safe to play.

Resources

Maaacks game template

Godot Wild Jam

Godot Wild Jam Discord

GWJ 88 results

Butler itch.io tool

Changelog

10-01-2026

• added few more tips for first time-jammers
• wording