What joining a game jam can teach you about development

Introduction

I recently joined the Gamedev.js 2024 jam. My submission did better than I expected for a first ever entry. Coming in at place 68 doesn't sound like much but considering there were 233 submissions to compete with; Im rather pleased with the outcome.

In this article I would like to reflect on the experience, share some lessons learnt and how I think it relates to my everyday development tasks.

Always keep your eye on the requirements

Print them out in big letters and plaster them in a place you can't ignore them if you have to.

Every game jam has it's rules: on what you can use for assets, maximum sizes for teams and most importantly, how the submissions are going to be rated.
You might have a ton of ideas about what your game is going to be about but if you ignore the rules on how you should be implementing the theme of the jam, for instance. Your game is not going to do very well.

In my case I did add sound effects, and since Im not a sound engineer I sourced it from pixelbay. That was allowed. But I opted to not add a music track, even though I had selected one. My reasoning was that having hyped up music play in a loop might become annoying pretty fast. And adding an option to disable sound and/ or effects was an extra feature that I would have to add.

I kind of shot myself in the foot by making this decision, as sound was one of the things the games were rated on.

Dealing with deadlines

You have about 2 weeks to hand in your game. For a game jam that's rather generous, there are jams that last a few days.

Here are some strategies to consider:

Take advantage of tools you are familiar with

This jam will accept any entry that would run in the browser.
2 weeks is awfully short to write a game engine from scratch.
The usual suspects among the big game engines (Unity/ Godot) support the web, but..

I wrote a basic asteroids game in P5 as an example for a article some time ago, and used most of it as the 'engine' for the entry.
There's strict rules about submitting previous games, but I figured basing it off an existing sketch should be ok as long as the required jam theme is incorporated in a fitting way and while I still wanted to keep the feel of Asteroids, it's now a completely overhauled new game.

Some of the (better) entries I judged later on used starter projects from submissions entered in previous jams. The point is that you should allow yourself a bit of a head start by working with a stack that you feel comfortable with. If that is Unity for you, then go for it.

Focus on key features and quick wins

When dealing with time pressure its important that you know how to prioritise features. In my case the game has to have a few just be even considered a playable game:

• A goal to reach and reaching it ends the game,
• obstacles and enemies
• power-ups
• A power bar that depletes slowly as the theme of this jam was "Power".

I spent about a day with the particle system, getting the explosions to feel right, and another day just doodling game assets never to use them. Recognise none essential features and put a pin it if it takes too much time.

In the end I didn't get to put in half the features that I wanted. At one point there were even NPC's that would give side quests on the menu. But that's ok, I had a working game to submit. And that's something.

However I did break my personal golden rule: never add new features on deployment day, and it was a non critical feature. I wrote the 'black holes' feature with just hours to spare. It might have been better to focus on level design, but I felt the game needed something extra and having coded the physics for explosions just a day prior I was very confident I could also add the gravity effect in reverse without introducing game breaking bugs.

Keep it Simple

Yup, the KISS principle. As a frontend engineer I'm quite used to including a TypeScript compiler or transpiler, package bundler, linting tools and let's not forget a minifier. When I was reading the 'nature of code' in preperation for the jam, I almost scoffed, have we arrived in the stone age? when learning that all the examples were just a library loaded from a CDN and unprocessed JavaScript. But that's what I ended up using myself. It's very easy to set up and fast to run and develop on. There is no time spent on transpiling a bundle, because the code you write is the bundle. If you can keep the codebase very small it is a very efficient way of working. There is no build to speak of, and there is no obfuscation of the code so it promotes learning too. And I do have to say: it was a nice break that took me back to simpler times.

No one is an island

There was a discord channel where participants could share progress, ask for help or just hang out. There also was a channel to encourage other people to team up. This jam has no maximum team size. Although I certainly joined the channel, my only contribution was something in the lines of 'hello'.

Teaming up can give any project huge perks as everybody will have gaps in their knowledge and capabilities. I already mentioned sound not being my strong suit.

However I did end up opting to go alone on this one, mostly because this being my first jam I wasn't quite sure if I could deliver in time and I didn't want to drag anyone down with me.
There is also some overhead and challenges in working in a team that you do need to consider. That's mostly keeping up with each others progress and making sure everyone still agrees on the chosen direction.

That being said a team has the potential of producing results that are way more impressive than just a single dev can manage. Having this entry under my belt will give me and potential teammates the confidence that I will bring something to the table. So I think for the next jam one of my goals should be to team up.

Take your (mental) health seriously

Even if you don't need to worry about having a day job. Things can get stressfull, especially with the clock ticking.

• It's never a good idea to lose sleep, skip meals.
• Stay hydrated.
• Be aware of crunch time and how it might affect you and the people around you.

Don't be ignorant of politics

Once you make an entry, you get the privilege to judge other entries. Knowing the hard work that goes into making a game, you want to do right by your peers. But you also want others to notice your work and hopefully judge your work fairly as well.
Ratings by themselves are anonymous, but you get the option to leave a comment on the games submitted. And when someone left me a comment, I always checked their stuff out too.

Don't get overly defensive if other devs have remarks. Thank them and put it on the todo list if it has validity.

I noticed some devs that would leave the same compliment to a whole bunch of entries. Personally, I sometimes can't help to give some well meant pointers directed to help them out. Knowing that these devs get a vote, it pays out to keep any feedback constructive. Even with the best intentions, you can be too honest.

My grandma always said: If you can't say anything nice then don't say anything at all. And it's solid advice.

Final Thoughts

It has been a blast participating, I had so much fun. Do check out the game page and let me know what you think. Subscribe and be the first to check wether Ill get the kinks out.