Designing My First Quake Map

I am not much of a level designer, let alone a Quake mapper, but with the hype around the release of TrenchBroom2 and the incredible maps still being made for the 22-year-old classic, I thought it would be a fun and educational experience to make one of my own.

My main goals were to learn more about the inner workings of Quake, learn about level design with some hand-on experimentation and practice, and to create a fun Quake map.

The resulting map is a bit inconsistent in terms of layout and aesthetics as it involved a lot of learning and experimentation along the way. Really, it’s something of a test map and I made things up as I went along, but I’m happy with it nonetheless.

You can download it here.

Context

In my mind, the most significant benefit of designing maps for a game with a clearly defined gameplay loop is that it allows you to focus on the relationship between the core mechanics and the map layout.

3D shooters are particularly well-suited to this kind of exercise, as their core gameplay is often straight-forward (move, point, shoot), with a heavy emphasis on 3D positioning and sightlines. This puts a lot of control in the hands of the level designer to craft unique play spaces.

That Grenade Launcher is just out of reach.

Old school/arena shooters take this further by putting significant, game-changing resources and mechanics on the map itself. Health, armor, weapons, ammo, power-ups and so on. They can all be distributed throughout the map to dictate what resources players have when.

Few other genres offer such potentially significant variation in player experience from level to level.

A Sense of Scale

One of the first things that required a fair amount of experimentation to get handle on was level scaling. Spaces that seemed natural to me at first tended to feel very cramped in-game.

Quake feels short and wide for a variety of reasons. The player character’s movement speed is high compared to most modern games, but their jump height is low. Various enemy types also have some difficulty navigating narrower spaces.

Wide ramps and tall ceilings.

Really, the only entities that demand much verticality are wizards (the white floating guys) and demons (the ugly monsters who like to leap in your face).

This puts very few real limitations on room height, especially with the ability to employ trigger_monsterjump (which, true to its name, makes monsters jump) to navigate ledges at various elevations.

Level Flow

One thing that is often associated with old school FPS level design is complex, labyrinthine layouts that require the player to scour the area for switches and keys to advance. This is difficult to execute well and can result in a lot of directionless wandering when intended paths aren’t clear.

Silver keycard visible at the start of the map.

So, I decided to make a really linear map that clearly communicates player goals and progress by revisiting the same areas at different levels.

Objectives are foreshadowed early to give the player a good idea of where they will be in a few minutes and once they’ve reached their destination, they often see early areas from a different perspective.

First glimpse of the gold keycard.

Putting routes the player will follow later on higher ground initially out of reach also has the added benefit of cutting down on unavoidable back-tracking, since they can simply drop down on the way back. It’s a one-way shortcut.

Second view of the gold keycard and shortcut on the way back.

Lighting

The lighting system in the original Quake has a lot of character and potential for the dramatic, but taking advantage of that seems to be a delicate balance. It’s easy to make a level too dark to see what’s going on or too bright and washed out. I probably erred on the side of “too dark,” if I’m honest.

Basic lights are spheres with a pretty steep fall-off, and a few properties that allow you to adjust their intensity and radius. You can also define a minimum light level (which doesn’t look great) and a default sunlight level (light produced by any sky brushes) in the world spawn entity.

Wall fixtures cast interesting shadows on the ceiling.

What I found most appealing aesthetically was a combination of high intensity lights casting shadows on interesting brush geometry and dim fill lights with a large radius to subtly brighten excessively dark areas. Often simply creating a physical light fixture and placing a light next to it was enough to cast interesting shadows.

Looking down from above.

Creative Constraints

Probably the biggest  appeal in designing maps for Quake is the unique limitations the game itself provides. I opted not to use any custom mod content in part for this reason.

Custom interactions in vanilla Quake are limited but flexible, relying on a simple trigger system. The core of this functionality is the “target” and “targetname” properties, which can be defined for any entity. Targetname is the name associated with a given entities entity (or entities) in question and the target is the targetname of a different entity which will be triggered.

I wonder if any of these pistons move.

What an entity does when it is triggered varies. Enemies when triggered will attack the player. Lights toggle on and off. A trigger_teleport… Well, it teleports things.

Most interesting to me is the “func_door” entity, which in practice is a brush or collection of brushes that moves 360 degrees horizontally or up and down when triggered. By default, func_doors trigger when approached by a character (player or enemy), but if given a targetname, they must be triggered manually. This makes it very easy to create complex doors with many moving parts as well as plenty other creative applications.

What does this machinery do?

Audio

Quake doesn’t seem to offer much in the way of custom audio behavior, with the primary entities for that purpose being a handful of preset ambient emitters, which can be placed throughout the level and have a static drop-off.

The most persistent ambient sounds, like the wind in outdoor areas and the persistent water agitation sounds play automatically based on your proximity to any open area with sky or water brushes.

Customs doors made of multiple brushes and some lava/slime.

Info_Intermission

Overall, I had a lot of fun and learned about Quake and level design in the process. It’s fascinating to look at the nuances of the original id episodes and the work of experienced map makers in the community.

There is are so many details that go into these maps, some of which I didn’t explore as much as I would like. In particular, the subtle and not-so-subtle ways that Quake maps change based on difficulty level is very cool, but also labor-intensive.

Modernized tools like TrenchBroom make this process more accessible than it has ever been.

Sound Effect Variation in Unity

One of the most fundamental elements of satisfying interactive audio implementation is variation. When you play same sound effect repeatedly, it tends to draw attention to itself through its artificial precision. Natural sounds have all kinds of subtle inconsistencies that we take for granted.

To address this problem, games use multiple pre-recorded variants of most of their sound effects and some additional modifications on playback. In this post, I’m going to walk through implementing basic variations within native Unity audio, assuming you already have a set of sound effects to use.

Setting Up

First, we’ll start with simple round robin, or playing each variation in a predefined, looped order. Next, we’ll randomize the playing order and ensure that the same audio clip doesn’t play back-to-back. Finally, we’ll look at using pitch and volume randomization to add some more subtle differences every time these sounds are played.

Before we do any specific implementation, we need a game object with an Audio Source component attached to it. Create a new one or use an existing object in your game that needs to make some noise.

Round Robin

To play our variations, we need to store them in a container Unity can work with: an array of AudioClips.

public AudioClip[] clipArray;

We also need to define an Audio Source to the play our sound effects.

public AudioSource effectSource;

And an integer variable to keep track of our current array index.

private int clipIndex;

In the inspector, set Effect Source to your AudioSource component, set the Clip Array size based on the number of variations you’re using, and add your AudioClips to the array.

Now, for the playback itself. We’ll create a new method, PlayRoundRobin(). Every time this method is called, it will play the current index of the array then increment the clipIndex value. If the index is beyond the boundaries of the array, it is reset to 0 and the round robin continues.

void PlayRoundRobin() {

    if (clipIndex < clipArray.Length)
    {
        effectSource.PlayOneShot(clipArray[clipIndex]);
        clipIndex++;
    }

    else
    {
        clipIndex = 0;
        effectSource.PlayOneShot(clipArray[clipIndex]);
        clipIndex++;
    }
}

Each time this method is called, it will play the next variation in whatever order you’ve established in the array, starting over when it reaches the end of the array.

Clip Randomization

Next, we’ll write another simple method in the same script to play the clips from the array in a (pseudo) random order.

void PlayRandom()
{
    clipIndex = Random.Range(0, clipArray.Length);
    effectSource.PlayOneShot(clipArray[clipIndex]);
}

This will generate a random number between 0 and the last index of the array, then play the audio clip stored at that index.

Avoiding Repetition

While this barebones randomization is serviceable, it still has a clear limitation: there is nothing preventing it from generating the same random index multiple times in a row, exactly the kind of thing we’re trying to avoid with randomization.

Fortunately, the solution to this problem is pretty simple.

We’ll compare each new random number to the last index used. If they are equal, we’ll generate a new one. To do this, we’ll create a new method, RepeatCheck(), that takes the last used index and the random range (for our purposes, this is the array length).

int RepeatCheck(int previousIndex, int range)
{
    int index = Random.Range(0, range);

    while (index == previousIndex)
    {
        index = Random.Range(0, range);
    }
    return index;
}

This will continue to generate random numbers within the given range until it generates a value that is not equal to our previous index. It then returns that value. So, now we can plug this into our PlayRandom() method.

void PlayRandom2()
{
    clipIndex = RepeatCheck(clipIndex, clipArray.Length);
    effectSource.PlayOneShot(clipArray[clipIndex]);
}

When this method is called, it will never play the same random variation back-to-back.

Pitch and Volume Randomization

Now, the last thing we’re going to do is randomize the pitch and volume of our Audio Source each time we play our sound effects. We’ll need a few more variables, so we can fine tune this effect easily in Unity.

public float pitchMin, pitchMax, volumeMin, volumeMax;

Set these values in the Inspector according to preference. This may vary depending on the specific sound effect, but in general very small ranges will sound more natural. Larger ranges sound jarring and unnatural (though that could be a useful effect in some cases). Set these values to 1 for no effect at all.

Add these two new lines to the beginning of the PlayRandom() and PlayRoundRobin() methods:

effectSource.pitch = Random.Range(pitchMin, pitchMax);
effectSource.volume = Random.Range(volumeMin, volumeMax);

Each variation will now playback at a random pitch and volume according to the ranges you set and can easily adjust in the Unity editor.

Testing it Out

If you want to make sure this is working, without assets or systems to go with it, you can just drop a game object with an Audio Source and the script attached into an empty scene. Add something like this to your Update() method.

void Update ()
{
    if (Input.GetButtonUp("Fire1")) PlayRoundRobin();
    if (Input.GetButtonUp("Fire2")) PlayRandom2();
}

Now you can trigger each method with the Fire1 and Fire2 bindings respectively, which are Mouse 0/Left Ctrl and Mouse 1/Left Alt by default.

Looping Music in Unity

Unity’s default audio capabilities have never been a particular strong point. Some much needed functionality has been added over its lifespan, like audio mixers, sends, and insert effects, but it’s still extremely limited compared to the feature sets found in widely used audio middleware and even other game engines.

In this post, I’m going to talk about 3 different potential approaches of gradually increasing complexity for looping music with native Unity audio.  Hopefully, there will be something useful here for a variety of experience levels.

First we’ll cover use Unity’s default loop functionality. Second, we’ll use a bit of audio editing and AudioClip PlayScheduled() to create a seamless loop. Lastly, we’ll calculate a loop point given the beats per minute (BPM), beats per measure (Time Signature), and the total number of measures in the track and create a simple custom looping system, again using PlayScheduled().

Before starting, it should be noted the mp3 format is ill-suited for this application for technical reasons beyond the scope of this post and should be avoided. Ogg and Wav are good options that handle seamless looping well in Unity.

1. Default Loop

This is the simplest option, requiring no scripting at all, but it’s also the most limited. For music that with no reverb or tail to speak of or music that doesn’t need to restart exactly on measure, this can be serviceable. A quick fade at the end of the last bar can work for less ideal music tracks, but it will result in an obvious and unnatural loop point.

Create a new object in your scene, or use one that already exists. Whatever is appropriate.

Add an AudioSource component to it and set the AudioClip to your music file, either from the menu to the right of the field or by dragging and dropping it from the project browser.

Make sure that “Play On Awake” and “Loop” are enabled. Your music will play when you start the scene and loop at the end of the audio file.

2. Manual Tail/Release Overlap

This method requires some work outside of Unity with an audio editor or Digital Audio Workstation (DAW). Here we’ll still use Unity’s default looping functionality, after playing and introductory variation of the looped track.

Before doing anything in Unity you need two separate versions of the music track in question, one with the tail cut at the exact end time of the last bar/measure, and another with that tail transposed to the beginning of the track, so that it overlaps with the start.

Ensure that the start and end of these tracks are at a zero crossing, to avoid any discontinuities (audible pops) during playback. This can be accomplished with extremely short fades at the start and end points. This second track will transition seamlessly from the introductory track and loop seamlessly as well.

Add an AudioSource to an object as in the previous section and set the second edit of the track (with the tail overlapped with the start) as the default AudioClip. “Play on Start” should NOT be enabled.

This is where a bit of scripting is required. Create a C# script and add it to the same game object as your AudioSource.

AddScriptMusicLoop

Open it in your IDE of choice. This will only require a few lines of code. First, declare two public variables: an AudioSource and an AudioClip

public AudioSource musicSource;
public AudioClip musicStart;

Save this and switch back to the Unity editor. There will be two new fields for the C# Script component in the Inspector: “Music Source” and “Music Start.”

Click and drag the AudioSource you added to your game object earlier into the “Music Source” field on your script. Do the same with “Music Start,” using the intro edit of the clip (without a tail at the start or end).

This is where the code that makes noise comes in.

void Start () 
{
    musicSource.PlayOneShot(musicStart);
    musicSource.PlayScheduled(AudioSettings.dspTime + musicStart.length);
}

When the scene Starts, the first clip will play once and the second clip will be scheduled to play as soon as the first has ended. This start time is determined simply by adding the length in seconds of the first clip to dspTime (the current time of the audio system in seconds, based on the actual number of samples the audio system processes).

From that point, the track will loop normally with Unity’s default loop functionality.

3. Calculating the Loop Point and Looping Manually

The last approach requires more scripting work, and some extra information about the music itself, but does not require any specific editing of the audio file. We’ll be creating a simple custom looping solution using two AudioSources and AudioSource.PlayScheduled() that calculates the end of the last bar or measure based on some data entered in the Inspector and uses that to determine the loop interval.

Add two AudioSources to your game object and set the default AudioClip for both to the music track you’re going to loop. This will allow each repeat to overlap with the tail of the previous one as it plays out.

Add a new script to your game object and open it on your IDE. First, we need some public variables that we can set in the inspector: an array of AudioSources and three integer values which correlate to simple properties of the music composition itself.

public AudioSource[] musicSources;
public int musicBPM, timeSignature, barsLength;

In the inspector, set the Size of the Music Sources array to 2 and drag the two AudioSources you’ve created to the Element 0 and Element 1 fields.

Then enter a few music properties. Music BPM is the tempo of the music track in Beats Per Minute (BPM). Time Signature is the number of beats per bar/measure. and Bars Length is the number of bars/measures in the track. You need to know these values for this calculation to work.

Next, we need some private variables for some values we will be calculating in the script itself.

private float loopPointMinutes, loopPointSeconds;
private double time;
private int nextSource;

The loopPoint values will be used to store the loop interval once it has been calculated. Time will be the value of dspTime at the start of the scene and be incremented by loopPointSeconds for each PlayScheduled() time. And nextSource will be used to keep track of which AudioSource needs to be be scheduled next.

Now, in the Start() method we need the script to calculate the loop interval, play the first AudioSource, and initialize the time and nextSource values.

void Start () 
{
    loopPointMinutes = (barsLength * timeSignature) / musicBPM;

    loopPointSeconds = loopPointMinutes * 60;

    time = AudioSettings.dspTime;

    musicSources[0].Play();
    nextSource = 1;
}

The custom loop functionality itself is defined in the Update() method, which is called every frame.

void Update () 
{
    if (!musicSources[nextSource].isPlaying)
    {
        time = time + loopPointSeconds;

        musicSources[nextSource].PlayScheduled(time);

        nextSource = 1 - nextSource; //Switch to other AudioSource
    }
}

First, we check if the nextSource is still playing. Then, if it is NOT:

  1. Increment the time by the loop interval (loopPointSeconds).
  2. Schedule the nextSource AudioSource to play at that time.
  3. Toggle the value of nextSource (from 1 to 0 or from 0 to 1), so the script will check and schedule the other audio source.

And that’s it. The music track should begin playing at the start of the scene and continue to repeat at the loop point until the object is destroyed.

Rhetorical Sound Design

Hearing is weird. It’s abstract in a way that sight isn’t. A picture can clearly communicate a sense of size and space. A series of pictures can communicate speed and distance. Sound is only movement. Almost any movement. It’s the vibrations people and things make when they pass through the air and come into contact with each other.

Hearing is also different from sight in part because we have less control over what we hear. We don’t open and close our ears, though we can try to block them. We don’t really focus our ears in the way that we do our eyes. We’re always hearing (as long as we are able to), and so we often become so used to sound that we don’t actively notice it unless we make the effort. We learn to tune a lot of sounds out, but instinctually notice when they are absent.

I think this is why sound design often goes unnoticed unless it is so incongruent that it breaks the audience’s immersion. Effective sound design sells the argument that what they are seeing with their eyes is real. It reinforces all of the concrete information about size, space, and action that they see on a screen. It is simply expected to be there and to sound “right.”

For that reason, it can be useful to have certain heuristics to apply to this problem; the problem of making things sound “right.” I’m loosely adapting Aristotle’s main rhetorical appeals—logos, ethos, and pathos—as a framework for thinking about effective sound design, with a particular focus on game audio. There is overlap between these appeals, because they are all fundamentally related (emotion and logic are never truly separate) and because each sound effect is essentially its own argument that should ideally succeed on multiple levels.

Pathos: The Emotional Appeal

An important function of any synchronized or reactive audio is to reinforce the emotional experience of the scene. This is where the role and function of sound design overlaps most with that of the musical score. Does an impact feel big? Does the gun the player is firing feel powerful? Does the giant monster they’re fighting feel enormous and deadly? Does that abandoned mansion feel haunted? This is the visceral, “game feel” component of game sound effects.

This has important implications for game design. Emotionally satisfying audio cues influence player behavior in a variety of ways.

  • A feeling of constant or impending danger can make players play slower and more cautiously.
  • A powerful-sounding weapon can inspire confidence and encourage players to be more aggressively.
  • A weak-sounding weapon might be used less often, regardless of its practical functionality.

Zander Hulme told a relevant story along these lines at a panel at PAX Aus 2016 about multiplayer weapon sound effects in a Wolfenstein game.

The players with the weaker-sounding weapon believed they were at a disadvantage and performed worse, despite both teams having functionally identical weapons. Replacing the weaker sound effects with something more satisfying fixed the perceived weapon imbalance. Game audio doesn’t simply play a passive support role in game design.

Logos: The Logical Appeal

Another important function in game audio in particular is the ability to communicate factual information to the audience. What exactly is making the sound? What direction is the sound coming from? From how far away? In what kind of space? Is the audience in that space or a different space? Can your audience discern all of these things or are they intended to? Lack of clarity and focus should be an intentional choice, not the result of carelessness or oversight.

Much like the emotional appeal, this too is a practical game design consideration. Audio information provided to the player can directly influence their decision-making and behavior in the game space, in a wide variety of contexts.

  • The recognizable sound of an enemy charging a powerful attack helps the player discern when to evade.
  • The distinct sound of a sniper rifle being fired makes them reconsider peeking around a corner.
  • The suddenly loud crack of their foot-steps on a tile floor tells them that sneaking will be difficult and may require them to slow down.
  • The clarity, volume, and propagation of sounds in competitive multiplayer games can significantly impact what kind of information players have about strategies of their opponents, even without line of sight.

In Counter-Strike, for example, players have to be mindful of moving at full speed, because running foot steps and jump landings can give away valuable information to their opponents with hearing and inform counter strategies. At the same time, being aware of this fact allows players to intentionally make noise to create misinformation.

Below is a clip of a CS:GO streamer, DaZeD, faking a drop by jumping on the ledge above. The opposing players throw a flash grenade and attempt to retake the room, expecting him to be below and blinded, but they don’t predict his superior positioning and lose the fight.

This only works because both teams are aware of the landing sounds and because these sounds are audible from positions outside of the room.

A subsequent update added unique landing sounds per surface, which complicates this scenario. In this clip, he actually jumps on a wood surface at the end of the upper tunnel. Now, an observant player could note that this surface sound effect is not what would they would hear when opposing players drop on the stone floor below. If he instead faked further to the left, the sounds would match as they did on older versions of the game.

Sound effects can provide extremely valuable information to players beyond the limitations of line of sight. It’s important to keep this in mind, even for members of the development team who don’t deal directly with audio. If footstep propagation distance determines when and where players can afford to move at full speed, this can influence how major routes through the map are designed. If this isn’t accounted for, it can have unintended consequences on player behavior and map flow. This applies in many other seemingly non-audio design contexts as well.

Ethos: The Appeal to Character

In the context of sound design, it’s useful to think of ethos as authenticity. Does the audience accept that this sound belongs in the space? Does it fit the art direction of the game? What stylistic considerations must be made to ensure that is the case? If the game is heavily stylized, there is plenty of room for stylized sound effects. If the game strives for pseudo-realism and photo-realistic graphics, it is probably appropriate to keep the sound effects relatively grounded. Often, however, what the audience expects is very different from  reality. Authenticity is what it seems like something should sound like, rather than necessarily what it actually does.

Practically, this has a large degree of overlap with Pathos, the emotional appeal, in that the most emotionally resonant sounds should also be authentic, but they are distinct. An ambience could be suitably unsettling, but not feel authentic in the wrong space. Creaking wood and howling wind might suit a creepy, old house, but be very much out of place in an abandoned space station, even though both evoke a lonely, isolated atmosphere. An impact could be distinct and punchy, but not fit the style of the game or the source object or actor.

Conclusion

A very common example of all of these elements in action is in effective gun shot sound effects, particularly for real world weapons. Fire arm field recordings on their own are rarely very interesting or particularly distinct. This is in part because of the difficulty in capturing the character and impact of sounds at extreme volume levels. Raw field recordings of fire arms tend to sound similar. To account for this, sound designers need create hyper-realistic gun shot sounds with a variety of explosive, mechanical, and environmental layers and processing in order to create the explosive, powerful sounds that audiences expect. This is both more authentic than a simple gun shot field recording, and more emotionally impactful. A core goal of satisfying weapon sounds is to recreate the visceral, explosive impact of firing them.

Given that, in situations where a large variety of weapons are called for, the sound designer will need to differentiate each of these weapons. This is especially true of games with a large selection of realistic weapons. It is important to both establish unique character for each and communicate that distinction to the player, who should ideally be able to tell what weapon is being fired at them from the sound. A sniper rifle might have an exaggerated, long reverb tell to really sell its firepower. Pistols and submachine guns might emphasize the mechanical elements over the explosive punch and the reverb tail to make it feel smaller. An assault rifle might lie somewhere in between.

Establishing these rhetorical choices and applying them consistently provides emotional satisfaction, authenticity, and clarity to the player.

Portfolios Require Planning

After quite some time struggling to put together materials from a bunch of different projects (most of which is either gone or broken, apparently), dating as far back as the spring of 2013, I’ve finally just gone ahead and finished a new project of my own that actually shows that I can do something: a Wwise implementation demonstration in Unity. Of particular note to me is the RTCP implementation for the player jet sounds, which modulates the volume and pitch of two separate layers based on the magnitude of the player ship’s movement vector (basically translates to speed).

I also took the opportunity to whip up a nifty animated logo with some punchy sound design to go with it. It’s pretty simple, but I’m not an experienced animator—by which I mean I have no experience whatsoever— so I had to start from scratch with what I had. I like it a lot.

Combustion Prototype Music

I recently got an opportunity to move a bit out of my comfort zone. It’s always a good exercise to explore different styles and aesthetics for sound and music. In this case, I tried to match the PSX-style, low poly, dieselpunk aesthetic of this project. I ended up playing around with the sounds and effects of the Korg M1 in an attempt to get a period (90s) appropriate, sampled instrument sound.

Misspelled my name in the video, though. 😉

Etrian Odyssey (How Atlus Got Me Into JRPGs)

The Nintendo DS was a system with a lot a great games. More importantly, and more relevant to this post, it had a lot of great RPGs. From remakes to ports to brand new games, it’s an understatement to say that the DS has an impressive library of fantastic niche titles (and no shortage of trash either). Nonetheless, for me, Etrian Odyssey was the first quintessentially “DS RPG.” It was the first RPG that felt like it could have been nowhere else. The main reason for this is the mapping system, which while perhaps outwardly gimmicky solidified the old-school pencil and graph-paper experience so often associated with the PC RPGs of yore, in a manner notably more tactile than the old school SMT/Persona experience. I mean Wizardry and the first person dungeon crawlers that followed it, the game that most obviously influenced the birth of the Japanese RPG along with Ultima.

But it was more than that. The mapping system wasn’t just some fleeting mechanical flourish incorporated to make the touch screen suddenly useful or a clever reference to the shared experience of certain older gamers that remember, perhaps fondly, the “good ol’ days” of PC RPGs. Ok. Sure. It may have been those things, but it was also your most important tool in a harsh and relentless labyrinth. It was how you kept track of the many dangers between you and the beautiful, but deadly depths of the twisting labyrinth and its many strata. It was how you remembered where that pool of healing water was to keep your party in fighting shape. It appealed to that irrational annoyance I have with auto-mapping systems that leave empty grid spaces, because I didn’t need to walk into that particular corner. It was the first ever present reminder that the dungeon space is always there. It was that small bit of control, that small way in which the player could touch the world that truly sparked the imagination, as they sketched the outline of a world on their virtual graph paper.

And imagination is a big part of the Etrian Odyssey experience, because you won’t find any cut scenes here. You won’t find paragraphs of exposition, exaggerated character archetypes vying for your attention and trying their best to make you believe they have depth and some meaningful emotional conflict that you should definitely care about. There is no overarching plot by some ridiculous villain to destroy the world so he can actually save it. There is no melodrama. The sole town and the NPCs in it are static hand-drawn images, with a simple interactive menu overlay. You get requests. You get missions. You complete them. And along the way, many small events add up to a memorable experience. Something hidden in a bush, a fruit plucked from a tree, a spring filled with healing water. A wild animal. It might be friendly; it might just eat your face.

There is so much that the game shows you and very little it feels obligated to outright tell you. For me, that made the story very personal, because I was the one who pieced all of those small moments together into a story. Each member of your guild is someone you gave a name, a face, and a job. Maybe you came up with a back-story for them from the beginning. Maybe one developed as you played the game. Maybe you named them after your real life friends. Maybe they remained a mystery, but they are YOUR characters. They represent YOUR agency in this mysterious place.

It’s the synergy between these characters and their skills that will keep them alive as you venture deeper (something that has been expanded and re-balanced as their series continues). Because of this, the bond between your guild members has a very practical foundation. The integrity of your five person team is essential to surviving the tougher parts of the game to a greater degree than most RPGs, regardless of your combination of character types. The loss of any of them, even with Revive spell or a nectar handy is a serious blow to the party’s fighting strength and something that can mean the swift end of a harder fight (and sometimes seemingly easier ones). For me, that simply served to further reinforce the importance of these characters to my experience as the game continued. Even though they never anything more than a series of portraits within a nest of menus, they feel like a close nit group of comrades, bonded by the dungeoneering experience they all share.

True to its roots, Etrian Odyssey is structured around repeated trips back to the labyrinth and slow, measured progress deeper and deeper into its twisted depths. It’s an unforgiving experience, entirely unafraid to decimate your party with a simple random encounter. Your support classes hide in the back row. Status effects are a VERY serious danger that you have to prepare for. You send your party in, explore until your resources run low (HP being one of the big ones) or your bag becomes stuffed to the bursting point with plant and animal parts, and then you return to the town.

You probably drop by Shilleka’s to offload your loot, the plant and animal parts you’ve harvested, restock on healing items and whatever new equipment can be hacked together from the latest hide you found, and you head to the Inn lick to your wounds (and save, of course). Maybe you’ll drop by the Golden Deer Pub that evening to relax, check with Valerie for any more jobs, and talk to some fellow adventurers, ex-adventures, and whoever else is carving out a life in the bustling town of Etria. These interactions aren’t in-depth, but they add just the right amount of detail to the place. The town theme quickly becomes a sound both familiar and safe, as it accents the peaceful beauty of that small settlement.

The next morning, you head back in, hoping you can make it further down this time and that those Venomflies you ran into on the second floor don’t decimate your party with their surprisingly potent poison. You fight your way through the various animals inhabiting the area, including some oddly dangerous rabbits that don’t seem to like you very much. There is a certain comfort in this routine and the satisfaction of making it just a little bit further into its depths, as punctuated by the new areas that you’ve mapped out yourself, is immense…

Then you meet your first FOE (Formido Oppugnatura Exsequens). Well, to be fair, this happens pretty much immediately on the second floor. I delayed it in this narrative for the sake of the dramatic twist. That’s just quality storytelling. You don’t have to tell me. I know you’re shocked and surprised.

FOE’s are basically bad-ass mini bosses that wander around the same space your party does. If you run into one, they will attack you and in all likelihood brutalize your woefully unprepared group of adventurers. The necessity of awareness and avoidance, which only becomes more complex deeper in, takes the tension of exploration up notch in a manner somewhat less psychologically distressing than a reflex-based game like Demon’s Souls or perhaps more appropriately, its first person predecessor: the King’s Field games. Things get more interesting a bit later, when you meet aggressive FOEs that will give chase if they spot you. It’s important that you always watch your map, because turns that pass in battle pass in the dungeon as well. If you get into a fight and you’re in the path of a FOE, they WILL join the battle and make your life a hell of a lot more difficult.

The major bosses are an extension of this, from Fenrir and its pack of wolf minions with no sense of fairness, to a dragon spewing its fiery breath around an entire dungeon floor. The sense of place, that they are moving through and interacting with the same area as your band of 5 intrepid adventurers, gives these towering beasts a presence they often lack in other similar experiences, despite the decidedly retro presentation. They loom over the battlefield even before the 3DS titles that put them in their fully rendered glory in the dungeon view. I can’t think of a more threatening videogame abstraction than that glowing orange ball, plodding towards you with every step you take, threatening to corner you if you make the wrong move. You can practically feel the ground rumble with every movement.

And, honestly, that’s pretty much the EO experience, without spoiling much. Things get hairier further down, with more environmental hazards and meaner monsters. The locale changes every 5 floors along with the excellent backing track, courtesy of Yuzo Koshiro. There might be a couple of unexpected narrative twists down the line. All told, it’s a pretty pure dungeon-crawling experience, but Etrian Odyssey never lets you forget that you are always in the dungeon. You aren’t in a mystical, abstract random encounter dimension and battles feel unusually immediate because of this, despite their turn-based foundations. The inter-play between the “real world” of the labyrinth and the pseudo-cyberspace of combat is a central theme. You are in Yggdrasil and it’s never truly safe until you’re out of it… But I always want to come back, because it’s such a curious place with so much to see and it doesn’t take hours of melodrama or a plethora of convoluted and ultimately irrelevant lore to make it engaging. That’s the magic of Etrian Odyssey and it’s why I love the series as a whole, but the first one is a special experience for me (the 3DS remake is great too).

Greetings

I’ve created this site in anticipation of the completion of several major projects in the next few months. As such, my portfolio is rather barren and this site is clearly a work in progress. It should progress very quickly.