BURN
Sold 150+ copies and counting!
Embedded Files
Click here to check out the game's steam page!
Overview / Goals
BURN is a zero-gravity psychological horror game created from December–February 2025. The player must navigate a station gone silent, discovering bodies and learning how to navigate with the unconventional movement system.
This project was originally intended to be completed by the end of December, but we ended up having about 4–5 weeks of playtesting and iteration, which led to our eventual February release date. For most of the project, I worked with another person who acted as a 3d artist and designer, and we ended up bringing in a second programmer in the last week of development to help with polish and bug fixing.
Design pillars
No death or damage
We wanted the player to feel a sense of doom and danger, but didn't want them to ever be in any real danger. This came from the annoying moments in any game with respawns of just retrying over and over until the player is able to overcome the situation. While this may work in some games like souls games or outer wilds, we found that in horror games after the player's first death, most if not all tension is lost.
Maintaining flow state with solid moment-to-moment gameplay
An interesting balance has to be struck with horror games, and action games in general. You have to keep the player stimulated, but the answer to this isn't constant action or danger. When creating BURN we were always talking about the moment-to-moment gameplay and trying to strike the balance between danger, safety, fun, and fear.
Keeping the player comfortably uncomfortable
To create our ideal experience, we didn't want anything to feel too game-y and simple to do, as we were striving to create a more harsh world with outdated and unreliable tech. Most of the sounds are very sharp and somewhat crunchy or static-y, the player's suit and ship computer are seemingly somewhat dated, and the environment is cold and uninviting.
Development process
Inspiration from a mistake
The initial concept from the game came from a bug in one of my other projects where sometimes you were able to look behind you by looking upwards. I had the thought that this could be fascinating and unconventional if done intentionally, so I made a quick prototype!
The Prototype
The project initially started out with a small prototype that consisted of a small station with a rudimentary version of our player controller. After bringing this to my would-be partner on the project, Aidan, we quickly created the design pillars to base the game around.
Early Stages
The first major challenge for this project was determining what the player would be doing aboard the station and what the interactions would be.
We cycled through a bunch of options here, pulling from games like Alien Isolation and Iron Lung as our inspiration. Eventually, we landed on the main gameplay loop, being that the player will explore the station looking for 6 bodies scattered across it. They will need to utilize the ship's computer to reroute power across the ship and to learn new information.
The hardest part when determining the interactions was creating them around the pillar of no damage, no death. We talked a lot about electrical fields, suit ruptures / oxygen meters and monster chases, but all of these could lead to death or damage, so we had to get creative.
Later Development
After achieving a first playable alpha of the game, we were excited to get it into the hands of whoever was interested in playtesting. We tried to get a diverse range of play testers to try to gauge the experience for a range of people.
From having a few (~2-4) play tests a weekend, we were able to review the footage from them and determine where the issues lay, whether that be in bugs or players not having the intended experience.
These videos were so key to the next section, which is.....
Solving problems!
Creating tools to build with
This was more anticipative problem-solving, but for systems I knew would get reused, I tried to make them as easy to use and modular as possible to account for a breadth of use cases.
Some great examples of this were the computer button and scare trigger scripts. Both allowed for calling of separate unity events for unique behaviors, and the option to toggle other objects to control their environments. The computer button was used as Unity's built in UI wouldn't work as well the way that I set the computer up, so I ended up rewriting most of their button code. Additionally, for the scare trigger, there were checks for how many bodies had been found, the chance for the scare to play, and slots to spawn objects / events.
Overall, I'm always grateful afterward when I create these systems as making them totally changes the game (ha, get it?) during the development process
We wanted the experience to be somewhat non-linear, and the solution we landed on was using a central computer to control the ship.
The ship computer
The computer was created as a key to unlock doors, with the door that started open being the one the player comes in from. They then had to travel up to the observation deck in a fairly linear path and interact with the computer to reroute power to one of 5 doors.
This system worked wonderfully for a few reasons!
It worked better than an open map to reduce confusion and keep the player on track. If all the doors were open at the start, it wouldn't give the player as much of a working narrative. However, with this system, each time they found a new body and went back to reroute power, new logs were also available to uncover the story and keep them on track.
It also helped with optimization, as we were able to effectively disable the props and lighting in the non-powered sections of the ship, clearing up a ton of memory!
Creating a linear ending to a non-linear game.
The problem here lay in finding an elegant solution that all players would get to no matter how they went about playing the game. We wanted the final goal to be unlocking a container, so the puzzle was figuring out how they would actually unlock it in a way that made sense.
Initially, we discussed having key cards the player would find on bodies, like access keys. The thought was that for each body they found, they would collect a key card.
However, this didn't work great as they could be easy to miss / annoying to come back to if you miss one and would require an inventory system.
The solution that ended up working great was using the bodies ages as the passkey. We had already created a section that would show more detail once you scanned a body, so by using the first letters of their names by age, it helped incorporate scanning the bodies to the central loop.
This also added functionality to the computer, as previously it just existed to reroute power between sections, and to show lore through logs. Adding this meant adding a lockdown app to unlock the artifact and a special memo hinting at how to figure out the password.
Movement through the ship
There were a few issues here as far as creating our ideal player experience goes
Sticking with the pillar of comfortably uncomfortable
We didn't want the movement to feel bad but wanted to maintain that sort of sense of clunkiness and manual gameplay. Initially, the game felt to hard to control with the player moving far distances, with more delay between input, which we resolved by making the delay shorter and by lessening the power. Additionally, we got requested by a few people to add the option to rotate about the Z (forward) axis to reorient, but wanted to keep this a bit uncomfortable so we opted against it.
This was a tough decision, but after testing, players seemed to gain too much clarity in the zero gravity space from rotating, and we wanted to maintain a bit more confusion and discomfort in the foreign space.
Movement (cont.)
When moving through the space, it was initially too easy to gain speed and navigate quickly.
This was solved through level design (and interestingly, a scare!). Early on, the central hallway was pretty open, and it was very easy for players to just zip up and down the ship incredibly quickly, so we quickly resolved this by adding some haphazardly placed pillars throughout the tunnel. However, players would still overcome this (which was a great moment to watch!), so as a multi-faceted solution, one of the scares we added was moving some of the statues from around the ship to that hallway. This added more obstacles to the environment and added tension to moving through the hallway, which ended up causing players to mess up a bit more.
More things I learned from the project!
Minor changes having MAJOR effects
This was something that really struck me from the GDC talk on how changing the Halo sniper fire rate from something like every .5 seconds to every .7 seconds was monumental to balancing it. Throughout the development cycle, when coming upon a problem, I would always try to come up with the easiest thing that I believed could be the most impactful before trying to majorly change a system.
This looked like the looping audio every minute or so telling the player to use the central computer to fix players not utilizing the computer. Another great example was adding buttons to airlocks to fix players getting locked out of them from odd physics.
How to analyze longer playtests and make changes appropriately
Being that the average run time of the game was about an hour, we spent quite a bit of time just watching the playtests. The hard part here is that we thought about just testing features in shorter sequences, but our main playtesting goal was to create that flow state for the entirety of the game.
An important discussion that came up was how much to simplify things from watching playtests. From the playtests in the earlier sections of the game there was a sort of general sense of confusion, so initially we discussed
Here's a stranger's play through as well if you're interested in seeing more!!
Page updated
Google Sites
Report abuse