You might be surprised to hear this, but I only recently completed my first ever game jam. For some reason, I had built game jams up in my head as this thing I would eventually do “when I was ready”, which is funny because the whole point of a game jam is basically throwing yourself into chaos and seeing what survives.
The jam I took part in was the ‘Indie Game Clinic COLLAB JAM 26’. This year’s theme was Self-Explanatory, and the rules made that theme very literal: no words, no numbers and no solo projects allowed in the jam.
So naturally, I recruited my lovely girlfriend as my artist. It was her first time doing digital art, so she was a bit nervous, but she was also happy to try something new.
By the end of the first night, we had our idea. We were going to make a simple puzzle game. It was going to be clean. It was going to be clever. It was going to be fabulous.
Obviously, this is where the mistakes began.
The Idea
The game idea was loosely based on the look and feel of ‘Inbento’ but with a new story and overall theme. At the start of the game, you are broke and your wallet is nothing but flies. But then something comes out of the sky, a way to fix your money issues. The Coal for Cash organisation has abducted you, but it's okay. Solving their puzzles gives you cash.
The concept itself was solid enough. It was small, understandable, and it fit the theme well. No words. No numbers. Just shapes, faces, matching, and solving.
The problem was not the idea. The problem was me looking at this “simple little puzzle game” and completely underestimating how much work it was actually going to take.
Mistake One: Thinking I Had Loads of Time
The first thing I did was open ‘Awesome Task Manager’ and start making cards for everything I needed to do.
Very responsible. Very organised. Very professional.
I started ticking off tasks one by one and making decent progress. Then, at some point, I looked at the remaining work and thought -
“Yeah, I could probably get the rest of this done in an afternoon.”
This sentence has destroyed more projects than any bug ever could. So, naturally, I downloaded Hoop Land, thinking I would just try it out for a little bit.
Skip forward a week.
The bad news was that no progress had been made on the code side, and I now had about five days left to actually make the game, but the good news was that my lovely artist had finished all the art.
It was officially go time.
Mistake Two: Forgetting That “Simple” Still Means Work
Once I got back into development, I started building out all the different blocks and their functionality.
This took longer than expected.
Of course it did.
The block logic had a lot more small edge cases than I originally thought, especially when it came to visuals. Some blocks needed different faces depending on direction. Reverse blocks had to always face each other properly. Everything had to read clearly without text, because the whole jam rule was that the game had to be self-explanatory.
Thankfully, I went with a data-based system, which saved me a lot of pain. I could add the faces in reverse order and tell specific blocks to use different face lists depending on their direction.
That made me feel very smart for about five minutes, until the next issue appeared.
Eventually, I got the core puzzle system mostly working as intended. Then I spent basically an entire day adding the “feel” elements: sounds, button movement, animations, feedback, and all the little bits that make a game feel like a game instead of a spreadsheet with sprites.
This part was worth doing, but it also ate up way more time than I had planned.
Which brings us to the final day.
Mistake Three: Leaving the Easy Part Until I Was Dead Inside
By the final day, the game was working. The feel was in. The systems were there.
All I had to do was quickly put the levels together.
Easy.
Except by this point, I had crunched so hard on Friday and Saturday that I had completely drained my motivation. The “easy part” suddenly felt like climbing a mountain while carrying a fridge.
I still managed to complete the levels, but they took much longer than they normally would have because I was running on fumes.
This is something I really underestimated.
Even if a task is technically simple, it becomes harder when you leave it until the very end, and you’re already mentally cooked.
Mistake Four: Trusting the Build Button
Finally, we were ready.
Four hours left before the deadline. I pressed Build and Play.
The build took 40 minutes.
Then the game launched and immediately threw a memory error.
Lovely.
I changed some settings, tried again, and lost another 40 minutes.
Still broken.
At this point, I had about two hours left and had no clear idea what was going wrong. From what I could gather, it looked like the issue might have been related to having too many levels, but there was no way I could rework the entire system with that little time left.
So, we made a team decision to submit the Windows downloadable version instead.
Thankfully, that built first time.
So technically, we submitted.
Victory.
A stressful, slightly cursed victory, but victory all the same.
Mistake Five: The Web Build Disaster
The first day passed.
No reviews.
The second day came around, and we finally got one.
The review mentioned the file size. Apparently, once uncompressed, the game was around 7GB, which is, to be fair, absolutely ridiculous for the type of game we had made.
The zipped file was only around 115MB, so I was confused at first.
Then it suddenly clicked.
I had copied the same compression settings I used for the pixel art over to the 1080p background intro and outro animations. That meant the game had around 100 uncompressed 1920x1080 images sitting inside it.
Very cool. Very normal. Very efficient.
Once I fixed that, the web build worked straight away.
So, the good news was that the problem was solved.
The bad news was that it was solved after people had already struggled to access the game.
Mistake Six, The Finale Mistake: Not Playtesting Enough
Once the reviews started coming in, another issue became very obvious.
The controls were a problem.
In my head, the input setup made perfect sense. You clicked and held to grab, and you clicked to flip, both on the same mouse button.
To me, that felt natural.
To players, it did not.
We got several reviews mentioning confusion around the controls, which means it was not just one person misunderstanding it. It was a design issue.
The annoying part is that I actually had an early warning sign. I got my little brother to play the game, and he struggled with the inputs. That should have been the moment I stopped and changed it.
Instead, I basically thought, “Ah, he’ll get used to it.”
That was the wrong call.
If one play tester struggles with something, pay attention. If that play tester is a child, pay extra attention, because they are usually very good at exposing what is confusing.
So, What Did I Learn?
Start strong and finish early
The biggest lesson is that I should have kept working properly from the beginning.
If I had stayed consistent during the early stages, everything would have been easier. I would have had more time to test, more time to fix the web build, more time to polish the controls, and more time to think instead of panicking at the finish line.
Leaving everything until the end does work sometimes, but it is not a strategy. It is just stress with extra steps.
Always playtest
This was probably the most important lesson.
The controls made sense to me because I built them. That does not mean they made sense to anyone else.
The entire theme of the jam was Self-Explanatory, so if players struggled to understand the controls, that was a serious problem.
Playtesting would have caught this properly.
Not theoretical playtesting. Not “I showed it to one person and ignored the result” playtesting. Actual playtesting, followed by actual changes.
A web build is basically mandatory
For game jams, a web build is not just a nice bonus. It is almost essential.
If people have to download a Windows build, unzip it, trust it, run it, and then deal with a massive file size, most of them simply will not bother.
A web build removes friction. People click, play, and review.
If you want your game jam submission to get played, you need to make it as easy as possible for people to try it.
Final Thoughts
Even with all the mistakes, I’m really glad I did the jam.
The game was not perfect. The process was definitely not perfect. The final few hours were held together by panic, compression settings, and questionable decision-making.
But we finished something.
My girlfriend made her first digital art for a game. I learned a lot about scope, polish, builds, and playtesting. We submitted a project that actually existed, which is more than can be said for plenty of abandoned ideas.
So, for my first game jam, I’ll take it.
Next time, though, I am starting stronger, playtesting earlier, building for web sooner, and absolutely not downloading Hoop Land halfway through development.
