All Systems Go Retrospective!

I made a game in 48 hours for Kenney Jam 2025!

Try it here! https://cuffbutton.itch.io/all-systems-gogogo

Why I Joined

This was my first jam ever, and I definitely bit off more than I could chew. I was honestly pretty scared to join, but that just meant I had to do it. Worst-case scenario? Crash and burn, then pretend it never happened. Once I committed, Kenney Jam felt like the perfect choice. Anyone in hobby game dev knows Kenney (and Kay Kit) for their amazing free assets. They’ve been a huge help in my learning journey, even just as stand-ins so my projects aren't all grey boxes. This felt like a small way to give back. Also, it sort've felt like a safe space to try making a finished game for the first time.

Engine Choice

My engine of choice for the jam was Godot. I personally like to focus on Godot because it's lightweight and FAST. I hate when I try to launch my game in Unreal and the time it takes to compile and load takes longer than the thing I actually want to test! Godot allowed me the fastest iteration, so it felt like a no brainer.

The Theme: POWER

Honestly when the theme was first announced I was majorly bummed. The theme felt a little generic and uninspiring. Like isn't power honestly the core idea of basically every single video game? Immediately I know everyone's games were going to be about batteries, money or fame, or level ups...at best some games would be very novel spins on these aspects. But I tried not to let that lower my spirits too much. The theme was actually announced during my work day so I couldn't start working right away anyway so I just let my mind simmer on the idea.

The Idea

As part of my day job I do a lot of QA and triaging for autonomous vehicle systems. While sitting there looking over my work space my mind started imaging a game around this concept; a system you weren't in direct control of but could influence based on how you move power around within that system. I wasn't worried about this being too "straightforward" a take on the POWER theme. I knew the biggest part of the jam would be actually executing on an idea and I didn't want to get too bogged down in trying to think of something overly "cool" or "unique." I let my mind be captured by the first idea that felt interesting.

From there, I started imagining giant mech battles. The idea of being part of a Power Ranger-style Sentai team, but playing the overlooked engineer, cracked me up. That led me to one of my earliest mech battle memories: Mystical Ninja Goemon on the N64! It was a goofy, action-adventure game where you played a ninja, but suddenly you'd jump into these giant robot boss fights. You didn't control movement. You'd just aim and trigger cooldown-based abilities. It was weird and awesome and that memory sealed my jam concept.

Gameplay Core

So that's basically what I did. Majorly "borrowed" some core concepts for that and made it so you didn't control actions directly but instead provided them power, like an engineer. The idea was that your abilities would activate at different levels depending on how many power cores you'd slot in. All of this while an enemy was taking pot shots at you and you also had to managed your "heat." Basically trying to just use the strongest weapons all the time would overheat your robot and you'd have to vent the excess energy!

If you're thinking that sounds like a lot, surprise surprise, it was! Ha.

What Went Right

To my surprise, actually developing the game went pretty smoothly. At least early on! I found a satisfying rhythm working in a "back-and-forth" cadence: I'd design an enemy attack, then immediately follow up by designing a player counter. That loop made development feel fun and game-like in itself.

The first day of the jam was a huge confidence boost. I greyboxed all my ideas fast and already had four player interactions working by the end of day one. I think the clearest win was how quickly the core loop emerged and felt playable. The power-routing mechanic clicked immediately, and managing heat added a fun layer of tension.

Momentum and confidence were flowing freely.

What Went Wrong (And What I Learned)

Let me walk you through some of the major challenges I hit when trying to bring this thing across the finish line.

Architecture

My biggest early issue was separating concerns between objects and scenes. I jumped right in without much thought to architecture. I just trying to get things working even if it meant spaghetti code. That mindset caught up with me. I had a strong vision for the game's mechanics, and a little upfront planning would've saved a lot of headaches. Even under time pressure, it would've been worth stepping back and thinking through structure before building.

I started with a player scene handling basic attacks, health, and shields. I knew I'd need a separate system for power and heat management, so I created a MechManagerScene. Later, I built a Cockpit scene for all the interactive bits and bobs the player could manipulate. The problem was these three scenes quickly became entangled. Each one needed to talk to the others constantly and this created a messy web of dependencies that got harder to manage as the game grew.

The power cell had to tell the power socket it was plugged in. The power socket had to tell the cockpit it was a socket for weapons. (Add an extra step if the socket also activated a secondary interactable, like a button or wheel) The cockpit had to tell player how much power his weapons had (because originally I thought it was smart for the player scene to contain all of the visuals that were related to the player so they'd all be in one place). Then the player had to tell the MechManager what animation was playing so the manager could match the heat and damage output.

Originally this didn't feel too bad as I was moving quickly and pumping out features. Once I hit my first bug or stumbling block though I finally turned around and looked at the absolute warpath I had carved myself through my code. I somehow had myself convinced I was being so smart too! To fix it quickly, I created a global signal manager singleton so everything could emit and listen without threading through messy chains. If I had to do it again I would've just combined the player and MechManager into one clean scene and run all player logic from there. The cockpit could've remained dumb, just emitting signals without needing to know anything else.

Asset Integration

My second issue was leaving the asset swap for last. The jam required using Kenney or Kay Kit assets. Not a huge restriction since they offer tons of great freebies, buuuut, I had never fully replaced an entire project's worth of greybox assets before. I figured, "Eh, I can do that in three hours." Yea, that skill I had never done or practiced before. Right.

I hit a bunch of snags. The scenes imported with inheritance, making them rigid and tricky to modify. At first, I tried brute-forcing it by manually clicking "Make Unique" on every piece I needed to tweak. Eventually, I remembered lesson one: stop rushing, slow down, and learn. Turns out you can clear the inheritance with one click. Oof.

Clarity and Communication

Another big missed opportunity is game clarity of what the enemy mech is doing and the status of your own mech. I had my stunning wife record some voice line callouts that were supposed to tutorialize and help with clarity when like, the enemy is charging an attack, or when you're near overheating, or explaining the "curse" mechanic I built in. Unfortunately I didn't have the time to implement them BUT during development I did have a running log of print statements that were intended to mimic the timing of these callouts so I could tweak them during play. When I knew for a fact I wouldn't have time to implement the voices I feel like I should've exposed those print statements to the player. Ultimately that's what I did with some HUD elements like player health. It would've fit in the aesthetic too to just expose like, a log to the player to give them more context. Huge lesson to learn on scope haha.

Pivot Sooner

A different lesson I learned would also be PIVOT SOONER. Throughout the project there were about a handful of issues or bugs that I sent multiple hours into. On each of them I felt like I was so close to figuring out the solution. When I finally did pivot to doing something else, most of the time I was able to create a new solution in under an hour! My instincts for how close I was to successfully debugging an issue are apparently terrible. But at least now I know! Lol.

Final Thoughts

All in all I learned an absolute ton finally taking a project from beginning to end. Sure, a lot got left on the cutting room floor but what matters is I shipped something. It has a start, an end, and some very sweaty heat management in the middle. I learned so much doing this that I'm really motivated to take on another jam soon! And I'm really happy to take these learnings back to my more fully featured projects.