Brackeys 2025.1 Game Jam Retrospective

Introduction

One week, one idea, and an ambitious goal—what could go wrong? The game jam theme was "Nothing can go wrong...", and in true ironic fashion, I learned just how much can go wrong in the span of seven days. But despite the challenges, I came out the other side with a ton of new knowledge, a stronger grasp on game development, and a half-functional, fully submitted 'game'.

This is my retrospective on what worked, what didn’t, and what I’ll take into my next jam and beyond.

What Went Right

1. Pushing Myself to Participate

At the start, my only real goal was to participate. I wasn’t aiming for a polished masterpiece - just something playable and a chance to go through the full development process under a tight deadline. In that sense, I halfway achieved my goal.

I submitted a project that didn’t crash, supported both Android and iOS, had a working main menu, an intro scene, a pause menu, a few solid animations, and it even had sound effects and music. I also got a few unexpected compliments on the artwork, and that alone made it feel worth it.

2. Learning More in a Week Than I Would Have in Months

Game jams force you to move fast, make decisions, and solve problems on the fly. The intensity of the deadline pushed me into learning things fast. I tend to deep dive into topics before practicing them. This time I had no choice but to be practical and hands-on. That paid off more than I thought it would. 

• UI & Control Nodes: I was weak in UI systems before, but now I feel more comfortable with responsive and dynamic GUI layouts, control nodes, and handling input. 
• State Machines & Autoloads: I can now write up a StateMachine in my sleep - although now I don't have to that I can just copy paste.  I also have completely reusable SceneManager and AudioManager singletons that I can drop straight in to my other projects.
• Tweens & Lerping: I am all about tweening and lerping for physics dependent animations now. 

Even though the gameplay didn’t fully materialize, I now feel ten times more equipped to build my main passion project. I also feel like I've finally figured out a more practical learning process moving forward.

3. Pivoting to Art When Burnout Hit

By day four, burnout was real. I had spent the first three days crunching hard on the missile physics and UI integration, but I just kept hitting walls, I wasn’t making progress, and my motivation and confidence tanked. Instead of forcing myself to keep struggling, I switched gears to work on the art—and that turned out to be a great move.

• It let me keep working without mentally exhausting myself further.
• The game ended up with unexpectedly decent visual polish.
• It refueled my motivation, making it easier to return to technical work later.

Next time, I’ll intentionally plan for a “recovery” day mid-jam where I focus on something lighter like art, sound, or UI before going back to heavy problem-solving.

What Went Wrong

1. Overcomplicating the Missile Flight System

The biggest mistake? Spending too much time on a single mechanic.

I wanted a hand-rolled missile flight system that felt dynamic and semi-realistic. But what started as an interesting challenge became a bottleneck. I kept thinking, "I just need to solve this one last problem..." and before I knew it, days had passed, and I was still struggling with aerodynamics.

By the time I realized I needed to pivot, it was too late to redesign the core mechanic, and the gameplay itself didn’t make it into the final build.

2. No Backup Gameplay Plan

Had I planned a simpler backup mechanic, I could have pivoted earlier. Instead of over-engineering realistic physics, I could have gone with something more arcade-style and intuitive.

Lesson learned: Next jam, I’ll prepare a "Plan B" gameplay loop that fits the theme but is simpler, so if the main idea isn’t working by mid-week, I can switch gears without starting from scratch.

3. No Strict Milestones for Gameplay

I spent too much time on menus, UI, and polish before gameplay was functional. While I don’t regret honing those skills, I now realize that in a jam, gameplay must come first.

For my next jam, I’m setting a hard rules:

• If gameplay isn’t working by X time, I pivot or simplify.
• No menus, polish, or extras until gameplay is at least minimally fun.

Key Takeaways for Next Time

1. Set Clear Milestones & Deadlines
   • If a mechanic isn’t working by the midpoint, pivot or simplify.
   • Don’t get stuck solving one big problem. Break it into smaller, testable steps that build on each other.
2. Have a Backup Gameplay Plan
   • A secondary, simpler mechanic that I can fall back on if things go wrong.
   • Design for fun first - realism and immersion can happen later.
3. Prioritize Gameplay Above All Else
   • No UI, menus, or polish until the core game loop is working.
   • If I wouldn’t want someone else to play it yet, it’s not ready for polish.
4. Plan for Burnout & Work Smarter
   • Take one light day mid-week to reset (art, music, easy tasks).
   • Stick to a normal eating/sleep schedule to avoid crashes, and have plenty of healthy snacks on hand.

Final Thoughts

Even though the final game didn’t turn out how I wanted, I wouldn’t call it a failure. The real win was in everything I learned. Now, I’m walking away with:

• A stronger grasp on Godot and game development fundamentals.
• More confidence in UI, state machines, animations - and even my crummy art.
• A clear strategy for tackling my next jam.
• And most importantly, a fire to jump back into my passion project with a newfound skillset.

Next time, I’m going in with a plan and I’ll make sure that at the end of the week, the game is not just a collection of cool mechanics, but something fun to play!

If any of this resonated with you (or even if you just made it this far), I'd love to hear your thoughts in the comments and to play your game if you also participated in the jam! 😊