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

 

Throughout the Practice 2018 design conference there was a question of building games around cooperation and negotiation. Several talks referenced the prisoner’s dilemma and its payoff matrix as a way to describe a range of outcomes for cooperation and competition. Through conversations, this problem solidified: how do we build cooperation into traditionally competitive multiplayer games? A successful solution to this problem requires cooperation and competition to both be viable and fun strategies.  (Idling in a tied match until the server instance shuts down is neither). I also think these strategies should exist inside the game’s systems and mechanics instead of relying on the social dynamics that surround multiplayer games.

Fuzzy Cooperation in Battle Royales
To me these question are a response to the popularity of last-player-standing battle royale modes and the mainstream industry’s shift toward multiplayer. For the codified battle royale format, there is no cooperation in solo play. Even in squad variants, cooperation is limited to a tribal Us vs Them. These games lack mechanics to build and maintain social contracts, and there are few interactions that can benefit multiple teams. There is nothing to negotiate. At best, two teams may independently decide to keep their distance instead of fighting, or to pick on another team first.

For Player Unknown’s Battlegrounds, intentional team killing in squads and teaming up in solo play are against the rules of conduct and can be punished by a ban. There are some good reasons for this. If players were allowed to team up in solo mode, they would gain unfair advantage, which would undermine competitive play and hurt the game as an esport. In Fortnite’s code of conduct, players are told to “Play fairly and within the rules of the game”, and Epic has penalized players who team up in solo mode.

This is a significant divergence from the original inspirations for battle royale game modes. DayZ, a mod for Arma II, put its players and zombie AIs together in a huge map. Around its initial release, players were unfamiliar with the mechanics and were afraid of the zombies. As a result, those new players would signal willingness to cooperate so they could better survive. Over time, players learned the rules of the world and players formed groups. These gangs became bigger threats than the predictable zombies, which turned the game into a cruelly tribal PvP experience where kidnapping and enslavement became norms. DayZ succeeded as a multiplayer story generator, and it demonstrates both the positive and dangerously negative outcomes of fuzzy cooperation.

 

Another inspiration these game modes claim is the film Battle Royale about a class of students in Japan who are forced to fight to the death on an island with no escape. Unfortunately, the game modes only draw inspiration from the setting and its rules, not the social dynamics that emerge in the story. Only a few students in Battle Royale are eager to kill their classmates, and most of the students reject the rules and try to cooperate and escape. On top of being an exciting action film, Battle Royale is about generational conflict in Japan, where youth are expected to enter a competitive, zero-sum business world. The Hunger Games series falls into a similar category for a Western audience. In both of these works, the only ethical moves are to break the rules, and that gets messy when trying to survive against competitors who are acting within the immoral rules.

When I worked on a battle royale for a few months, I wanted the mode to return to its source material. In the early iterations, I had a few lofty goals (which we didn’t get to explore):

1) undermine competitive play in favor of generating unique stories. Surprise and uncertainty are the best tools for generating stories in multiplayer, and they comes at the cost of fair competition. This also means keeping the game accessible for new players by limiting the skill ceiling and going wide with systems instead of deep.

2) create ways for players to break the rules of the battle royale. My hope was to include some improbable system for a cooperative victory. (My example for this idea was to randomly spawn a “One Ring” that players could destroy in “Mount Doom” on the far side of the map.) This goal of breakable rules also means encouraging dynamic teams where cooperation and betrayal are both valid play.

3) keep death meaningful. A dead player shouldn’t back out to the menu and launch a new match as though they were respawning in an arena FPS. They should feel investment in the story of their teammates and the world. Even a defeat should feel like a complete story.

I think one key to hitting these goals is to add improbable systems for players to revive their fallen allies. One version of this system would be a “graveyard” that teams must reach and fight over to revive their friend. A more forgiving version would be like Left 4 Dead’s closets or Spelunky’s co-op coffins, where each new level section offers a chance to “rescue” a dead teammate, at some risk. Spelunky’s co-op mode also keeps dead players involved by letting them fly around as ghosts and nudge objects in the environment. The importance of these mechanics is to keep dead players invested in the game and to affect the team’s story instead of encouraging them to quit to the menu.

All of these ideas have problems to solve in the specifics of their implementation. My larger hypothesis—that cooperative story generation should take priority to fair competition—may also be false (which is to say, it may serve too small of an audience to be viable as an online game). That said, as designers who have codified the battle royale mode, I feel we have failed our source material by prohibiting cooperation and embracing a zero-sum design.

Fuzzy Cooperation Inside the Mechanics
My examples of cooperation in existing battle royales rely on external social mechanics and rules of conduct rather than mechanics built into the game. For a version of this interaction that plays through mechanics, I want to look at the MOBA formula.

For readers who aren’t familiar, the traditional MOBA has two teams of 5 that respawn at bases on opposite sides of a 3-lane map. Each team has towers that protect their lanes from waves of AI that spawn at their opponent’s base. There are also neutral AI in areas between the lanes that players can fight over to gain resources. A player spends their resources to improve their character. Each character is unique and may have different resource needs as the match progresses. Destroying the enemy base wins the match. Beyond this, a lot varies between titles. The complexity of MOBAs makes many strategies viable, and there are ways for teams to adapt and exchange resources to get ahead.

For a prisoner’s dilemma MOBA modification, we could start with the same foundation. We would keep the two teams of 5 with their own bases that can be destroyed. We would also keep the idea of players gaining resources to improve their characters. However, instead of team AI spawning in waves to attack the opposing team, the AI would be an antagonistic third party that would spawn to the side and attack both teams. This AI team would scale in difficulty over time so that the players are pressured to gather resources efficiently. The longer a team survives, the more points they earn, and the final score would go to a leaderboard. If one team decided to steal resource from the other, they may survive longer and thus “win” the match, but they will score lower on the leaderboard than teams who cooperated. The variety of resource needs for each team should also be asymmetrical so that “trade” or “resource gathering permission” emerge in gameplay.

If players violate the peace by stealing from the other team or attacking, there need to be non-verbal tools for negotiation. A robust emote system to signal intent may suffice, but a global chat system could make cooperation too easy and introduce other problems.

While I believe this is a solution to the design problem, there are other faults. First, in this design, a “win-win” solution is still a “defeat”. Second, the mechanics are now too strict for generating a wider range of stories. As a result of these problems, I expect the game would have trouble retaining a playerbase.

Fuzzy Cooperation, but Cozy?
Another path to explore in the overlap of cooperation and competition is the idea of “cozy” design. In 2017, one Project Horseshoe report explored what it means to make a cozy game, and related research has looked into design patterns for friendship and the spectrum of player trust. To achieve the goals of these models, any competitive mechanic that can violate trust may come at too great a cost. It seems that this means swinging to the opposite side by adding competition into a cooperative game. But I think there is a way to add cozy cooperation as a subversive element within competitive games.

My early intuition here is to add features that function as “community gardens” do in real neighborhoods. Interactions with these “gardens” would persist across many multiplayer interactions and benefit other players. The garden would be a medium for giving gifts to the community, and for player expression.

An easier implementation: add toys to a competitive environment. Add a big trampoline in the middle, add a fishing pond, add a slip’n’slide. Let players opt out of competitive play if they want, and give them the tools to do so.

Other Examples?
I’ve had my head down in traditional multiplayer design, and I know I’m blind to some of the work going on in this space. However, there are a few recent examples that come to mind:

• Destiny 2 is adding a new game mode called “Gambit” where two teams fight separate waves of enemies and have opportunities to invade the other team. This sounds like a horde mode with a little competitive play added in, but well have to see how it plays out.
• Fallout 76 is online with a shared, persistent world of a dozen or so players. It is not strictly competitive or cooperative. It is also not clear how the game will police uncooperative behavior, or if it will have the same problems as Ultima Online.
• One Hour One Life is a shared world multiplayer game by Jason Rohrer where players try to advance technology by working on the civilizations that outlive their characters.

Conclusion

There is potential for us to reach new audiences and tell new stories by moving away from traditional competition. As a multiplayer designer, I want to create better shared experiences (and create fewer experiences that encourage toxicity and hate). I think there is potential to achieve these goals in games designed around fuzzy cooperation and negotiation. There are also many problems to solve, but I hope this post has been a useful step forward.

Thanks for reading!

References:

All sources were retrieved July 4th, 2018

• Player Unknown’s Battlegrounds Rule of Conduct https://www.pubg.com/rules-of-conduct/
• Fortnite Code of Conduct https://www.epicgames.com/fortnite/en-US/news/fortnite-code-of-conduct
• PCGamesN “Epic Will Ban You if You’re Caught Teaming Up In Fortnite Solos” https://www.pcgamesn.com/fortnite/fortnite-squads-solo-matchmaking
• Kotaku “DayZ Player Sings and Plays Guitar for His Life” https://steamed.kotaku.com/dayz-player-sings-and-plays-guitar-for-his-life-1693226685
• Project Horseshoe “Coziness in Games: An Exploration of Safety, Softness, and Satisfied Needs” https://www.projecthorseshoe.com/reports/featured/ph17r3.htm
• Raph Koster “The Trust Spectrum” https://www.raphkoster.com/2018/03/16/the-trust-spectrum/
• Raph Koster “A Brief History of Murder in Ultima Online” https://gamasutra.com/blogs/RaphKoster/20180627/320893/A_brief_history_of_murder_in_Ultima_Online.php

In my work, I’ve started thinking of multiplayer level design in terms of public parks and playgrounds. I’ve found these metaphors useful while trying to integrate new design ideas—especially design patterns for friendship and trust—into older multiplayer design patterns.

So, on my flight back from GDC today, I took some time to think about actual public parks and playgrounds. Some principles:

• Users can enter and leave a public park freely.
  • Most activities, like using a swing, are short instances with repetition. These activities do not lock users in for a long duration (social activities are more complex).
  • Some public parks offer walking trails, which can lock users in for a longer duration. When designed well, these longer activities offer rest breaks along the way and shortcuts back for those who need them.
• The park and its resources are not depleted through use.
  • A playground’s toys and their potential for play persist between uses.
  • Some resources, like a bench or a swing, are “held” or “blocked” while in use. This requires turns and sharing when demand is high.
• Playgrounds are fundamentally multiplayer (not fun when alone), supporting parallel play and cooperative play (like see saws and tire swings).
• Good public parks give options for different kinds of users
  • The children can play on the playground while the parents talk on a nearby bench.
  • One user can walk through a garden while others play a sport in the fields.
  • In this way, the park is a foundation for many activities.
• Excellent playgrounds offer the potential for “subversive” play, like walking up slides or devising other routes that feel unintended.
• Playgrounds aren’t ashamed of being toys.

I then adapted these ideas to imagine an alternate reality to Doom (1993):

• The game is fundamentally multiplayer, supporting opt-in competitive and cooperative play. Players can drop-in or out of servers as they please.
• The level exit is available from the start. Some areas in the level require the player to backtrack some distance, but no areas lock the player into an activity.
• No resources are required or consumed.
  • All doors can be opened and closed, and none require keys.
  • NPC Enemies all respawn, or “freeze” for a duration instead of dying.
  • Player also don’t have health, armor, or ammo to collect.
    • Without health or armor, this means that all incoming enemy attacks are limited to their audiovisual feedback.
  • Players can’t hoard weapons. Instead they may only use their current weapon, drop it, or swap it for another. There are no ammo limitations.
• Combat areas are all opt-in, with safe areas available to take breaks.
• A score, if it exists at all, is opt-in or player-controlled. The game does not dictate a correct way of playing.
• The level offers a range of activities, making full use of exploding barrels and elevators and collapsing floors (so long as all reset for the next player).

This is a very different game!

In particular, removing combat attrition and resource management reduces the challenge of Doom. If a player’s goal is to spend all their time in a “flow” state (where their skill is met by the game’s challenge), then these changes gut Doom‘s depth. But in that exchange, this alternative Doom gains something. This Doom could be the place players meet on their way to other activities, or the place they go to relax and spend time in peaceful conversation.

I’m not sure what conclusions to draw from this, since my example is an extreme. I think some of these problems may be known within MMO design, though. Time to do more research!