OZARK: Creating a Dark Story-Driven 2.5D Action-Horror Game

OZARK is described as a dark, story-driven 2.5D action horror game built for a short, intense playthrough. What was the original creative vision for the project, and how did you define the kind of horror experience you wanted to create?

OZARK actually started much more simply than what it eventually became. The first version was essentially an experiment to see if we could make a 2.5D side-scrolling shooter work using a simple sprite, a locked camera, horizontal movement, and some freedom in depth. Horror was always somewhere in the back of our minds visually, but there wasn't this enormous master document outlining exactly what OZARK was going to become. Once more of us became involved, the ideas started bouncing back and forth, and the story and world slowly evolved around what we were making.

For us, horror can mean a lot more than simply frightening the player. It is about generating an emotional response. Fear is part of that, but so are uncertainty, tension, panic, isolation, and even existential discomfort. Some parts of OZARK can become extremely intense, while others slow down and allow the player to sit in the atmosphere and wonder what is coming next. There is even a sprinkle of humor in there because contrast can make the darker moments hit harder.

We also didn't believe that giving the player weapons meant they could no longer experience horror. You are playing a capable character, but that character can still experience the psychological weight of what is happening around them. If players dig into the lore, there are some much stranger existential ideas beneath the surface involving biological experimentation, alien influence, technological inevitability, and the consequences of creating things that perhaps shouldn't exist. We wanted the world itself to become disturbing, not simply the creatures inhabiting it.

OZARK uses a side-scrolling perspective but presents itself with realistic 3D visuals. What made 2.5D the right format for this story, and how did that perspective shape the way you approached level design, camera framing, and environmental storytelling?

The format really came before the story. OZARK began as an experiment with 2.5D movement, and we simply kept exploring what was possible within that restriction. One of the biggest advantages of controlling the camera is composition. We can build moments almost like individual shots in a film. There are still certain camera angles in the game that I love playing through simply because of how everything happens within the frame.

Everything is composed fairly organically. We build environments by hand, move the camera around, change lighting, move props, play the section, and keep experimenting until something feels right. The environment can influence the writing, and the writing can come back and change the environment. There wasn't always a strict order to that process.

The fixed perspective was also one of our biggest technical burdens. As soon as you give players freedom to move into depth, a supposedly simple side-scroller becomes much more complicated. Aiming was probably the clearest example. In a completely fixed plane, you largely have to worry about aiming toward positive or negative X with some vertical influence. Once the player moves freely in depth, target selection and aiming become much harder.

Controller was our original focus partly because of that. The aiming and target-locking system has a particular feel that solved many of those problems. Then we went through Steam Next Fest and received a lot of requests for mouse and keyboard support, which forced us to rethink the problem again. Mouse aiming naturally became much more like point-and-click shooting, so we effectively ended up supporting two slightly different ways of experiencing the combat.

Enemy behavior also had to be designed around the camera. How quickly can something enter the frame? How much pressure can an enemy apply while offscreen without feeling like it is cheating? Can it throw grenades or chase the player into the visible space? There is a constant balance between using the limited view to generate tension and still giving the player enough information to react fairly.

Can you walk us through the art production pipeline for OZARK, from concept art and reference gathering to modeling, texturing, animation, lighting, VFX, and final in-game implementation?

Our process is probably much less formal than people might expect. Most environments begin as an idea, a gameplay space, or even just an atmosphere we want to explore. We will start blocking things out, kitbash different pieces together, and then spend a lot of time experimenting with how light interacts with that environment.

The assets themselves are a mixture of things we've made and marketplace assets that we heavily modify. We never had the budget or team size to create every nut, bolt, and wall panel from scratch, so we became very comfortable taking pieces from different sources and transforming them into what we needed.

I've joked that the process is a little like Sid from Toy Story. We take everything apart and rebuild it into something else. That might mean completely retexturing an asset, altering decals, recoloring it, modifying the mesh, combining several models, taking character bodies apart, or binding different head meshes onto them. It is a very maker-oriented approach: play with things, break them, rebuild them and find something interesting.

Our usual environment flow is roughly greybox, props and environment work, followed by a very large amount of lighting, atmosphere and color work. Blender and Cinema 4D are both part of our modeling workflow, and Substance Painter is indispensable for texturing. I'm also probably one of the few people still clinging to Fireworks CS for texture and UI work. I have never really enjoyed Photoshop, and there are some old tools you just become incredibly fast with after years of using them.

Animation is equally mixed. We use commercial animation libraries, Mixamo, hand animation, and custom work, and fortunately we also have access to a Vicon motion-capture system. That allowed us to capture custom performances for some of OZARK's larger story sequences.

Lighting is predominantly real-time. There isn't much baked lighting in the game. Fog, particles, post-processing, and environmental effects all contribute heavily to the atmosphere. One technique that became an important part of OZARK's identity was lighting the underlying world extremely low while maintaining areas of contrast and then using post-processing to bring that image back out. It produces a particular grainy, imperfect quality that we really like.

We are constantly adding grime, damage, wear, and tiny environmental details as well. A clean facility simply says that a facility exists. Grime can suggest that people worked there, something happened there, and time has passed. Our professional work involves building simulations, so environmental and prop-based storytelling is something we have always cared about. Small details can convince someone that a space has actually been lived in.

What software, engine, and tools are being used to build OZARK, and how did those choices affect the team’s workflow for creating realistic environments, characters, horror atmosphere, and co-op gameplay?

OZARK is built in Unity. The project originally began around the 2018–2019 generation of the engine, and over roughly six years of development, we upgraded it several times. We are currently on Unity 2022 LTS using the Built-in Render Pipeline.

There is sometimes pressure to continually move toward whatever the newest rendering pipeline or engine technology happens to be, but we knew this pipeline extremely well. Our professional work was also standardized around Unity 2022 LTS and Built-in, so it allowed us to use techniques we had already spent years learning. You can still get an enormous amount out of that renderer, and OZARK is probably a good example of how far it can be pushed visually.

Most of the game's systems were written by us. We did bring in a handful of larger third-party systems where it made sense, such as NGSS for shadows and some IK solutions, but much of the gameplay architecture, interaction, camera behavior, AI, and supporting tools grew internally with the project.

There was an interesting downside to developing something over such a long period while also running a studio full-time. You sometimes return to a system you built years earlier and have to remember exactly what your past self was thinking. Maintaining that mental map of all the interconnected systems became a challenge of its own.

Our background in VR and simulation development definitely helped. In that work, you constantly deal with interaction systems, real-time performance, animation, spatial readability, tools, data management, and unusual input problems. OZARK gave us somewhere to take all of those disciplines and apply them toward entertainment instead.

Co-op is fundamentally built around the local experience. Steam Remote Play Together then allows that couch co-op game to be streamed to another player without us having to transform OZARK into a traditional networked multiplayer title.

How do you balance action and horror so the player feels capable enough to fight, but still vulnerable enough for the world to feel dangerous?

Having a gun doesn't mean you're invincible. The player still bleeds. Weapons still need to be reloaded. Enemies can group together, attack aggressively, and turn one small mistake into a much larger problem very quickly.

We dare players who assume that being heavily armed means they're safe to step into OZARK — the game is quick to challenge that idea.

Different enemy types create different kinds of pressure as well. Some are lethal in very direct ways, while others contribute to a situation becoming increasingly difficult to control. That uncertainty is important. You might technically be capable of killing what is in front of you, but that isn't the same thing as being comfortable.

We wanted combat to generate its own form of horror. Reloading at the wrong moment, being pressured from outside the frame, getting separated from another player, or suddenly having several enemies collapse onto your position can create tension naturally rather than requiring us to constantly take weapons away from the player.
The balance we were looking for was essentially: "I can fight this" rather than "I'm safe from this."

The game supports solo play, local couch co-op, and online co-op through Steam Remote Play Together. How did co-op influence the game’s design, especially around pacing, encounters, item sharing, exploration, and readability in a side-scrolling space?

Co-op has always been a central part of OZARK. Having another person there completely changes the emotional experience, but it doesn't guarantee either of you will survive.

Players can share items, cover each other, and move through encounters together, but they can also separate. That led us to spend quite a bit of time thinking about how cameras should work in a game like this.

We eventually built three different co-op presentation modes. Forced Split Screen gives each player their own camera. Split-Distance keeps both players together on a shared camera and dynamically splits when they become separated. Forced Single keeps everyone within the same camera space and effectively forces players to stay together.

Each creates a surprisingly different feeling. Forced Single can become cramped and tense because both players have to negotiate space together. Dynamic splitting gives players more freedom to explore independently, while permanent split-screen gives each person much greater autonomy.

The important thing for us was that co-op should add another layer rather than replace the original game. You can watch each other's backs, share resources, and coordinate during encounters, but OZARK wasn't designed around forcing two people to stand on switches or constantly solve dedicated co-op puzzles. Solo play still needed to feel completely valid.

OZARK’s tone appears to combine military rescue/recovery, science-fiction horror, investigation, and gore. What were some of the biggest artistic inspirations behind the game’s creatures, facility design, lighting, materials, and overall mood?

Films were probably our biggest influence in terms of atmosphere. Movies like The Thing, Event Horizon, Scanners, Die Hard, and a lot of the science-fiction and action films from that era have an incredible visual character to them. The filmmakers of that period were masters at lighting dark spaces. Practical lights, smoke, silhouettes, deep contrast, grain, and imperfection simply look fantastic on film, and we wanted some of that feeling inside OZARK.

The creatures are rooted in mutation and biological experimentation — but there's another influence that starts entering spoiler territory. There is an alien component underneath some of what is happening, which allowed us to push the designs beyond straightforward human experimentation and into something increasingly unnatural.

The facility itself also has a Canadian influence. We sometimes feel Canada is underrepresented in games, especially in this kind of science-fiction setting, so we deliberately wanted OZARK to feel connected to where we are.

SNOLAB was one of the interesting real-world inspirations. It is a major underground science facility here in Sudbury, Ontario, built deep underground in an active mine. Spaces like that already feel mysterious because you have sophisticated scientific infrastructure surrounded by exposed rock and an environment that has literally been carved out to support the work happening inside it.

That collision between technology and geology helped inspire OZARK. Concrete, industrial materials, rock, machinery, scientific equipment, and infrastructure all exist beside one another instead of the world feeling like a perfectly manufactured science-fiction spaceship.

We also deliberately weather environments. Grime tells a story. It says people used this equipment, something happened in this room, and some amount of time has passed. A perfectly clean laboratory often loses that history. Because our day jobs involve simulation work, we have developed a real appreciation for visual storytelling through props and environments. Sometimes a dirty coffee cup or an abandoned piece of equipment does more to sell a space than another paragraph of exposition.

Because the game is designed as a focused 3–6-hour experience, how do you think about pacing? How do you decide when to escalate combat, reveal story details, introduce new threats, or give players a moment to breathe?

A lot of OZARK's pacing honestly came from the creative process rather than a rigid pacing formula.

We would build something and ask what felt right there. Sometimes the environment inspired a story moment. Sometimes something in the story made us completely change an environment. An encounter might cause us to rethink what happens before or after it. There was a lot of back-and-forth between writing, world-building, and gameplay.

That naturally produced different rhythms throughout the game. Some sections apply heavy pressure while others slow things down and allow the player to absorb the environment or start questioning what they have seen. Enemy types also change, which lets us create different kinds of tension rather than constantly relying on the same form of combat.

The audio tapes are part of that as well. Someone who simply wants to move forward can maintain a fairly fast pace, while players interested in the lore can spend considerably longer finding and listening to those recordings. There is a surprising amount of story buried in them.

We wanted the overall experience to feel closer to watching a film than committing to a giant game. Depending on how you play and how deeply you explore, the runtime can change, but the intention was always to keep things moving.

Speaking of the game's length, what did your market research tell you about games of that scope and why did this feel like the right genre pairing for a tightly focused experience like that?

There really wasn't any market research. We didn't build OZARK by looking at spreadsheets, identifying a market segment, or trying to determine what campaign length would maximize revenue. We were friends making something at night because we loved making games and wanted to see what we could create.

The three-to-six-hour scope eventually emerged from the project itself and from being realistic about what a handful of people working around full-time jobs could actually finish to a level we were happy with.

It also happens to fit how we increasingly like to consume games ourselves. There are so many games competing for people's time now, and not everybody wants every experience to become a 40, 60, or 100-hour commitment. OZARK is almost deliberately going in the opposite direction. We wanted something someone could sit down with, become immersed in, and actually finish.

We never really thought of the short runtime as a weakness that needed to be disguised. It is part of what the game is. We would rather create a focused experience than stretch the same content simply to increase the number beside "hours played."

There are also reasons to come back. Co-op dramatically changes how encounters play; there are different difficulty options, and we're interested in supporting the speedrunning community. After playing the game ourselves for so long, we've discovered that OZARK is actually very enjoyable to speedrun. There are many small opportunities to shave time from a run, and we'd like to expose more tools around that.

Ultimately, though, there was no financial equation behind it. OZARK exists because we loved making it.

For 80 Level’s audience of artists and developers, what has been the most difficult part of making OZARK feel cinematic, readable, and technically polished while still preserving the immediacy of a side-scrolling action game?

Lighting and presentation have probably consumed more time than almost anything else. We spent hundreds of hours refining the relationship between our environments, real-time lights, post-processing, color correction, fog, effects, and the final image on screen. Because the game is so dark, relatively small changes can completely alter the mood of a scene or make important information disappear.

Readability becomes particularly interesting because we don't necessarily want perfect readability. Horror benefits from uncertainty. If we simply put a giant rim light around every enemy, the game might be clearer mechanically, but we would lose part of the atmosphere we spent so much time creating.

Instead, we use several smaller cues together. Many enemies wear bright orange jumpsuits, with variations helping distinguish enemy types. We use contrast, lighting, silhouettes, environmental composition, and camera framing to draw attention without completely separating characters from the world.

There is always a negotiation between readability and uncertainty. The camera itself creates another huge group of challenges. Enemy behavior, offscreen pressure, player reaction time, and aiming all have to respect what the player can actually see. An enemy attacking from outside the frame can create incredible tension, but if the player believes the game is simply cheating, that tension becomes frustration.

That tension describes a lot of OZARK's development. Many of the hardest systems are things players hopefully never consciously notice. When the camera transitions correctly, an enemy enters at the right moment, aiming selects the target you expected, and the lighting draws your attention toward the right part of the screen, it just feels natural. Getting all of those invisible pieces to cooperate took an enormous amount of iteration.

In many ways, OZARK became a love letter to game development for us. The project forced us to touch almost every discipline: design, lighting, shaders, characters, animation, motion capture, timecodes, engine work, tool development, gameplay architecture, and data management.

It started as an idea to try something different and gradually became this short story-driven side-scroller through years of late nights, arguments, experiments, development struggles, and the joy of finally seeing people react to something we had created.

We learned an incredible amount from it. Hopefully someday we can take everything OZARK taught us and put it into a sequel or another project and make something even better. More than anything, I hope seeing a project like this encourages other developers to try making the thing they have in their head. You don't have to be an expert at every discipline. Sometimes you find another way to make it work.

Alter-Boy, Indie Game Studio

Interview conducted by David Jagneaux