I’ve been tinkering with a new prototype for the Dim Road on and off for about a month now, and thought this would be a good time to provide some context for where it is heading. For a description of the game as a whole, you can check out the portfolio entry for the game on my site here. I went with a pre-made character controller as a starting point for movement and camera control, and added many of the game’s essential actions such as picking up and dropping cubes, breaking-open compacted trash, and re-compressing it (from the previous build).

I also managed to go further and included some actions that didn’t make it into the previous build, such as crouching and crawling, and storing a cube on your back.

In addition, I decided to tackle a bug from the previous build. It was extremely easy to force cubes out of bounds by picking them up and shoving them into walls, and given that some of the objects the player carries around will be rare and essential to progress, it was important to address the issue in this version. To fix it, I set up a script that pulls held objects to a given location if displaced, and forces the player to release it if the object is ever displaced enough. In essence, if the player bumps into a wall or other object while carrying a cube, odds are good that it’ll fall out of their hands. Since it kicks in before the player can jam it half-way into a wall, bug fixed (for now).

Now onto the meat of the post: Collapsing terrain.

For the game’s core loop to work (scavenge for supplies, solve puzzles, move on before the section collapses and crushes you), the rooms and hallways in a given level needed to be able to collapse on the player. That meant I would need to move away from gray-boxing whole hallways and rooms and instead start working on new concepts for walls, floors, ceilings, and set pieces that could be segmented further. Eventually I settled on 4 main categories of environmental objects: Tunnel Walls, Dressing, Break-Aways, and Loose Objects.

• Tunnel Walls: These make up the bulk of the game’s structure. The floors, walls, and ceilings all fall under this category. I identified size ranges for rooms and corridors, made some mock-ups of modular parts, and assembled them into prefabs in-engine. The rule of thumb is for each floor, wall, and ceiling in a corridor or room, there are at least 4 different parts that can be moved for a collapse sequence, with joins at the seams of the texture.
• Dressing: These are sturdy parts of the level design that will shift with the Tunnel Wall parts. They are designed to be anchored to one or more parts to movie in-unison during a collapse and exist to help break-up the otherwise cube-based environment. I’ve added some support beams and a light fixture to the roof as dressing.
• Break-Aways: These are mostly cosmetic elements, like Dressing objects, except they are built to break off of the objects they are anchored to during a collapse sequence and are affected by physics. This can include loose wall panels, grates, light housings, signs, or other less-than-sturdy parts of the environment. As an added twist, I’m planning to add a “bash” verb to the player’s arsenal of actions, allowing them to kick or punch these objects loose in-addition to other gravity based objects. This corridor has riveted strips on the sides that are built to come off during the collapse animation.
• Loose Objects: These are objects that will freely move around during a collapse animation using gravity, but can also be interacted with by the player. This will include debris cubes, utility cubes, items, tools, rubble, or any Break-Aways that have come loose from their section. 

With these categories settled, there are three other major factors that needed to be considered for the collapse mechanic: How it’s triggered, how to communicate the mechanic to the player, and ultimately how the parts will actually move to achieve the collapse.

For this demonstration, I implemented a couple of hotkeys to trigger collapse stages for testing purposes. In the next build, each corridor and room will have its own Stability value, not unlike a health bar. Each region will also have a collective stability value, and if the region’s stability is low enough, it will trigger a collapse sequence. Most actions that the player can perform will reduce stability in their area, from breaking apart debris cubes, dropping objects, bashing things, and traveling long distances. Stability will also decrease every few seconds if the player hasn’t reduced the region’s stability recently. This will help create some pressure on players that might have stopped to craft, strategize, or manage their inventories. Consider stability like a dynamic time limit, or a limit to how many moves you can make in a puzzle game. The player will be challenged to use an area as effectively as they can before they are forced to move on, and the primary loss condition arises when they way forward is blocked off and they haven’t come up with a solution by the time a collapse really starts.

So how does a player know how much time, or how many moves they have left in an area?

The simple answer is that they won’t know, and will need to prioritize clearing an exit route. The more complex answer is that collapse occurs in stages, and these stages are communicated to the player through the environment. An area has 4 different states, and the transitions between them are where collapse occurs.

1. Intact: The area is mostly undamaged and isn’t showing any visible signs of instability apart from the general appearance of disrepair that the environment has.
2. Damaged: The area may collapse soon, and has sustained significant damage. The changes to the environment don’t really impede movement yet, and its mostly slight shifts where wall, ceiling, and floor parts join with each other, creating the impression that they are starting to crumple or buckle a little. This stage isn’t as clearly communicated in the test gif as I’d like, so in future iterations the Damaged and Doomed states will both be more extreme.
3. Doomed: The area is now so unstable that it can collapse at any moment. If the player leaves a room or corridor that is doomed, and is heading towards an exit, it will collapse automatically beyond a certain distance (to prevent back-tracking, and to add excitement to the sequence). Otherwise, the area or region is now on a timer, and will fully collapse when that timer expires. Doomed areas have more shifting of parts than damaged ones, and it can often contribute to obstructing player movement if debris or floating objects weren’t moved out of the path.
4. Fully Collapsed: The area is inaccessible, the ceiling is essentially touching the floor, and the player will have lost the run if they were in the area when it was coming down. After a little bit of time, the game will remove fully collapsed areas except where they border an un-collapsed region that the player is currently in.

As an extra layer of support for the collapse mechanic, I plan to include three other features to help communicate the state of the environment to the player: a light-flickering script that causes overhead lights to blink randomly for a second at each step (placeholder implemented) a diegetic HUD element that displays a stability warning for different collapse transitions (that I plan to implement in the next build), and dynamic music that becomes more driving and rhythical and less ambient as an area gets closer to collapse (that I plan to implement in a future build). There will also be sound effects that play when structure damage occurs, be it a creak, snap, clunk, or ominous musical sting.

Lastly, a quick explanation on how I’m actually collapsing the levels. For starters, I’m using a basic animator to animate each room and corridor rather than using a truly dynamic destructible environment. Transitions between the major collapse states leading up to “doomed” will be fairly uniform, however the animation to collapse a segment the rest of the way from doomed will depend on the location/route of the player in relation to the segment in future builds. Each segment could have a different collapse animation from doomed for each of its exits, so that regardless of what direction the player is traveling in, it can collapse in a visually dramatic way, as if the player is staying just barely ahead of certain doom. This will also allow me to collapse a section in a way that doesn’t expose the blank void around the tunnels, or allow the player to travel out-of-bounds. To avoid coming up with some kind of pathing script, here is how I’ll determine which final collapse animation will be played. “Target Exit” in these points refer to the last part of a section to collapse during the sequence, or the general direction that the section will collapse towards.

1. If the player has exited a doomed segment, triggering the doomed-to-collapse event, whichever exit the player used is considered the target exit (overriding all other factors).
2. If a segment is part of a dead end, the furthest exit from the dead end is considered the target exit. This could be done using a script that flags dead ends during level creation, and sets target exit variables automatically.
3. If a segment is not part of a dead end, the closest exit to an “open” region-transition is considered the target exit by default. Basically wherever is closest to the goal.
4. If an adjacent segment is fully collapsed already, the furthest exit from that opening is the target exit. This overrides cases 2 and 3.
5. If no target exit was set, one of the collapse animations is considered the default. It is a direction-agnostic animation that is built first (for simplicity’s sake). These will be built to collapse in the center first, and radiate towards all exits from there.

I’m hard at work on this version of the Dim Road prototype, and hoping to make a new build publicly available towards the end of August 2022. Until then, watch your head.