Zero Atmospheres: A Postmortem

Zero Atmospheres was created in 8 days (in-between a full-time job and social obligations!) for the Dungeon Crawler Jam 2025. It was my first time using Godot, and it was the first time I’d created a game for a jam which wasn’t an in-person all-weekend affair. What the experience of those in-person jams, along with the jam games I’ve played, showed me was that what holds game jam games back is not time but time-management.

I’m writing this dev log so that others can, if they so choose, can follow the process I used. I’m also using it so that prospective team members in future jams can have an understanding of how I think about making games.

My goal in this project was to deliver something short, polished, accessible and shareable. Those last two really mean “Works on a mobile browser!”. My biggest advantage going in was that I have a good understanding of my skills and my limitations. I was also lucky that my theme suggestion (“Sinking Ship”) had enough support on the jam discord to be selected, so I already had the idea core idea of a wrecked spaceship with controllable gravity floating around in my head – no pun intended.

Development process

Because I knew time management was going to be the real challenge, I went about building my game using a “polish-as-I-go” approach. When I decided to add a feature, I ensured that it reached my standard of “good enough” before I moved onto the next thing. That isn’t to say that I didn’t have a polish stage at the end of the jam, because I did go through and make some things better than “good enough”, but when I got to that stage every area and every gameplay element was already at a stage where I was happy, so I could really focus on elevating. What that meant specifically was adding sound effects as I went and maintaining graphical consistently and quality as I went – especially when it came to UI design. A unity/Godot unstyled or hastily button is the biggest way game jam games give themselves away as made under a time constraint!

Priority one: Movement

Strict rules were put in place by the jam organisers that the games must be first person and must contain grid based movement. Since movement is the thing that players do the most in the game, I knew it was vital that it feels right – and I could see from the previous years entries that that was an area a lot of submissions struggled with. Moving onto to gameplay features was not an option until I got movement feeling perfect.

Rather than try and use the existing physics that was built-in to Godot, I elected to roll my own system where I handled all movement myself programmatically. The one tool I used from Godot to help with this was raycasts, which were used to determine which moves were and were not valid. My work in Pico-8 meant that I had learnt not to fear rolling my own systems to handle movement, and I am very happy with the out come. Like almost any motion I’ve ever programmed and been proud of it extensively uses a mass-spring-damper model. In this case, to quickly accelerate the player towards a “target tile” and them have them quickly decelerate upon arrival.

This is also where I did the first proof of concept for the oxygen system and gravity-changing mechanic. A good rule of thumb for prioritisation is to do the highest risk tasks of a project first – if either of these two mechanics were non-viable then I would have to rethink my whole game idea. Luckily, they just about worked.

Priority 2 - Tileset, mood, and environment

Once walking felt good, I needed somewhere you could walk around! Ten euro later, and I was the proud owner of a spectacular texture pack, which I think deserves just as much credit as I do for this project coming together. Slapping these textures on some boxes, putting in a space skybox, and turning on some aggressive fog didn’t take a lot of time nor skill, but he result was effective nonetheless. I used Quibicle, a voxel editor, to composite these textures into more complex tiles, such as windows and hull breaches, and used them to create interesting feeling test areas. But it was still missing something… adding some ambient sounds and clink-y echo-y footsteps was starting to bring it together, but it didn’t all snap into place until I set the resolution to 128 pixels ×128 pixels…. which brings me on to…

Priority 3 - PICO-8, Faux-PICO8, and the magic therein

The virtual console PICO-8 is one of my biggest influences. It’s ultra low-res 128x128 square screen gives projects a defined aesthetic, which is retro but not trying to evoke any specific generation or console. Low resolutions are an absolute godsend to someone like myself who is able to create some game assets to an okay level of quality, but not create any truly impressive art. Slap them in a low-res screen, and that mediocre quality becomes an aesthetic, and people start throwing around buzzwords like “PSX”.

PICO-8 delivered what I always aspire towards with shareability, since games work straight in the browser and on mobile have touchscreen controls appear automatically. For this project, once I stole the pico8’s resolution, it was natural to be inspired by it’s touch controls. PICO-8 touch controls are outside the screen area, and not limited to the 128x128 resolution. Likewise, I put my controls in the HTML-template not the Godot project. This allowed me to use web features to create a responsive display, while not having to worry about having them be part of the game itself and having to run the game at different resolutions, or try and handle responsive web design from within Godot. The technicalities of how I achieved this will come in future devlog.

Accessibility doesn’t just mean mobile web, but it means supporting WASD, arrow keys, controllers and mobile web. It also meant testing the web export and exe export multiple times a day! It’s very easy to not realise your project does not export correctly until the final days or hours of a jam. For that reason I had the WIP project running on itch by the end of the second day.

Priority 4 - The start and the end (Nothing else matters)

So I have an area I can walk around. It looks, sounds, and feels good, and what’s more I can send someone a weblink and they can run it on their phones. But the first weekend was over and that isn’t a game.

But…

If I spent time making a satisfying start area, and a satisfying ending, I can then look at how much time I have left in the jam and make any amount of content to fill that time. It could walking be 15 steps through my existing test areas, it could be 100 hours of intricately designed content. Whatever I made, if I had the start and the ending done, I would have “a complete game.”

This mentality also included the main menu and logo, a saving/loading system, and, bizarrely, a chicken as per the rules of the jam. Everything that would get me across the line to a technically submittable game.

In the end, both sequences were 3-5 second cutscenes – one of waking up in a cryogenic pod, and one shooting off in an escape pod. Not much, but simply having anything of the sort in the game jam is the kind of polish that gets noticed. As it happens, in the end, some players said they expected a little more from the escape-pod sequence, but the first few seconds of the game invoked a positive reactions from a lot of players.

Priority 5 - “Draw the rest of the owl”

In a sense I was done, I had a technically submittable game, one that felt good to play, and I still had 3 days left of the jam. It just was completable in 3 minutes, and had no content whatsoever.

I went to a café, and wrote up a list of everything I wanted to have. By this point I had a good sense from creating my various test areas how long building up content would take. Being a big fan of wordless tutorials, I also knew that I wanted to introduce each mechanic in a safe and simple situation first, and then remix it into a more complex challenge. Once I had my list of areas, I mapped them out into a graph, which allowed me to figure out things like key-door placements, placing one-way doors, allowing multiple valid routes, and maintaining pace.

The graph was great because it meant I did not have to think about the physical space at all; I only had to think about player experience. I would look at the graph, play through the game in my head, and move things around when it did not feel fun. It also helped me realize that one particular area, which was originally going to be a simple crossroads in a corridor, needed to be a memorable focal point to avoid players getting lost.

Once I was happy with the imagined experience, I had to try and bend and warp this graph into a 3D space.

In the end, this was not as hard as I feared, but it did take a lot of pages scribbled out in my notebook. And then I got to work.

Priority 6 - Finding something to polish

I was already happy with my game, and in the end, creating all the content took less than 2 days, leaving me plenty of time to playtest and polish.

I made some minor tweaks, moving walls where playtests got players lost, improving sightlines and window placements so players had better sneak peeks at what was coming. Most of my remaining notes in my NICE-TO-HAVEs list were either too big (I wanted a robot inspired by this unfinished PICO-8 project to chase you at one point) or playtesting made me realize they weren’t as important as they had seemed during the planning stages.

I added autosaves, which turned out to be absolutely vital for my goal of accessibility, after a playtester died right before the end of the game and hadn’t saved even once.

I also focused on making the command room of the ship — that’s the central hub that needed to be memorable, the one that was almost just a crossroads in some corridors — as memorable as possible.

Finally, I added some settings, including adding an instant movement mode, called “boomer mode,” in a tongue-in-cheek jab at the older gentlemen running the jam — it’s good to be talked about!

After the jam ended, and I watched the various playthroughs (1, 2, 3), of course I discovered more issues which I would have fixed had I known, but in a game made in less than two weeks I didn’t beat myself up about it. Other pieces of feedback lead to valuable lessons, such as although I am very proud of the textless tutorilization, there are still times – such as when the game autosaves or when interacting with keys and locked doors – where text prompts in addition would have improved accessibility. There were also times where my goal to create accessible content turned off some players, since they felt that a lot of the puzzles did not have meaningful choices – a valid criticism, and one I risked receiving when I aspired to create a game that everyone who played could enjoy.

Conclusion

Overall, I am proud of what I created, and I am proud of the approach I took: 1) Make the core thing you do in your game the most as fun as you can, 2) Polish as you go, 3) Create a polished start, the ending, and the menu (etc.) as soon as you can, 4) spend the remaining time on content planned out as soon as you’ve completed step three and feel you understand your game well enough to do so.

I look forward to working on applying this approach to future game jams. If you want to join me on that journey, message me on bluesky.