Recently, my son and I decided to do a game jam together. When he was younger, he created game jams for our family, setting a theme and using a specific engine (e.g., Pygame). However, this was our first real game jam together. We decided to enter the Brackeys Game Jam 2026.1. The theme was “strange places.” This post is about what happened, what worked, and what I’d do differently.
If you want to skip straight to the game, you can play Jesvilemys in your browser.
A Little Background
Before we jump into the game jam, a little background context is necessary.
My has made games in Scratch and Godot before, composes his own music, and has a good eye for visuals. He doesn’t have formal training in algorithms and data structures yet, but he writes GDScript (and Python) comfortably and cares a lot about code cleanliness. He also has strong opinions about what feels good to play, which turned out to matter more than I expected.
As I have talked about before, I have a computer science degree, but professionally I work in other areas, so game development is a hobby for me. This was my first project in Godot.
Game Jam Idea Phase
As soon as the theme was announced and the game jam began, we decided to each build a prototype independently before deciding what to pursue together.
My idea (based on my son’s interest in how HTML is parsed) was a platformer set on a webpage. The elements of the webpage served as the platforms (e.g.,paragraph blocks as platforms, buttons you could stand on, a jetpack emoji as an actual jetpack that you could use). I liked the concept and felt it fit the “strange places” theme well. The problem was structural. Webpages are tall and vertical, and platformers need horizontal space. It was difficult to create a “webpage” that a player could jump from element to element without making the webpage look not like a webpage. The more I built it, the less fun it was.
His idea was a multiplayer fighting game similar to Super Smash Bros. The prototype was immediately more enjoyable than mine. The honest problem was that “strange places” was harder to see in his design. But the game itself was better, and choosing his idea wasn’t difficult. I didn’t feel confident in my own concept.
Throughout the development, the theme gap never really closed. We discussed it throughout the project but couldn’t find a solution that felt natural rather than forced. In the final days I was researching negative color shaders, thinking an inverted visual effect might at least make things look “strange.” Then I looked at the game visuals he had implemented and decided against it. They were too good to make weird. The missing theme is probably a regret we both share.
Finding Our Lanes
We didn’t formally divide responsibilities. Roles developed organically based on interest and what each of us felt capable of. He handled the visuals, player movement, music, and sound effects. I built the multiplayer architecture and backend infrastructure.
We wrote a game design document early on. Looking back, I think that was more useful for me than for him. He already had a clear picture in his head. I needed the structure to feel oriented. What I would actually want for a project like this is explicit milestones with timing and accountability. There were points where I genuinely wasn’t sure what I should be working on, and no clear way to answer that question. However, this is likely based on years of project management and not something that my son has experience with or felt like he needed.
Communication
Communication was informal and evolved as we went. Early on, it was mostly walking between rooms. Toward the end we started using GitHub Issues, which worked better than I expected.
Git was our biggest practical success. We used it consistently throughout, which made sharing code relatively smooth (once we got through a few initial bumps with corrupt scene files). Our styles for git usage were different. I made a branch for every feature, he committed directly to main. There were a few minor collisions because of it. He accidentally deleted code I had written to reset player stats between games. I broke his player movement at one point. Neither was a serious problem, but both were a reminder that having different habits in a shared codebase requires some coordination. Check out our GitHub repository if you are interested.
Frustration
Around the midpoint of the project he seemed discouraged. The game wasn’t matching what he had envisioned. I tried to ask what was missing, but he couldn’t fully articulate it, and I couldn’t draw it out of him. Looking back, I think it was the theme gap. He had the feeling that something was absent without a clear name for it. He pushed through on his own. The turning point was when we actually played the game together and it was fun. That seemed to settle things.
Multiplayer: Not Quite the Game Jam Theme
I was always uncertain about multiplayer. I was not worried about it technically, but from a player perspective. A multiplayer game requires enough concurrent players to be enjoyable (the network effect), and for a small jam game, that’s a real challenge. I suggested adding AI players to fill empty slots. He wasn’t interested. He wanted a player-versus-player game, and bots felt like a compromise of the concept. We probably wouldn’t have had time to implement them well anyway.
The architecture I ended up with uses a Python WebSocket signaling server for matchmaking and port allocation, with headless Godot instances running the game sessions. It works. Whether enough people are ever in the lobby at the same time is a separate question.
A game jam is a mostly a learning experience. I learned a lot about multiplayer architecture, and that has value regardless of player count. In the future, I will share more of the technical details of the multiplayer setup in a separate post.
The Last-Minute Browser Rewrite
One communication failure we had was around how the game would be delivered to the player. Since the game jam is through itch.io, we both knew that it would be hosted there. However, I was approaching it as if users would download the game and play on their system. He was expecting a browser based game.
The problem was that I had built the entire networking layer on ENet, which doesn’t work in a browser (at some point in the future, I will create a separate post on this). Late in the jam (approximately 24 hours before it was due), under deadline pressure, I rewrote the networking layer to use WebSocket multiplayer. That meant a new peer type, new connection logic, SSL termination through nginx, and certificate setup. It was the kind of infrastructure work that is satisfying when you have time and stressful when you don’t.
The browser requirement was his idea, not mine, and he was right about it. His reasoning was simple: nobody is going to download a game from a jam they’ve never heard of. If you want people to play, it needs to run in the browser with no friction.
It came together. But if we do this again, the browser target goes in the design document on day one.
What Went Well
Git worked well and I would use the same approach again. His visual and audio work was excellent. The character models, the music, and the item souls mechanic were all his contributions. The item souls idea in particular is clever: rather than items having fixed effects, their “souls” swap between bodies on a timer. The bomb becomes a speed boost, the speed boost becomes a trap. It adds a layer of unpredictability that keeps the game interesting. I wouldn’t have come up with it.
What I’d Do Differently
Set explicit milestones with timing and accountability at the start. Nail down the browser target early. Give the theme an owner and a plan rather than hoping it works itself out. These aren’t surprising lessons, but they’re more concrete after having felt their absence.
From my own work, I am most proud of the multiplayer infrastructure, and also most uncertain about it from a player experience standpoint. The hardest technical problem got solved. Whether it matters to the people who actually play the game is still an open question.
Play the Game
The game is called Jesvilemys. It doesn’t mean anything, just a mix of different words. That was his idea, and I loved it.At least for now, you can play it in your browser on itch.io (I am not sure how long I will keep the multiplayer server running). You may or may not find other players in the lobby. The network effect concern hasn’t gone away. But the game is real, it works, and we built it together.
f you enjoyed this post, consider subscribing to the newsletter where I share work-in-progress updates, upcoming tutorials, and the occasional behind-the-scenes look at what I’m building.
