BURNING UP: A DOOM CUSTOM LEVEL

SUMMARY

As an homage to the single-player campaign of DOOM's 2016 remake, I created a new campaign level entirely within SnapMap. The editor provided many interesting constraints, and the finished level contains several technical achievements which aren't supported by default.

KEY DISCUSSION POINTS

Principles of DOOM's level design and combat, and how they're reflected in the experience
Explanation of process from start to finish, including paper design, themes and iterative development
Technical achievements, including creating a checkpoint system by rewinding game state in an editor which only partially supports it
Overcoming technical constraints and limitations to deliver a brief

ROLE

Designer, Engineer

TYPE OF WORK

Personal project - custom map (2024)

PLAY IT!

Enter code VUVXKZ8A in SnapMap to play

SELECT A VIEWING MODE

Text highlights with option to expand

All text shown with no need to click

VIDEO PLAYTHROUGH

It was important to me that my level should be played by people who weren't familiar with the layout to get accurate feedback! The video here is of a friend of mine playing through the level from start to finish. All I'd told him in advance were a few technical differences to the campaign, and that (as with the campaign) there were some secrets to be found in the map. He found 2 of the 3 secrets. If you'd like to skip to particular sections, links are provided throughout this article to the relevant times in the video.

Please note: the level uses many of the same assets and the same combat as the DOOM 2016 campaign (an 18-rated game) and so the video has violent content throughout. As such, it can't be embedded and so you'll need to click to go through to YouTube directly.

Click for YouTube playthrough

TECHNICAL ACHIEVEMENTS

CHECKPOINT SYSTEM

SnapMap provides some support for checkpoints, allowing mappers to rewind health, armour, ammo and progress within an individual objective. However, rewinding of game state more generally is not supported. There were a few solutions I considered:

Using SnapMap's "persistent integer" feature - this would allow us to restart the game at a designated checkpoint and fast-forward the game state, but as we have no control over the wider game flow it would require the player to go through a lobby.
Introducing a "lives" system - I felt it would be too frustrating to reset a player's progress entirely given the length of the level.
Respawning the player without rewinding game state - playtests of this during level creation felt very arbitrary and led to negative play patterns such as luring demons out of locked-down rooms in which they'd spawned.

In the end, I decided to build an entire checkpoint system in-game. Each room has a reset function which rewinds everything to its base state, and which functions are called is determined by checkpoint status which is updated throughout the level. There's also extra global logic which handles anything common to all rooms, such as the destruction of AI. To avoid breaking player immersion and to allow them to see what they died to, their camera fades to black and the reset begins at the instant the fade is complete.

I also created an inverse of the checkpoint system - a "fast-forward" system using room completion functions, which allowed me to debug parts of the level quickly without having to play through the whole thing. This saved me considerable time during QA.

The only thing I wasn't able to do was remove evidence of prior fights, eg. bloodstains from slain demons, as these are applied dynamically as decals to the geometry and don't have any associated logic within SnapMap. The checkpoint system can be seen in action during the playthrough here.

RANDOMISED AMBIENT SOUND SYSTEMS

Key to developing the feeling of a facility falling to pieces around the player was sound. It's not enough for them to walk through a series of rooms and see some fires and explosions - the sounds within the facility have to be narratively consistent.

SnapMap provides support for adding "roomtones" to modules. These are effectively ambient sounds which play in the background as a player walks around the level to keep it from being silent. While they're extremely useful, they're also - by design - simple, quiet sounds like outdoor air or the hum of a server room.
I augmented the roomtones with a randomised ambient sound system of my own creation, using SnapMap's selection of mechanical screeches and echoing clangs. Some of these are scripted when the player enters a corridor, but in most cases they work as follows:
The player enters a room, and starts a repeating timer.
When the timer hits zero, a screech or clang plays from a 3D speaker in a random corner of the room at a greatly increased volume; the player is guaranteed to hear it, but often they'll sound distant or "in the walls" due to their locations.
Each time a sound effect plays, the timer is reset to a random duration.
As the player moves through the facility, the timers speed up to create an increasing feeling of something going wrong - for example, the maintenance room at the start is 15-30 seconds per noise, whereas the emergency exit room before the final stairwell is 8-15 seconds.

There's a roughly 1-minute portion of the playthrough where the player runs around an already-completed room so you can hear the ambient sounds in action - click here to watch.

EXPLODING CORE SET-PIECE

The big peak of the level comes at the end: the player is fighting up a stairwell to escape, with the facility exploding beneath them and demons spawning at the top to push them back - click here to see this section of the playthrough. This was the hardest part of the level to engineer; here's a brief journey of the set-piece:

My initial plan was to have a moving hazard volume and enable explosions/fires when they came into contact with the volume. Unfortunately, SnapMap does not support moving objects at runtime - every object has to be pre-placed. This led me to the floor-by-floor approach which made it into the finished level.
All the fires and explosions start out as invisible, and are enabled on timers. Each floor has a static trigger volume which is enabled once the fires appear; if the player moves into the trigger volume, the room's environment blends quickly from "Hot" to "Molten" and the fire damage effect appears on their screen to give a visual explanation that the player is taking damage.
On each floor there's also a trigger volume which spawns demons of increasing difficulty based on how far up the player has climbed.
Initially, I had planned to spawn demons in front of the player as they ran up the stairs, but couldn't get this to work. After some debugging, I discovered that SnapMap does not allow demons to spawn near a hazard, even if that hazard is invisible or disabled.
When playtesting, though, the "demons coming from the top" approach was actually more enjoyable so I embraced the situation and leaned into it! I adjusted the demon spawns to frontload the encounter with weaker, faster demons to reduce the amount of time before the player would see enemies.
I was pleased with the outcome, although there were some things I'd do differently in another editor - in particular, I'd experiment with a mid-stairwell block to provide the player with a simple problem to solve under pressure and break up the stream of demons.

LEVEL DESIGN PROCESS

INITIAL PAPER DESIGN - BRAINSTORMING

I began my level design process by trying to understand the restrictions, the goals and the context of the level. These helped me get a good start on the level without feeling like I was working with a blank slate!

Restrictions are technical limitations which I'll have to work around or which may affect what I'm able to do. With an existing editor like SnapMap, these limitations are largely fixed; working internally in a studio, there may be scope to discuss with other teams what's possible and what can be feasibly added in the available time. This was my first project in SnapMap, so I was still a little unsure on some of the restrictions.
Goals are the big themes the level wants to hit. In this case, we're escaping from a burning facility, so we want the player to feel the urge to keep moving as things are collapsing around them. DOOM's combat design mantra was "push-forward", and so this desire for movement and speed naturally lends itself to combat over exploration.
Context is the position of the level within the overall structure. As this was a hypothetical level I envisaged it as being mid-way through the campaign and tuned the difficulty appropriately.

After establishing these, I started brainstorming the rough beats of the level. Early on there were a few extra ideas which didn't make the completed level - a vents section was cut almost immediately as SnapMap's geometry didn't seem to support it, and there was an end-of-level fight after the stairwell which was cut later on due to it not fitting the pacing curve particularly well.

Incidentally, I had a strong idea from the start of the pacing curve I wanted to achieve - escalating periods of stress with time for breathers in-between - and feedback I got on the level suggested that the pacing ended up being good!

INITIAL PAPER DESIGN - LAYOUT

My second step was to create a rough layout for the level. There were a lot of changes between the paper layout and the finished product, but the general structure of the level is similar.

There's an introductory room which sets the scene.
After that, the player heads into a "hub" area with two power core stations serving as a landmark.
There's a short non-linear section where the player can go to each side in the order they choose to retrieve power cores.
Then there's an intermission as they crawl through some vents (this was cut quickly due to technical restrictions).
The emergency exit fight is there, and the exit is destroyed.
There's a slight breather before the stairwell, allowing the player to stock up.
The stairwell set-piece is followed by a big end-of-level fight to get outdoors - this remained for some time, but ended up being cut due to pacing concerns.

One thing I'd do differently at this point, with the benefit of hindsight, is to have more clarity over the themes of the individual rooms. For example, why are there two wings leading out from the facility? What are they? While iterating on the level, I added decals as signage around the facility to help guide the player, but realised as I was doing it that I had very little idea what these rooms actually were - which led to some hasty re-doing of props and effects in order to fit the new themes.

INITIAL BLOCKOUT IN SNAPMAP

After getting a rough layout down on paper, I began blocking out the level in SnapMap - clipping a bunch of rooms and corridors together to get a feel for scale and structure. I wasn't too worried about which rooms I was using at this point; I mostly chose them for the numbers of doors they had, and some elevation changes.

One thing which I cut while blocking out the level was the aforementioned vents section, but there were three other changes which quickly became apparent when walking through the level:

The two non-linear wings in the repairs section were much too large, and a considerable amount of time was just spent walking through the corridors. I changed this shortly after by having the encounter rooms which dropped the cores open up straight back into the hub, with a direct line of sight to the power core station to help the player with their mental map.
The underground tunnel between these two encounter rooms also didn't work - the elevation changes involved and the distances were too large, which led to a lot of boring running and potential for getting lost.
I was already pretty close to the object limit even before adding any logic, so I also cut almost all of section 5 on the paper layout - I ended up achieving the desired breather by having the player take an alternative route through a room they'd already cleared.

At this point I also recorded a video of me walking through the empty level, which you can watch if you'd like to hear my thought process.

ITERATION AND FEEDBACK

ITERATION

Development from here was an extensive process of iteration and playtesting. While there was assorted polish at every stage, here's a rundown of my iterations on the level, and any major decisions that were made along the way:

v1 and v2 were blockouts. v3 added quest objectives/items/logic, placeholder encounters and a placeholder checkpoint system to allow me to quickly test sections of the level.
v4 concentrated on sound, adding music, voice lines, roomtones, and the airlock sequence at the beginning. Initially the music was from a variety of tracks, but after testing this version I reduced it to two for cohesion.
v5 had the first version of the stairwell encounter, and I added scene-setting explosions and fires in several places. Testing this version, I realised it also needed something extra sound-wise for v6. After testing the stairwell and realising how intense it was, I was fairly confident I'd cut the final room - but left it in for the time being.
v6 added - as a result of the v5 playtest - the randomised ambient sound systems. I also added signage around the level to guide players, and the three secrets.
v7 was mostly concentrated on visuals - adding props and scenery throughout the level, plus point-of-interest settings for the power core stations.
v8 was where I finally removed the last room, making the stairwell the final encounter. Now that geometry was set, I also tuned combat encounters and added pickups throughout the level. This version was still using AI-generated encounters, and playtesting of them didn't feel great so I changed that later on.
v9 added the formal checkpoint system, which was probably the biggest individual chunk of work. Playtesting this reinforced my feelings from v8, as the random encounters were different after you respawned.
v10 was finishing touches and bug-fixing. The last change I made was to individually select which demons spawned during encounters to best fit the chosen rooms/geometry, rather than relying on automated spawns. I also added exploding barrels to benefit players with a more opportunist playstyle! From here, the rest was QA and bugfixing.

Perhaps amusingly, the very last thing I did on the level was name it!

PLAYER FEEDBACK

After finishing the level, the first thing I did was find someone else to play it! My perspective as a designer is affected by the fact that I know the layout of the level and structure of the objectives, so it's always good to get another person to take a look.

I gave the level to a friend of mine, mentioning only that there were a few technical differences to the campaign and that there were some secrets in the map. Here was some of the feedback we discussed:

He got a bit lost in the hub section with the two power cores, and felt disoriented when trying to assess his location as the power core was picked up and the door unlocked. We discussed making the layout in each wing symmetrical, though my preferred solution would be to add distinguishable landmarks to help the player orient themselves when a locked door opens.
At one point he experiments by jumping into what turns out to be a death volume and gets disoriented when respawning. The respawn point is placed in a random corridor and the player is facing the correct direction, but we could potentially move the respawn point into the hub itself to immediately trigger the voice lines and points-of-interest that would make the location more clear.
That death volume isn't editable in SnapMap, but in a different editor I'd also consider making it into a hazard volume which slowly damages to make falling into it less punishing (particularly given how much progress it resets).
The final and biggest piece of feedback concerned enemy AI. In DOOM's campaign, once the last elite enemy in a wave is killed, all the smaller enemies seek out the player to avoid them having to search the room. In SnapMap, however, there's no support for this - spawned AI can't have their behaviour changed from a single default mode, leading to frustration when tracking down the last enemy in a wave and also a potentially false sense of relief that the pacing is slowing. The best example of this can be seen in the playthrough here, where one elusive Imp prevents the next wave from spawning.
One thing I'd experiment with if faced with the same restrictions again would be a system which detects when the number of AI is below a certain threshold and spawns the next wave automatically. This wouldn't solve the problem entirely, but would retain good pacing while minimising the impact of the AI limitations.

LEARNINGS

It's also important to look back and reflect on process to see what we could have done better! Here are a few thoughts I had both during and after the process which I'd change next time:

As mentioned previously, I'd give more consideration to the themes of each room or area within the level at the paper stage. In particular, I'd come up with a rough idea of what the facility as a whole would look like, and then plot the player's path through it after that.
The checkpoint system turned out to be a very complicated technical element of the level, but I didn't identify this well early on and it left me with a large amount of work in later iterations to effectively retrofit it to the level I'd created. For future SnapMap levels, I'd concentrate more on restrictions - figuring out which systems are likely to be complicated and adding in WIP versions early on.
I'd consider doing a bigger pen and paper version of the level after settling on a layout, perhaps using A3. This would allow me to go into more detail and provide reference materials to anyone else working on the level, while incorporating any very early changes.

FM 2019 TUTORIAL

D&D CAMPAIGN