A View from the Other Side of the Screen

If you read SUPERJUMP, you're probably here for the games themselves. I want to offer a slightly different view: the one from behind the screen, where someone is fumbling to build those gaming moments for the first time.

By day, I've been a software engineer for over 10 years, mostly in cloud and web. I'm comfortable with PHP, JavaScript, and Python, among others. But about a year and a half ago, I got curious about how games are actually made. I bought a few books (the Code the Classics volumes were a wonderful starting point), followed tutorials, and fell for Pygame. Last October, I went further and started building my own little games: an idle game first, then a small city builder, picking up game design and pixel art along the way.

The trouble with building games only for yourself is that you can tinker away forever and never finish anything. So a few weeks ago, I decided it was time to actually ship, or in other words, to put something out to the public, with my name on it, in front of strangers. I work best inside walls: the tighter the constraints, the more I'm forced to be creative. A game jam is nothing but walls, which is exactly why I signed up for one.

My first jam was the Campfire Creators Jam #2: build a game in two weeks (not much time at all) with a single rule: you had to use a provided campfire spritesheet. Here's what came out of it.

Campfire Stories: Cooking While Someone Bares Their Soul

After a few days of just thinking about the theme and the feeling I wanted, I landed on a narrative game. You play as a cook at a campfire on a cool summer night, grilling skewers for the strangers who sit down across from you. Simple enough. The twist is that while you cook, they talk and tell you real, personal things. The entire game lives in the tension between listening and watching the fire.

One of my characters is Albert, a retired banker in his sixties who has loved medieval history since he was a boy poring over his grandfather's books. He visits the fire three times across a night, and he only opens up if you've truly been paying attention. I won't spoil the story for you here; feel free to install the game and find out for yourself, and please feel free to send feedback and suggestions.

On the technical side, I deliberately chose to build in MonoGame rather than Pygame. I'd been learning the framework for a couple of months, I'm still a beginner in C#, and I wanted to put it to a real test. The experience was genuinely great, something I'll reach for again.

The game runs on macOS, Linux, and Windows, and I open-sourced the whole thing. You can play it here and dig through the code here. I'm happy with how it turned out, though, as with anything you make under a deadline, there are things I'd do differently.

What Went Well

The first thing I'm proud of is that I didn't dive straight into code. I forced myself to plan, or in other words, to sit with the idea before building it. I wrote a proper Game Design Document (GDD) and got most of my thinking down on paper, which meant I could share it with friends and use AI tools to pressure-test it before a single line of C# existed. That single habit probably saved the project.

That said, the GDD process and the weeks that followed taught me something I didn't expect about those AI tools. They genuinely do make you more productive; that part is real. The catch is what that productivity quietly turns into. Because adding one more thing is so fast and so easy, you keep adding a feature here and a flourish there. A lot of it was never in the plan you started with. You feel like you're shipping a great deal, and the tool leaves you feeling both productive and clever. But much of what you're "delivering" is scope you never actually decided on. That's what makes these tools remarkable and a little dangerous at the same time; the productivity is real, but so is the drift. I came away convinced you have to use them carefully, especially for code, with a firm idea of where your project is meant to end. For your information, I did not use Claude Code, only Claude. I link it to my GitHub repositories, and I work only sparingly with it as a partner.

The second thing, and honestly the biggest, is that I finished. I think of jams the way I think of hackathons, and the trap is always the same: we aim too big. I've actually won a few hackathons over the years, and even then, I was wrestling with a project that was too large. So, for me, the accomplishment here was never about placing in the jam. It was about taking pleasure in the work, learning, and crossing the finish line with something real.

And I learned a ton. I figured out how to link and use an external library inside a MonoGame project. I built two gameplay loops at once: a conversation system and a cooking system, and I braided them together, which was every bit as tricky as it sounds. The truth is that I'm a noticeably better game-maker now than I was a few weeks ago, and I genuinely can't wait for the next one.

What I'd Do Differently Next Time

The honest headline is: I should have scoped smaller. I built two brand-new systems at once, a dialogue engine and a cooking engine, when I'd never built either before. Each would have been a perfectly good jam project on its own. Doing both meant that for a while, I had two half-finished things instead of one finished one, which is a stressful place to be with a two-week clock running. Will I avoid that trap next time? Probably. Or I won't, and I'll learn it all over again. That seems to be how this goes.

I think I already know the fix, though, because I read something that stuck with me about how experienced solo developers work. They tend to build one complete feature at a time: they take a single feature all the way through, the design, the code, the art and spritesheets, and even the sound, before moving to the next one. The beauty of working that way is that you always have something finished to show. That matters when you want to put your game in front of people, and it matters just as much for your own morale; there's nothing quite like the slow grind of two unfinished systems to wear you down.

So next time, that's the plan: one complete, polished feature before I let myself start the next. Less impressive on paper at any given moment, maybe, but far steadier, and far kinder to the part of me that needs to see progress to keep going.

What's Next?

For now, I'm going to take a short break from building and go back to the theory. I've got two courses waiting on Udemy that I'd like to actually finish. There's a quiet pleasure in slowing down and shoring up the foundations between projects.

After that, another jam. I've already found one that has me genuinely excited: Retro Recreation 2026. I even think I know which game I want to make. I'll be staying with the tools that served me so well this time, MonoGame for the code and Aseprite for the pixel art.

If there's one thing I've taken from all this, it's that finishing something changes how you see yourself as a maker. I came into this jam wondering whether I could actually ship a game. I came out the other side already itching to do it again. Honestly, that feeling of being half exhausted and half lit up, scrolling through jam listings at midnight, might be the best part of the whole thing.