What was that process like? Working with different constraints, and in smaller, more focused contexts, ultimately limits the sheer number of options developers have at their disposal, which I actually found helpful in narrowing down what I wanted to work on. Working in PICO-8 or p5.js (which is another simplified coding tool for Javascript) allows new developers to work on implementing simple, focused projects, rather than getting lost in the endless sea of overscoping (which I have definitely fallen victim to in the past).
What other games have you worked on? Over the years I’ve worked on platformers, first person shooters, text- based adventure games, VR experiences and even an in-vehicle game while partnered with BMW Group during University. Some of the highlights include Anchor, a prototype of a first-person rocket jumping platformer, harkening back to TF2 movement in the source engine, as well as Dungeon Tempo, a multiplayer rhythm game where players attack each other with created rhythm tracks to the beat of music. Despite all this work though, BURNTCRUST is the first game I’m planning to fully publish on Steam.
How has the development of BURNTCRUST been so far? In late 2025 I quit my food service job to work full-time on games and ironically ended up working on a space sim with food delivery as the core gameplay loop. Maybe it was a subconscious choice to pass off my trauma in the food service industry to others… who knows? Anyway, I’m a huge fan of sci-fi, and BURNTCRUST is a love letter to all those retro sci-fi tropes. My dad and I have always been big fans of the original Star Wars
trilogy, and I think recreating the magic of getting lost in a huge universe like that would be a really great feat for a video game to achieve. I’ve been making the game by myself in Unity, and my process is less of a rigid schedule and more me thinking “what is something cool I could add today?” alongside the usual bug fixes. I wouldn’t suggest this process for all developers, and there’s definitely a chance to be less productive and get lost in the possibilities, but it seems to have worked for me so far.
What are some challenges you faced during development? One of the biggest challenges of BURNTCRUST - and open world space games in general - is floating point errors and implementing origin
What are some of the changes you had to make during BURNCRUST’s development? I originally started a prototype for the game a couple years ago, trying to jump on the comedy horror bandwagon with games like Lethal Company, but had to sideline it after being distracted with work and school. Eventually I came back to it though, after having a different idea for the base concept (a sort of long haul delivery simulator but in space), which ultimately became the foundation for BURNTCRUST. The original concept has specific set locations that the player would
visit and would have to explore in first-person horror sections typical of the genre. You would go into a dishevelled building, have a flashlight and had to be wary of any monsters that would appear in your path. The name was also changed and was originally tentatively called “Delivery Cost”. Obviously, there were a lot of changes along the way, but some of the ideas I have are likely to still be implemented in some capacity in the final product, so look out for it when it releases!
February/March 2026 MCV/DEVELOP | 27
shifting. When the player is heading far away from the centre of the game space (the origin), this slowly starts to build up floating point precision errors, which can cause the physics to function unexpectedly. Usually for me, this appears as slowly increasing jitter in the game and is especially noticeable on UI elements. To fix this, you implement origin shifting, which basically teleports the
player back to the origin every time they go too far in one direction, and shifts all of the level accordingly (so it appears to the player as if nothing happened). A more advanced approach, used in games like Outer Wilds, is to just move the world around the player, instead of moving the player. So, when the player moves in one direction, it’s actually the level moving in the opposite direction which simulates the player’s movement. This is by far the trickiest problem in the design process, since any
stored positions in space (such as for where to spawn points of interest, or even where to place the player’s decorations) also all need to be shifted as well, and keeping local space and world space sorted is a headache in and of itself.
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56
