Breakdown: How Dark Machine Created a Roguelite Speed-Climbing Game

What were the core design pillars that shaped the game from the beginning?

Holly: The game emerged from the milieu of games and prototypes that we had been working on for years, ideas that shaped its identity even before we knew what White Knuckle was going to be. Because the game didn't emerge as a concept fully formed and only solidified well into development, it's hard to say that we had some core pillars from the very start.

That being said, the design pillars that emerged over time were:

• Everything the player encounters or uses should either force them to progress, help them progress, or hinder their progression so that the thing that is currently forcing them to progress becomes more hazardous. It's all about climbing, about going up, and if our systems don't feed into that in interesting ways, we have failed to make a game about climbing.
• Always surprise the player. An encounter with a new thing should lead to surprise or confusion, followed by a slow and steady understanding. New areas should change up core aspects of play to keep each run feeling fresh as you progress through the environment.
• The game should be strict, difficult, but always fair. This isn't a kaizo game, it's not a rage game. The player should always be able to predict a hazard before it happens, or have enough time to deal with a new one before it becomes fatal. We are pushing people to improve their abilities, not to blame the game for being unfair.
  

The climbing system is central to the experience and feels very physical and high-stakes. How did you approach designing and implementing that system from both a gameplay and technical perspective?

Holly: We knew we wanted to do some sort of climbing x horror game, and to me, that meant physicality. Years prior, I had played some VR climbing games, and the sensation of sticking to an immense wall stuck with me. On the first night of prototyping, I experimented with an idea of making each hand a separate mouse button and put it in a simple cube-laden climbing test environment, and immediately, I saw potential. The systems were rough, but engaging.

White Knuckle's movement is about momentum, the swinging motion between holds, the speed added on every jump, and between every grab. It needed to feel good, and to me, good meant an extremely high level of control, as well as forgiveness. Climbing is already high stakes. Dangling from a dangerous height and making even more dangerous moves will always feel impactful and engaging. So from the perspective of a developer, I wasn't too concerned.

The thing that I had to get right was making it easy. I don't mean making the game easy, I mean making the act of climbing nearly as second nature as walking, so the tension can come from the situations and the tangle players put themselves in trying to solve immediate problems. On a technical level, that ease, that forgiveness, came from what I call the "Lazy Grab" system.

Basically, instead of having to accurately point at a hold and then click the mouse, you can hold down your mouse from the start, and the moment a hold is detected, it will grab. In addition, I gave each hand a short memory of the last hold it saw, so if the player clicked shortly after swinging past a hold, it would grab it as well. Finally, I made it so the quicker the player was moving, the larger their detection radius would be, making speedy climbs or recovery easier to pull off.

All of these meant that in a high-stakes situation, you could always trust in your ability to grab something. You could be falling dozens of meters, and as long as you were holding your hands out, you would be very likely to grab a piece of geometry or a precarious piton. The other side of the coin comes from a gameplay design perspective. White Knuckle is about climbing through an abandoned superstructure, a facility of concrete and steel.

It's not enough to make holds grabbable, I wanted players to be able to climb across anything that feels like it should be a piece of mantleable geometry, from a loose brick in a wall to the edges of pipes and girders. This is an interesting problem to solve. How do you build a grab-point detection system that takes into account world geometry from various angles, and is also controllable by the level designer?

The solution was simple: to build all static world-grab points ahead of time, to have a process that would bake them into their own geometry instead of having to fiddle with advanced detection systems. The generator worked better than expected, and as a bonus, allowed me to directly view what the player could grab while actively making levels.

From a technical standpoint, what engine are you using, and what made it the right fit for a physics-driven, first-person experience?

Holly: We are using Unity, though I'm not sure if it's necessarily a "right fit" sort of deal as much as it is what we were used to. As much as White Knuckle is a physics-y kind of game, the player controller actually doesn't interact with Unity's rigidbody system at all, and has an entirely custom movement and physics system. That was necessary to give me the amount of control I wanted to tune the exact feel of the movement in the game, something that took months of refining.

Can you walk us through your typical workflow for building a climbable environment—from early blockout to final implementation with hazards, traversal points, and polish?

Quinn: Environments begin in Substance Designer as Holly fleshes out the visual/stylistic core of a White Knuckle's region. Those tile sheets are brought into Blender.  One of the biggest strengths of the White Knuckle look (compared to other art styles) is the simplification of the process. For the most part, the blockout/greybox happens at the same time as the art pass.

It's relatively easy to take breaks from working on the level asset in Blender to test the intended routing in the engine, then return to Blender to make more tweaks until satisfied. Once routing is finished, a pass distributing special hazards (environmental hazards, enemies) and item placement happens in Unity.

Holly: We don't really block out most levels in the classic "greybox" sense. I like seeing how the textures and the more detailed shapes inform the design of a space as it builds out. It seems to leave a stylistic naturalism to the environments where one location flows into the next rather cleanly.

It's a strange approach that only really works in White Knuckle's case because the game takes place in an absurdity: An environment where concrete can meet nonsensical machinery, all of it tuned towards the innate player motivation in the game: To Climb.

What are the biggest challenges when designing spaces that are meant to be climbed rather than navigated traditionally?

Holly: An interesting quirk of climbing games as a genre is that they are built around making something that is, in our world, distinct from our natural locomotion and also extremely challenging. Game design, especially in 3D games, has developed around basic models of movement and play that were refined over decades. Walking should feel like this and should use these controls, jumping should use this key, shooting your gun should feel like this, etc.

Climbing is another axis, another mode, and its lingo and design have not been codified into either developer's minds or player expectations. In Portal 2's developer commentary, it is mentioned how difficult it was to make players look 'up' at all, how in many scenarios a player would essentially be softlocked, unable to progress, all because they refused subconsciously to look upwards to find the path ahead.

In a climbing game, "up" is the direction a player is meant to go. That means there is an extra layer of unwanted friction between the player and the world, one that we needed to slowly train the players out of as they progress deeper into the Campaign.

From an art perspective, how do you ensure readability of climbable surfaces, interactable objects, and hazards in such fast-paced, high-pressure scenarios?

Quinn: There are a few ways we keep the readability consistent throughout our levels. Our "Hierarchy of Climbability". The most climbable surfaces are accentuated with color control (if it's meant to be grabbed, it will feature red strongly in its textures) with additional help from baked ambient occlusion to help those elements pop. For the more "incognito" routes, we keep to the rule that if an edge looks like a grab, it should act like one.

We generate "handhold geometry" in Blender with geonodes that are used for detection but hidden in the game. As level designers plan out routes, extra care is spent checking the generated handhold geometry to make sure it is engaging. Distributing our easier-to-see handholds between sections of incognito handholds also helps to cue in players about intended routes and cut down on players getting confused. 

Jack: With how quickly any run of the game can turn on its head, it's paramount to ensure players understand what threats are present in a given space. Early into development, we opted to use a more sparse soundtrack that would play in areas that were generally safe. This makes it so enemy and hazard audio cues aren't fighting as much for space in the mix during tense moments.

A lot of work goes into making sure those cues are readable from distances that someone playing faster will still catch them, but still retain some amount of realism to someone playing at a more methodical pace.

What does your asset pipeline look like for environments, props, and interactable elements, especially given the need for clarity and performance?

Holly: The art style of White Knuckle leads to a pretty simple approach for most of the world's objects: basic modelling, texturing, some Substance 3D work (in both Substance 3D Designer and Painter), and then a final resolution and palette reduction.

Quinn: Interactable elements like the equipment (pitons, artifacts) normally begin life as a high-resolution 3D model in Blender. We kick over to the Marmoset Toolbag or Substance 3D Painter for textures. We typically skip concept painting unless the asset has a high amount of group contention. We render out the individual poses for each animation.

Then, in Aseprite, narrow the color palette and do some paintover work to hit the correct level of grime that's the foundation of the WK look. Taking the finalized spritesheets and authoring the animations in Unity. The entire workflow was designed by Holly to create reasonably good-looking assets without being a heavy GPU lift.

Roguelite games often struggle with balancing randomness and fairness. How do you approach procedural or semi-procedural design to ensure each run feels both unpredictable and intentional?

Holly: Early on in White Knuckle's development, we decided we didn't want to do true procedural generation. Each level in the game is hand-designed, with a couple of minor elements, and then shuffled so the variations you see and the order they are in feel random. We want players to be route-reading when they come across a new room, but then optimizing their routes when coming across rooms they have seen before.

To keep things engaging, we inject new rooms into earlier areas as the player progresses further into the Campaign, so as long as they are getting somewhere new, they will see even more new things when starting over.

What tools and software are central to your development pipeline across disciplines?

Quinn: Blender, Aseprite, Substance 3D Designer, and Unity.

Holly: Ditto.

Jack: White Knuckle's audio is created almost exclusively in FL Studio and uses a wide range of 3rd party plug-ins. Native Instruments Kontakt libraries appear frequently in the game's music, alongside free instruments like Synth1 and Atonoise Pro. Many of the sound effects are recorded in-house as well, using an H4N Zoom recorder for Foley.

White Knuckle doesn't use any middleware for its audio processing because none of us on the team had experience with it prior to starting work on the game, but we do intend to rectify that with future projects. Holly has done an excellent job creating tools in Unity to make the process significantly easier for the time being.

How has community feedback during Early Access shaped the direction of systems like progression, difficulty, and new content?

Holly: A big reason we wanted to take the Early Access route was so that we could see what the community thought about all sorts of different features. We just released a massive Anniversary Update, which was this big shift up to the metaprogression of the game, many ideas, and QOL features that had percolated over the last year as we watched our players engage with the content the game had to offer.

The economic changes, in particular, came out of dozens and dozens of discussions with the wider community. Early Access is most valuable because you can change direction based on how players receive each feature. It's worth listening to them even in just the abstract because if you do, you will have new ideas spring to life that will better the experience for everyone.

Looking back, what were the biggest lessons learned while developing White Knuckle as your first project as a studio?

Quinn: How important is momentum to our process as a studio? White Knuckle, since its inception, has been developed at breakneck speed. It's placed good scope limitations, kept community engagement high, and really set a "flavor" we return again and again to mine more ideas from.

Holly: How to manage our time, I think. We are ambitious to a fault, and often overextend ourselves. White Knuckle has taught us how to better plan and how to let something go if it's holding us back.

Jack: Finding a good balance between the more evocative or strange design choices and the more grounded ones. This has allowed us to have very easy and fast discussions when adding new elements to the game or marketing it. An example is a currency system that allows you to buy tools and perks to progress the game, but the currency is insects that can be killed. If an idea doesn't meet our gut feeling about what makes White Knuckle what it is, it's very easy to scrap or begin fleshing out.

Finally, are there any behind-the-scenes materials—such as greybox levels, debug tools, or system breakdowns—you can share to help developers better understand how the game is built?

A screenshot of a later region's levels in Blender.

The "Generated Handhold" geometry (marked in red) is automatically applied as we model our levels, which makes it really easy to know what kind of climbing environment we are creating.

One of the few cases where we did some rough greyboxing (in the same general environment) and route planning.

A screenshot from the first night of prototyping, after we got the basic climbing mechanics in.

Screenshot of an early AI test for an NPC that could climb on walls.

Dark Machine Games

Interview conducted by David Jagneaux