nanware logo

One Week, Five Planets - Our Brackeys Game Jam 2026.1 Story

So yes… I’ve done game jams before. You sign up thinking “this time I’ll scope it properly,” and then 48 hours later you’re neck-deep in a feature list that could take a month. It’s a trap, and we all fall into it every single time. But this one was different. Not because we scoped it well (we didn’t either), but because we were organized and got the last commit to the release branch with four hours left until the deadline.

This is the story of Pocket Galaxy and how it came together during the Brackeys Game Jam 2026.1.


The Setup

The jam ran from February 15th to 22nd, 2026 - One full week. The theme was “Strange Places”. I went in with Batzzer and Heidozanzo, two teammates who share the same passion for game development and who I work with on a daily basis. We’d worked well together in previous jams, and having that trust already in place made a huge difference. No time wasted figuring out who does what or tiptoeing around feedback. We could just… go.

The first commit hit the repo on Sunday morning. Yep, a bare README.md, but hey… we were one commit ahead! By launch, we were already arguing about the core idea. We had the theme, but what does “strange places” even mean for a game? We threw around a bunch of concepts, and eventually the idea just landed: “hey, what if you could walk around a tiny planet?” That was the one. It was weird enough to fit the theme, technically interesting enough to be worth building, and small enough in scope to maybe, maybe, fit in a week.

Spoiler: it didn’t fit in a week. We made it fit anyway.


Day One - Foundations (Sunday, Feb 15)

The first day was all about proving the core idea. Can you actually walk around a sphere? Does it feel okay? Is the camera going to make people sick?

By Sunday evening, we had a working gravity system. A GravityAttractor at the center of a sphere, a GravityBody on the player, and a first-person controller adapted to curved surfaces. It was rough. The camera jittered, the movement felt floaty, and walking near the “poles” of the sphere was… an experience. But it worked. You could walk around the entire planet and end up where you started. That was the moment we knew the idea had legs.

By the end of the night we also had the raycast interaction system in place and the first sketch of the spaceship scene. Thirteen commits on day one. Not bad for a Sunday.

The first development planet taking shape in the Unity editor, with the extraction point beam and a lonely tree


Days Two and Three - Building the Skeleton (Mon-Tue, Feb 16-17)

Monday was architecture day. The hub scene, the planet carousel, the objective system framework, the scene transitions… all the invisible plumbing that makes a game feel like a game instead of a tech demo. None of this was glamorous work, but without it, nothing else would have come together later.

Tuesday was when things started looking like an actual game. The HUD came online, the minimap appeared, and we had a working flow: select a planet from the carousel, descend, explore, complete objectives, extract back to the ship. The planet ring in the carousel was “spinning”, the extraction point had its beam particle, and for the first time you could play through the whole loop from start to finish.

The spaceship hub scene coming together, with particle effects and the ship exterior floating in space

We also established the base planet prefab structure on these days, which turned out to be one of the smartest decisions of the entire project. Every planet would follow the same template: sphere, gravity, player, objective tracker, extraction point. Planet-specific content layered on top. That structure is what made it possible to build five worlds in the time we had.


Days Four and Five - Content Sprint (Wed-Thu, Feb 18-19)

With the framework in place, we shifted into content mode. This is where things got intense.

The main menu scene with the space station model and nebula backdrop

Wednesday brought the main menu, the credits scene, the audio mixer, and the first two planetary environments. Batzzer was cranking out assets, vegetation, terrain materials, props, while I was wiring up systems and building the worlds themselves. The grass spawner using Fibonacci sphere distribution was born out of necessity here: we needed to cover a planet in vegetation fast, and placing things by hand on a sphere is an exercise in frustration.

World 2 taking shape: lighting pass on the planet surface with vegetation distribution and the ship hovering above

Thursday was more of the same but faster. Four planets had implementations by the end of the day. The UI got polished, the spaceship HUD got its widget elements, and audio started coming in: menu music, sound effects, ambient tracks. The commit messages start getting shorter around this point. That’s usually a sign that things are moving fast and nobody has time to write descriptions.


Friday - The Optimization Wall (Feb 20)

Friday was chaos. Beautiful, productive chaos. 37 commits in a single day. That’s our record, and I hope it stays that way.

The fifth planet was done by 2 AM. All five worlds existed. We had quests, audio, a complete menu flow, and a game you could actually play from start to finish. For about an hour, we felt great.

Then we tried a WebGL build.

The thing about building for the browser is that everything you got away with in the editor comes back to bite you. Textures that looked fine? Too big. Audio files in WAV format? Way too big. MSAA, light cookies, lens flares? All of those add up in ways you don’t notice until the browser tab crashes.

So Friday became optimization day. We disabled MSAA, cut shadow maps in half, turned off every URP feature we could live without. Converted the entire soundtrack from WAV to OGG Vorbis, which alone dropped the audio from ~67 MB down to ~7 MB. Removed unused fonts, reduced texture resolutions, enabled Brotli compression. Commit after commit after commit, each one shaving off a few more megabytes.

We completed all PRs, made a build, and then we tried to upload to itch.io.

Here’s a fun fact about itch.io that nobody tells you until it’s too late: while you can upload files up to 1 GB, the browser runtime won’t load any individual file larger than 200 MB. Unity packages everything into a single Build.data file. Ours was over 300 MB.

What followed was a full troubleshoot sprint. We went through every asset, every texture, every audio file, every model. Anything that wasn’t essential got cut. Anything oversized got compressed further. We rechecked every import setting, every build option. The managed stripping level went up. Exception support got disabled. At some point I think we were individually inspecting .meta files looking for anything suspicious.

We got it down to 175 MB. It loaded. We didn’t celebrate so much as exhale.


Saturday - Polishing and Minor Details (Feb 21)

On my end, I had to be away for most of the day, so we agreed to keep things light and go all-in later that night. Luckily, most of the major tasks were already done by then and we knew our build was meeting the expected constraints. Saturday was meant to be polish day, and it mostly was: we divided the tasks so I took the quest systems for the remaining worlds, Heidozanzo took ownership of the in-game pause menu, and Batzzer handled the visual effects like sparkle particle effects for collectibles or the particles in spaceship animations. The final ice planet was completed around midnight.

World 2 during the polishing pass: dark volcanic terrain with the ship overhead


Sunday and Release (Feb 22)

Between 1 AM and 2 AM on Sunday, things were looking good. Night was oddly quiet by comparison as we were really focused on final bug fixes, credits scene tweaks, and minor adjustments on planet prefabs. A few sparkle effect fixes because the collectible particles were misbehaving. The kind of small, satisfying work that comes after the storm.

We were consolidating everything on the release branch, so the moment came… code freeze and live smoke test. We merged the final pull requests into the release branch. Tag v1.0.0. And with around 4.5 hours remaining until the game jam deadline, the game was live on itch.io. 123 commits, 42 pull requests, and five tiny planets you could walk all the way around.

Upload screenshot from Itch.io publishing

What came next was just completing the form… providing the descriptions and minor post-deploy adjustments for the publishing itself… and of course, submitting our game to the Brackeys Game Jam 2026.1 entries. Yay!

Brackeys Game Jam 2026.1 Pocket Galaxy submit


What Came Out of It

I won’t pretend everything went smoothly. We over-scoped (five planets for a one-week jam is ambitious, let’s be honest), we hit the WebGL wall hard, and there were moments where the whole thing felt like it was held together with duct tape and good intentions.

But it shipped. And it’s not just a prototype or a proof of concept, it’s a complete game with a beginning, a middle, and an end. The gravity system works and feels good. The objective framework is flexible enough to model real quest lines. The hub and carousel give the game a sense of progression. Every system was built to be reusable, and that discipline is what let us move as fast as we did.

More importantly, working with Batzzer and Heidozanzo reminded me why jams matter. It’s not really about the game. It’s about compressing the entire creative process into a week, from “what if” to “it’s live,” and learning how you work under that kind of pressure. What you reach for, what you cut, what you protect.

Pocket Galaxy was born from a constraint, but it’s something we genuinely want to keep building. The architecture supports it. The ideas are there. And walking on a tiny planet, watching the horizon curve beneath your feet while the stars drift overhead… that never got old.

If you’d like a look under the hood, the project page dives into the technical details and design decisions behind the project.

And you can play it here: