At GDC this year, I presented a talk on applying playgrounds to multiplayer level design. Because this was a short talk, I focused on the application to level geometry and the consequences on multiplayer systems.

If you’ve followed my blog for the last few years, you’ll know my interest in playgrounds is not new. They are a metaphor I’ve used several times as an example of how digital games should adapt to their to players’ needs. What follows is my framework for these ideas in multiplayer level design. There are still many areas to explore in this space, some of which I outline along the way, but I hope this introduction to the playground metaphor helps you in your own explorations.

The Basics
Playgrounds are persistent community spaces for non-prescriptive play.

A playground is not an obstacle course to complete, a puzzle to solve, or a story to hear. There are aspects of obstacle courses and stories, but they are not consumed through player interaction; they persist. A good playground facilitates many obstacle courses, many stories, and many forms of play.

Playgrounds are places to be, not levels to beat.

Playgrounds are Multiplayer
Playgrounds are fundamentally multiplayer spaces. They support a wide range of player needs, and they scale along game mode, player count, and player trust.

Raph Koster and a team with google explored the idea of a Trust Spectrum in games. The idea is that different multiplayer activities call for different amounts of trust, which can create barriers for an audience. If a game supports basic parallel play alongside intense, cooperative raids, there is not a path for new players to build the trust they need for the harder activities.

Playgrounds also support a trust spectrum with a range of play, from solo and parallel activities up to group competitive and cooperative play. As multiplayer spaces, playgrounds also follow some design patterns for building friendship. The activities encourage proximity and reciprocity between players.

Here, for example, are several activities as part of a playground. Players can enjoy some activities alone, or in parallel. Other activities require multiple players, some with turn-taking, others with players working together, which means reciprocal loops that build trust. These activities also don’t lock players in for long; a player can stop in the middle of an activity, or at the end of turn to opt out of play.

When I describe playgrounds as community spaces, I also mean more than the play structures. The community space includes the surrounding park, the walking paths, and benches. Playgrounds include spaces for parents to sit and talk while their children play. This is an area I want to explore further in video games, but what could serve the function of a park bench in our multiplayer game systems?

Playgrounds, Not Sandboxes
There is some overlap between playgrounds and sandboxes worth clarifying. For me, a sandbox is a neutral space where players bring toys. In contrast, a playground is the toy. Sandboxes are also used up through the act of play; often a player will need to start a new game for the sandbox to reset. The main overlap between these terms is that both allow non-prescriptive play. That is, sandbox and playground design both let the players do what they want instead of forcing one way to play.

Sandboxes best support solo and parallel play, but not rich cooperative or competitive experiences. This may be a consequence of genre convention more than a necessity. When I say that sandboxes are neutral spaces where players bring toys, I mean the individual player’s upgrade trees, loadouts, and equipment. Because these are not shared, or passed between players in turns, the game systems encourage each player to specialize in a way that may conflict with deeper cooperative play.

For example, in Saints Row IV there are a finite number of activities and collectibles in the world, and the act of play depletes this world of its potential. While exploring the world cooperatively, there are few activities that require both players. As we level up, we can each choose to spend our skill points differently. If I focus on enhancing my character’s movement abilities, while you focus on combat, then the systems are pushing us away from cooperation. You won’t be able to catch up with me while I scale the buildings, and I won’t be able to fight alongside you when you attack harder enemies. Again, the emphasis of the sandbox design is on the toys—skill upgrades in this case—that each of us collect and bring to the neutral space, instead of the space being a persistent toy for both of us to share.

My focus with this post is on level geometry, but the way we shape our levels affects multiplayer systems. If we play Deathmatch on a King of the Hill map, the game may still play like King of the Hill. This is because level geometry and game systems work together to create the play experience.

The Formula
Now let’s dig into some examples:

Here is a basic playground from my neighborhood. If you live in North America, you are probably familiar with playgrounds like this. As playgrounds go, this one is simple and unremarkable. Importantly, we can’t convert this structure directly to our video game levels, and we wouldn’t want to, but there are lesson we can take from its design.

The basic unit of a playground is a module, a self contained chunk.

At the center of the module is a platform elevated off the ground. This playground is for young kids, so remember this platform is a meaningful vantage point for a five year old. This means it functions as a goal for that player to attain.

In order to reach the platform (the goal) the player must pass a skill check. Here that skill check is a staircase. Importantly, a good skill check is not a binary pass or fail. The player can fail and trip on the stairs, but most use falls into a range of skill: for the three year old, slow; for the five year old, OK; for the ten year old, maybe two steps at a time?

Remember the multiplayer context for these skill checks. If I can take the stairs two at a time in a game of tag, and another player can’t, then there is a tactic I can exploit around the playground.

On reaching the platform, there are routes back down that function as rewards. Here they take the form of slides, which are also opportunities for subversive play for the skilled player who will risk running up the slide. Subversive play is whenever the player thinks they are using a constraint of the design against its intent.  We can design with some subversion in mind, but the flexible form of playgrounds should allow for more subversive play than we can predict.

Against the bars at the back of the platform, there is a steering wheel. This functions as a setpiece, which landmarks and differentiates modules from each other. In playgrounds, a good setpiece can also spark imagination and encourage roleplaying. (For now, the aesthetic and thematic solutions to the playground formula is a problem to save for another time.)

Now that we have a formula, we can create more complex forms. This playground is more interesting than the first example because it connects multiple modules into a complex structure.

Here we have a hierarchy, or tree. This makes a fun playground, but there is still a problem in the lack of cycles or loops. If we played tag on this structure, the only ways to go from one end to the other are by backtracking or by running on the ground. But with our abstract language of modules, we can imagine variants that do connect as cycles. With these formulas, we can now imagine infinite, sprawling playgrounds if we want!

But our imaginary playgrounds do hit a constraint of safety. Real playgrounds are safe environments for failure, where the design limits risk. Playgrounds also limit the time to recover from a failure. If I lose my grip while crossing the monkey bars, I lose a few seconds of progress before I can try again. In games, if the player fails a skill check and cannot recover in a short amount of time, then the level lacks the safety of a playground. If the player reloads a save state, we’ve designed something where recovery is too difficult. This may limit how big a playground can be and what systems we can use.

Applying the Formula to Level Design
For most of my experiments with playground level design, I’ve used Quake. The most direct application of playgrounds requires a robust set of skills, which Quake has. A staircase in Quake is not a meaningful skill check, but once we add a monster at the top, there is some skill involved.

Another benefit of testing these ideas in Quake is that all levels support singleplayer, co-op, and competitive play. Once we adapt the level geometry, we’re close to my definition of playgrounds.

There are also many ways to create timing-based skill checks around moving obstacles, traps, and dynamic cover. For a game two decades old, there is a lot we can do!

Quake also has advanced movement skills:

 

 

 

 

 

Bunny hopping lets players maintain their momentum, and circle jumping (curving their aim while strafing in air) lets players accelerate and curve around obstacles.

 

 

 

 

 

Jumping at the peak of a ramp gives players more height than normal. Jumping a little too early or a little too late will still give some bonus to the jump height, which makes ramp jumps one of the easier movement skills to use.

 

 

 

 

 

Rocket jumping grants even more height, but it comes at the cost of some health. We also usually reserve the rocket launcher as a rare reward item.

These advanced skills create opportunities to move through the level quickly and take shortcuts, but if we made them necessary skill checks, the level would be inaccessible for most of our players. That is, these advanced skills should be fast routes and opportunities for subversive play, not the only routes.

Putting it all Together

Putting these ideas together, we get a basic playground. This level plays in a different way than a standard Quake level, and I want my players to recognize this the moment they enter the map so they won’t rely on existing habits.

If we break the structure into its modules and their connecting skill checks, this should look familiar. With different skills involved, this same formula could describe a real playground.

Pushing these ideas further, adding more skill checks and rewards in the form of enemies and items, we get a pretty cool structure! Importantly, while there are objectives for the players to complete, there are many ways to approach them, many ways to add new goals, and many ways to play.

Speedrunning is one example of players creating a new goal on top of the intended design. In the video below, one of my playtesters routed a speedrun. Normally a first playthrough of the map takes 10 minutes, but here it takes 27 seconds. This speedrun also demonstrates the range of subversive play possible within this design.

 

 

 

(If you aren’t familiar with Quake, the speedrun starts by grabbing a secret Ring of Shadows, which makes the player invisible for 30 seconds. Normally, this is enough time to get an edge on combat or explore in safety, but not enough time to complete the level. Importantly, if the goal of speedrunning is set by players outside the game, then they can decide if they want to use the item. Speedrunners create their own categories and rules.)

For comparison, and a more thorough exploration of the level, here is my playthrough:

 

Other Applications for Playgrounds?
At this point you may be thinking “but Andrew, I’m not making that kind of game! How does this help me?” And probably what I’ve described is very different from what you’re making. But if you work with 3D level design and you follow the needs of camera, character, and controls, then playgrounds are still useful.

If you’re involved in prototyping or pre-production, you need metrics test maps. Normally, a metrics test map is the 3D equivalent of a meter stick to know how high, how far, how fast, and so on. But these maps can’t tell you whether your metrics are fun. So instead, metrics playgrounds!

Here’s an example of a metric playground I built to find the fundamentals of a game early in production. We had a tight third-person camera and a robust move set with double-jumping, mantling, sprinting, and crouching. In a standard metrics test map, there is no way of knowing if your character moves too fast or jumps too high. Aside from verifying your code works, distances only matter in the context of play. The purpose of my metrics playground was to provide that context.

As we continued building the game, we kept the metric playground up to date with our mechanics. We had gunplay, so there were ways to spawn enemies to shoot and others to evade. In this way, the metric playground let us test the whole game in one spot and quickly tune for fun.

Would our final levels look or play anything like these playgrounds? Probably not, and that’s OK! The purpose of the metrics playground was to find our fundamentals.

Conclusion
I am not suggesting playgrounds are a magic solution to all of our problems. Rather, playgrounds are another area of design we can study and—when appropriate to our goals—apply.

To me, playgrounds are an exciting metaphor for level design because of how they facilitate a breadth of play that we, in video games, seldom allow. They are level geometry doing the work of system design, and they show a way forward for levels that adapt to their players’ needs.

Thanks for reading,
-Andrew

 

Several years ago my work tasked me to build a cooperative dungeon themed around a volcanic palace. We wanted the dungeon’s difficulty to rise across a series of rooms and end with a fight against the Fire King. At the half-way point through the level, we wanted to challenge the players with a combat-puzzle encounter.

For my prototype of this encounter, I locked the players in a room with several waves of combat and environmental hazards. Each wave, the players needed to complete an increasing number of objectives in order to survive lava that would rise through the floor.

Outside the specifics of the theme, I designed this encounter to test player coordination across multiple objectives under pressure. The encounter also served as a gear check through the enemies. In the abstract, this encounter is typical of raid design, which was our goal. The problem was the theme and converting my prototype to final art without losing clarity.

In one of several meetings dedicated to solving this problem, another designer asked why the Fire King would have this hazardous room in his palace at all. This led to question about who (within the game’s fiction) built this room, why they built it this way, and what happened since it was built.

When a level is able to answer these questions, it passes a test I think of as “architectural realism”. If a level does not hold up to this scrutiny, and we’re left saying “no one (within the game’s fiction) would have build this place or built it this way”, it fails the test of architectural realism.

This concept overlaps with environmental storytelling, world-building, and immersion, all of which are important for high-fidelity AAA narratives games like Last of Us and God of War (2018). As an industry, we place a lot of value on these concepts.

But my level was not for that kind of game. We used a distant 3rd-person camera, larger-than-life characters with exaggerated proportions, and abilities that worked at massive scales. We built our levels and the environment art to match.

So, when one of these design meetings entered a third hour of argument to solve the problem of architectural realism, I was ready to ship the level as it was, in Mario-like abstraction where primitive meshes clearly conveyed their function. Immersion be damned.

Architectural realism had no place in the problem we were trying to solve, and the efforts to pass its criteria wasted development time and made the encounter’s mechanics opaque. A bad application of best practices made my level worse.

Now, when I see the ideas of architectural realism described as best practice, I remember how it can harm the development process when it does not serve the intended experience.

Here for example, Mark is correct when referring to most real-world architecture, but most real-world architecture ports badly to video games. This is obvious for those of us who learned level design through modding; our rite-of-passage was to build a replica of our house—or school, or office—in Counter-Strike, Doom (1993), or one of so many other games with mod tools. This was a rite-of-passage because it was a painful realization that we can’t just copy what works in the real-world because the context is different. Even within the same genre, the context of Quake 3: Arena was different from Unreal Tournament 2004. An excellent level in one game will be different, often terrible, in another.

The act of design is to recognize a context, its local needs and constraints, and find a solution that fits best. The practice of greyboxing is a way to prototype a solution, evaluate how well it fits the context, and—in professional game development—communicate the solution to the team. The study of level design is too often concerned with the skills of building and not the skills of design, which persist across genre convention.

Christopher Alexander wrote about design this way in his 1964 essay “Notes on the Synthesis of Form”, where he created a visual metaphor of constraints and relationships. The dots each denote a constraint, and the lines denote relationships. The + and – along each line indicates whether the constraints support or conflict with each other. This visual metaphor is powerful because it lets us step aside from convention and any dogma around best practices to instead face the specific needs of the problem.

In real-world manufacturing, material and production—what Alexander labels “economy”—are real constraints. Even in our digital world of level design, material and production are constraints we need to consider. We have our level construction processes, our art asset pipelines, and our production methodologies. We also have our studio cultures and divisions of responsibilities. All of these factor into the local context within which we solve our design problems.

For my lava palace encounter, the values of architectural realism diminished once we recognized the whole context of our production process. Solving the encounter for world-building and immersion conflicted with too many other constraints.

//

Around the assumed best practices of AAA development, there are assumption of roles and responsibilities. In some studios, level designers are also layout artists, world builders, environment artists, content designer, scripters, and quest designers. Each game and studio has its own needs.

(Jeff also clarified in a later tweet that his advice “can be true or false depending on the situation”)

On another project as a professional level design, I spent several months sculpting and painting terrain. I placed foliage and props. Again, I did this work as a level designer. For the experience we intended to provide, we needed rolling hills and grass, and someone had to implement that solution to the design problem. This is level building, but we still call the job level design.

As another example, look at Dear Esther. Where does the level design end and the environment art begin? This division is artificial until we separate design from building. To provide the right experience, the design of Dear Esther called for an island with terrain and foliage; it doesn’t matter whether it was a level designer or an environment artist who did the work of building.

All of that said, when I see talk of “best practices” that don’t specify their context, I get grumpy. And when these “best practices” are directed at students, I get angry. I think about the days of my life wasted solving the wrong problems, and I think about all of the work I shipped that was less than it could have been.

//

What remains if we throw out “best practices” and say the quality of a design depends on its context?

There are fundamentals we can still apply. Gestalt psychology has value. There are also psychological models like Self-Determination Theory to help us better recognize our players’ needs. I personally am skeptical of any application of shape- or color-theory that says “[x] will make the player feel [y]”, but there is still value in studying these areas as well.

What remains is local level design, where our work serves a specific context to the best of its ability. To me, this enriches the many forms our levels can take, frees us from the International Style of AAA best practices, and returns us to our position as experience designers instead of overspecialized level builders. This lets us escape high modernism and enter postmodernism (and maybe we’ll catch up with the rest of the art world eventually).

For students, my suggestion is that you shouldn’t greybox levels in Unity or Unreal by imagining a context that you can’t playtest. Doing this is making fan art levels, replicating solutions that already exist rather than learning how to solve. Instead, take a game with mod tools and an active community and design a level for that context. Seek feedback, not to hear how your level is good or bad, but to better understand who your level is for.  Then build another level with this knowledge. This is the only best practice I know to learn the skills of design.

I want to talk about a pivot happening in my side-projects as part of some larger changes in my life.

I stopped playing video games a few months ago. This would be fine—even admirable in some circles—if my job wasn’t to make video games. There are a few games I have sampled, a few minutes of something here and there, and I still mod, but I haven’t sat down to play a game in months.

Making video games in Georgia, I let work become my life. Where there were voids, I worked longer hours and spent my free time studying games. There was always more to do, always urgent, so I worked.

For my enthusiasm, my managers threw me at projects with the biggest amounts of work. In 2017 I moved my desk four times between three games. My weeks may have averaged 50 hours, but many exceeded 70. Several weekends disappeared.

There came a point I vowed I would not work another 16 hour day. Then I received a deadline where the choice was to either create something below my standard of quality (and I am not a perfectionist), or to break my vow. In the end, I did both. I remember a 74 hour week ran through Sunday into another 70 hours in a continuous 14 days, but I was still disappointed with the quality of the game. No amount of work could save it in time.

Once the deadline passed, I rationalized my unhappy results by saying “I am proud of the work I did, even if I am not proud of the product I made”. Months of recovery from that voluntary crunch, now more than a year ago, I wonder why I should be proud of the work at all.

Most people use the word “workaholic” as a humblebrag. I am a workaholic, but I don’t mean it that way. I mean when there is a void in my life, I fill it with work; this causes my friendships to fade; this expands the void further; and this invites me to work even more. My work was a malignant addiction.

To quote David Foster Wallace’s “E Unibus Pluram” about television, irony, and addiction:

something is malignantly addictive if (1) it causes real problems for the addict, and (2) it offers itself as relief from the very problems it causes. A malignant addiction is also distinguished for spreading the problems of the addiction out and in in interference patterns, creating difficulties for relationships, communities, and the addict’s very sense of self and soul.

This is what I mean when I say I am a workaholic.

Somewhere in 2016, I stopped reading. I stopped writing. I did not date. The few, short books I did read were about business management. I scoured them for ideas to fix the politics and production problems at work, so I could move at an even faster pace. Through all of this, I had become a different person.

In autumn of 2015 when I considered the job offer in Georgia, I worried it would cost me my soul. From my rural hometown with no prospects, I needed the work, I needed the experience. But after I took the job, I slowly lost something of myself.

As I kept up my pace at work, I felt burnout approaching. I had burned out once before, in college, when I took more courses than I could handle. There was a long recovery then. This time, I knew I couldn’t recover while expected to keep the pace I had set.

Moving to Canada was an opportunity to restart. Outside of a 40 hour workweek, being a stranger in a new country has meant facing the voids in my life. I could fill these voids by playing video games, by doing research for my work, but I haven’t.

In October I entered into a relationship. On our second date, we went to the local poetry slam. This reminded me how I dabbled in poetry before my job in Georgia and reminded me of the person I had been. I mentioned this and my date teased me, asked if I would ever perform a poem here. I said “maybe”.

The relationship was short, but the reminders of my past-self stuck. I was left to reexamine my values: what I want from a relationship, yes, but also what kind of person I want to be. I have had to reckon with the costs I paid in my three years in Georgia because there were costs. I strengthened as a level designer at the expense of everything else. Now I am lopsided. I see my failure in this relationship linked to my addiction to work for the ways I chose not to develop myself.

Since that relationship ended, I am writing again. I have performed at the poetry slam twice. I am reading again too. These are ways for me to grow.

But I stopped playing video games because they can’t help me do this work of introspection and healing. Games can kill time, they can anaesthetize, and—when studied—they can fill the void with work. None of this is what I have needed.

In this view, a passage from Austin Grossman’s novel You comes to mind:

Let’s admit some things about video games. They are boring. They induce a state of focus that is totally absorbing but useless—like the ghost of work or creative play, but without engaging the world in any way. They are designed to focus attention but don’t train you to overcome the obstacles to being focused.

They are fun but don’t tend to make a person more interesting.

The rewards are false coin—they are rarely satisfying or moving. More often, they offer something like a hunger for the next game …

Against this cynicism, I see how video games can be a means of social connection across long distances. Increasingly, this is what I value about the medium. This is why I work in multiplayer. However, I see this role of video games as a supplement for social connection, not the replacement it too often becomes.

I’m not sure how much of this thinking is an indictment of the medium. Games may have a capacity as tools for introspection—Firewatch and Dear Esther come to mind—but this is not our medium’s strength. If I want to see the world in new ways, books remain the best tool.

Within these feelings about work, and within the catalyst of a failed relationship, my attitude as a designer is changing. When I am feeling pragmatic (and blunt), I say my job is to design toys for children. When I am feeling poetic, I say my job is to design architecture for imaginary cities. When I tell strangers about my job, these descriptions free me of the stigmas (and embarrassments) of video games without excusing the frivolity of my work. I don’t know the terminus of this thinking.

I will return to playing games at some point. To be good at my job, I must. There are still games I want to play and games I want to make, but there are debts I need to pay first.

I hope you read this as an explanation and a warning. If I had read a post like this in 2015, I might find myself now with a life in better balance.

Moving forward, I have some fun side-projects in the works and ideas I am exploring. They may not be what you would expect from a multiplayer level designer, but I am excited to show you all when they are ready.

Thanks for reading.
– Andrew

Today I released a new Quake map, “Recursion”, which you can download over Here.

Or if you’re here to read about the map, I have some notes below!

Notes on the design

In standard Quake maps, there is an exit that leads the player into the next level, and on from there through an episode of maps. Harder levels block the exit with locked doors that require gold and silver keys, which require exploration. Mid-2000 level design replaced keys and doors with narrative equivalents—power generators and bridges, objectives and targets—before late-2000 design practices abandoned nonlinear spaces altogether. The result of this older lock-and-key pattern is that the player takes a mostly linear route through a nonlinear space, backtracking across hubs as the player takes keys to their respective doors. In Quake levels, backtracking is an opportunity for the player to reorient in what may otherwise be a disorienting space. Good backtracking also offers new gameplay through role reversals; for example, now the player fights downhill in contrast to the earlier fight uphill.

“Recursion” breaks from that format. Here there are four runes that each restart the level when the player acquires them. Once the player has all of the runes, the exit becomes available. Instead of backtracking, with opportunities for role reversals, this structure means literally replaying the start of the level multiple times to reach the end. On paper, this sounds worse! And if the start of the level was long, it would be worse. But “Recursion” quickly opens to a hub with several branches and many gameplay dynamics. Players also keep their inventory between level resets. With this format, I’ve tried to create a sandbox with a variety of toys for players to use, so the same space can play many ways. That is my goal with the format change from locks-and-keys to runes: a sandbox, not a series of skillchecks.

The short length of each branch also reduces the impact of death. There’s no need to save or load while playing “Recursion”. Since inventory persists between lives, the player can quickly try any of the objectives again, or try with a different tactic. I also applied this low-risk attitude to level boundaries. Instead of killing a player who falls into the abyss, the level teleports the player back to safety.

Another goal of this format is to keep the level alive as a world. When the player kills an enemy, collects a rune, and returns to the level start, that enemy will be alive again! I want all of the enemies to feel like inhabitants of a living world that the player is just passing through. This means the player isn’t “clearing” the level, or claiming territory.

In this way, I am drawing on the structure of Mario 64, where there are many stars to collect in a level, and each will send the player back to the start. My favorite levels from Mario 64 also play like sandboxes where I explore by setting my own goals. When I see a big hill to climb, I’ll want to reach the top, and when I do, the level replies to my exploration by giving me a star, or a boss to fight, or a puzzle to solve.

To get into the specifics of “Recursion”, I want each rune to offer its own type of gameplay:

• Rune 1: taking the left route down from the hub, the room locks in on the player and spawns 4 zombies. These enemies can only be killed with explosives, or by dealing a massive amount of damage. On a platform to one side is a grenade launcher. There are also explosive barrels for players who prefer that method, and to add a comedic danger to missed shots. There is also a quad damage powerup available in the hub before entering this space, for players who want to bypass explosives altogether. By eliminating the zombies, the room unlocks to let players return to the hub, and a cage opens to give access to the rune.
• Rune 2: at the highest point in the level, a platform floats with a rune on top. There are several routes from the first floor to the second floor. From there, a staircase leads up to the platform, and a Shambler spawns in for the player to fight! If the player skipped earlier fights during their ascent, or if the player is low on resources, this Shambler fight will be a chaotic retreat back down into the hub of the level. But once the player defeats the Shambler, a path opens to reach the rune.
• Rune 3: on the second floor of the level, a teleport takes the player into a separate arena with two moving piston-like columns in the middle. A Shambler spawns in, and the player must dodge between the dynamic cover to avoid the Shambler’s line of sight attacks. Once the Shambler is dead, a ShalRath and a Hell Knight spawn in. The former fires homing explosives projectiles, and the latter swings a sword and fires a fan of fire arrows. Both pressure the player to keep distance, but the homing explosives require the player to move and either lead the shot into the Hell Knight or into one of the pillars. After all enemies are dead, paths open to reach the rune, or to return to the hub. This rune is the closest to a traditional Quake skillcheck encounter.
• Rune 4: on the far right side of the level, a series of moving platforms cross a chasm to a button. On pressing the button, the player has 8 seconds to return and loop up a staircase where a cage has opened and made a rune available. The void under the platforms teleports the player back to the button, where they can quickly make a new attempt across. I designed this to be a bit of a puzzle, where there isn’t enough time if the player jumps on each platform as it becomes available. The solution is to make two longer jumps across, instead of four short jumps. This rune is frankly the weakest of the bunch, since there is only one correct way to complete it, and since partial failure is still punished. (I’ll be making a few tweaks in the next version.)

Beyond the runes, I also added a hard mode that makes the level much sillier. When the player walks along a ledge off to the side of the level start, a message warns the player that they’re about to activate “Fiend Mode”. If the player continues and picks up the relic at the end, their next instance in the level will be on hard difficulty, with many Fiend enemies added to the level. The Fiends tend to lunge past the player and off the level edge, where they are teleported back to the start. The result is as much humor as danger. This hard mode also gives the player the lightning gun and piles of ammo at intervals, which balances out the added enemies. Altogether, the changes of this “Fiend Mode” make the level about speedrunning and avoiding enemies on the way to each rune. It’s not a pure difficulty increase, but rather a new way of playing in the sandbox.

What’s next?

If you’ve followed my design blog for this year, you’ll know I wrote about these ideas back in March in “Early notes on Level Design Playgrounds”, and also back in December in “Halo’s Multiplayer and Public Parks” with an eye toward multiplayer. “Recursion” is the result of asking myself the easiest way to start testing these ideas and putting so much talk into practice. But there’s only so much I can do with vanilla Quake, and I had to skip many of the ideas from that March post.

Altogether, “Recursion” was maybe 24 hours of work (4 evenings after work, 5-6 hours each), ignoring dozens of scrapped level ideas that came before. For such a short turnaround, I’m glad it has proven a few of the core ideas.

In the long term, testing this playground design theory in Quake calls for a total conversion:

• New art assets to create a happier and more inviting world.
• A wider range of interaction options, fewer “do damage” weapons and more “do [thing]” tools. E.g. reimagine the rocket launcher as a no-damage knockback tool.
• Tools for randomization and surprise, like Mario Kart blocks.
• Full support for co-op.
• Respawning enemies and items instead of hacky level resets.
• Allow multiple levels of this type in an episode without restarting the game.
• …

But that’s all too much for a side project, and it would take too long to get results. So, the short term:

• A bigger level, where each rune feels like a distinct area
• A better solution to varied gameplay than precision platforming
• Try separating the level start from the level proper, for a less jarring reset
• Look into basic code changes for a less hacky experience

These are a bit easier to achieve on my own. At the very least, they’ll verify the ideas of “Recursion” as more than a one-off gimmick approach to Quake level design.

That’s all for this post. Thanks for reading!

 

 

Yesterday was my last day at Hi-Rez Studios. I have some time before my next job starts, which means a little vacation, maybe some new Quake maps, and also some time to reflect. All of the information in this post is publicly available, but I wanted to gather it up in one spot.

My first day on Paladins was the launch of closed beta, November 17th, 2015. I started as an associate level designer under Jordan Smith as lead level designer. At that time, Paladins had the look and presentation of a fantasy Team Fortress, but it played like an MMO’s PvP arena. Paladins had a limited set of roles and a first person camera with shooter gameplay, but the combat was far more about the calculus of a high time-to-kill brawls. Damage-over-time attacks and crowd control abilities like stuns, slows, and fears were key to winning objective fights. The mismatch of player expectations around first person gameplay was a problem for many players.

The closed beta of Paladins had its niche, but the design needed to change for the game to succeed. In those first few months, the decisions about the game’s identity seemed like a knot of many interacting factors: lower or higher time-to-kill (TTK), fewer or more champions, random cards or decks or item shops or levelups. With distance—and a false confidence that comes from forgetting the details—the choice seemed to be 1) make a niche, casual game embracing the random cards on the MMO Arena combat style, or 2) make a mainstream, competitive game with a fast TTK and less impactful cards. It took a long period of experimentation to settle on the second option, and then another long period of experimentation to get our levels up to speed.

This was the topic of my GDC talk at the Level Design Workshop (slides here, video isn’t public yet). The short version is that we spent 2016 redesigning maps for faster competitive design, believing that we could serve a wider range of player motivations at the same time. This left many non-competitive player motivations forgotten, and I feel we’ve only come back to serve our wider audience in the last few months.

In the summer of 2016, I was promoted to a mid-level role and Hayley Williams joined the team as an associate level designer. As we finished the redesign for the maps, we also worked on early versions of what became “Stone Keep”, which we released in January of 2017. Around that time, we also started a public test queue of greybox maps to help us vet the quality of new designs before entering full art production. The team kept updating the test queue and adding new maps until the fall. By July of 2017, with the three of us designing maps for the test queue, we understood the formula for solid competitive designs. Unfortunately, if you care about competitive play, the formula is strict. That’s why all of the Siege maps from “Stone Keep” onward are variations of a c-clamp shape.

This limitation was frustrating. I built “Sandbridge” and “Sewer” for the test queue as alternatives to the c-clamp formula. They were fun gimmick maps for the test queue, but they would have made terrible competitive maps. A good rule of thumb: if you want players to like your map, don’t name it “Sewer”.

2016 had been about solving the problem of level design for Paladins, and the first half of 2017 was about refining that solution. This was a slower, easier task, so I sought new challenges by moving to Smite Adventures.

After that, things sped up and blurred together. I worked on Smite Adventures for a few months, then I worked on the battle royale prototypes that led to Realm Royale, and then I came back to Paladins. I moved my desk 5 times in 2017.

In these last few months on Paladins, I have tried to improve some processes so the team is set up for success. There are some great things in the works, and I’m looking forward to experiencing them as a player.

My Time at Hi-Rez (approximated from memory)

• Winter 2015: More Siege?
  • At launch of closed beta, we had two maps: “Temple Ruins” and “Enchanted Forest”. These were designed by several level designers who left the project before I joined (I believe it was Katelyn Pitstick and Kevin Powell) and by Jordan Smith.
  • In this phase, we explored new Siege layouts and we released “Glacier Keep”, designed by Jordan Smith.
• Winter – Spring 2016: We add payload
  • I built “Outpost” the first payload map, a remake of “Ice Floe” from Global Agenda with a few minor gameplay adjustments.
  • Other maps of this period were “Serpent Temple”—later renamed “Hidden Temple”—and “Frostbite Caverns”, both payload maps designed by Jordan Smith.
• Spring 2016: Survival!
  • “Tropical Arena” – I built it as a skirmish arena for 2v2 and 3v3s, but plans change and we released it for the 5v5 survival game mode.
  • In this period I also designed the layout that became “Snowfall Junction” a year later.
• Late summer 2016: The massive 3-Lane Siege maps turn into 1-Lane Siege maps!
  • “Frog Isle” – a new siege map drawing inspiration from the canyon objective of “Temple Ruins”.
  • “Serpent Beach” – a siege map modifying the sunken city objective from “Temple Ruins” with a new payload route.
  • “Jaguar Falls” – a siege map modifying the ruins objective from “Temple Ruins” with a new payload route.
  • “Timber Mill” – a siege map remixing the second half of the payload push on “Outpost”.
  • “Gauntlet” – a siege map remixing the first half of “Outpost”, later removed from siege and turned into the tutorial.
  • “Fish Market” – a siege map remixing two objectives from “Enchanted Forest”
  • Other maps of this period were “Waterfall”, “Frozen Guard”, and “Ice Mines”, which Scott Zier started as modifications of “Glacier Keep” and which Jordan Smith finished for release. Zier worked on the project for a few weeks to guide the design process.
  • We removed “Waterfall” in the next patch along with “Gauntlet”.
  • In this period, we also removed Survival and then later on removed Payload, but I forget when exactly.
• Winter – spring 2017
  • “Stone Keep” – the first new siege map in the one-lane format
  • “Snowfall Junction” – the first  survival map built with survival rules in mind! But then we disabled Survival (again?) and released the Onslaught mode.
  • “Primal Court” – a layout revision for “Tropical Arena” as an Onslaught map.
  • My memory is really fuzzy on when exactly Survival went away and came back and then was replaced with Onslaught.
  • We also started the Test Queue for releasing work in progress greybox maps and getting feedback. I released 7 of these maps in the first half of 2017:
    • “Undercity” – a map designed to gauge the response to high-complexity maps.
    • “Grotto” – became “Splitstone Quarry”.
    • “Frog Isle Redo”
    • “Forward” – the only payload map we released in the test queue.
    • “Moss Garden” – a high-complexity map inspired by a David Bowie song.
    • “Sandbridge” – a map designed for flying flanks and long sniper sightlines.
    • “Sewer” – a map designed for healers and tanks with no room for flanks.
• Spring – summer 2017: focus on Siege and competitive play
  • “Splitstone Quarry”, a siege map attempting to be slightly more complex than “Jaguar Falls” and “Stone Keep” to serve our competitive players.
  • Another map in this period was “Brightmarsh”, designed by Jordan Smith. He also designed “Ascension Peak” in this period, which released the following winter.
• Summer – fall 2017: Smite Adventures
  • “Corrupted Arena” – a remix of the Arena map to have pits and meteor strikes. The design started before I joined the team, and I helped guide it to completion.
  • “Shadows over Hercopolis” – a 3 player cooperative dungeon in the style of an MMO raid with an ice region, lava region, and an underworld. Travis Brown led the design with Dishant Samtani and Matt Barcas working on the design of the encounters, bots, and boss behavior. I prototyped the encounters, implemented the designs into the level layout, and coordinated with environment art.
  • During this period on Paladins, Hayley and Jordan worked on maps for the Onslaught and Team Deathmatch game modes. Hayley designed “Magistrate’s Archive”. Jordan designed “Foreman’s Rise” and “Trade District”. “Ascension Peak” art also started production. I forget if “Snowfall Junction” and “Primal Court” were still around at this time, or if they came back as Onslaught map after having been disabled.
• Fall 2017 – Spring 2018: The royales
  • In this period I worked on the version of Paladins Battlegrounds that we showed at HRX. I led the map design for this initial version, but got help from the rest of the Paladins design and environment team as we wrapped up.
  • After HRX, I did the groundwork for version 2 of the Paladins Battlegrounds map, which we released in March 2018 for a few days before shutting it down and taking it back to internal iteration. During the new phase of iteration that led to Realm Royale, I returned to Paladins.
• Spring 2018: Back to Paladins
  • Aesthetic and gameplay touchups on “Frozen Guard”, “Ice Mines”, “Frog Isle”, and “Timber Mill”.
• Early summer 2018:
  • “Rise of Furia” – an event map that starts with a platforming climb up a tower and then turns into a Team Deathmatch brawl.
  • ???
  • ???

Public Works
This timeline is a list of my public works, and I mean “public works” as a play on words. First, these are the works that went live to the public, not the many levels and experiments that didn’t make the cut. There is no “Stone Keep” without the dozen versions before it and the lessons we learned from them. Second, “public works” because I like how Paladins is open to the public, like a small town diner. As a level designer, I feel like I’m working at the grill to serve you something, or that I’m a line cook in the kitchen working with a team to make the best meal we can. Because I work in multiplayer, nothing I’ve built will last forever, but I want it to be excellent for as long as it does.

That also means ownership is kind of a weird concept. In the timeline of my work above, I tried to give credit where due. “Serpent Beach” and “Jaguar Falls” are some of the best maps in Paladins, and those were modifications of older work by other designers. Now that I’m off the team, my contributions may also be subject to modification, touchups, and reworks to make the game better. It means after a while I won’t be able to go back to any of “my” works as they were, but it also means they never were “mine”. This is a weird feeling that I am still processing, but there are definitely some maps that I hope the team will get around to reworking (Frog Isle, please)!

Conclusion
Working on a live project for a couple years has meant facing all of the ghosts of what could have been. There is a ghost of Paladins for every card system. There is a ghost that pivoted to consoles earlier, and another that never went to console at all. There are ghosts of art, where we could’ve leaned into the sci-fi inspirations instead of the fantasy. After these years, I can’t play Paladins without feeling haunted by all the forms it could have taken.

The ghosts that haunt me most are the ones where we didn’t chase esports and competitive play. This was at the heart of my GDC talk. I imagine a version of Paladins that could have been the Mario Kart of first person shooters. Maybe if we’d done that, I would be writing a similar post looking back and imagining Paladins as a competitive game. Collecting these ghosts seems to be part of the job.

And while some of these ghosts may have been better games, many more would have failed. There was a moment when hero shooters seemed to be the Next Big Thing, like MOBAs had been a few years earlier, but then a few of those games didn’t catch on and battle royales took off instead. We were incredibly lucky that Paladins found an audience. I want to emphasize, this was luck and not thanks to skillful foresight or expert design or market research or whatever. I am very lucky that I was able to work on Paladins for a couple years, and I am proud of the work I have done to make the game what it is.

Thanks,

Andrew