The Language of Arena FPS Level Design
What Is The Problem?
Studying architecture, I've spent a great portion of the recent years thinking about what makes environments sufficient to their requirements or what makes them whole. At the same time, arena fps mapping is something that has always been in the back of my mind. The conditions are kind of similar for creating real spaces and virtual levels. There is a context for these environments, and certain geometries create forces that influence "users" in their actions. Sometimes the designers introduce forces they could not predict. Just like architecture, arena fps map making has never been fully figured out and certainly never will as long as we rely on individual intellects for telling us how maps should be made. Part of that is surely because of the fact that the Quake games which kicked off competitive arena fps, are older than the profession of the level designer as we know it today. Quake mapping has never been systematized although there have been attempts (which again nobody had the competencies to verify). I'm not claiming I have these competencies, my judgement is just as limited as anyone eles'.
Approaching The Problem
Now where am I going with this? Obviously, map design in arena fps is governed by the respective game's mechanics, and apart from that by the player skill. If we consider the case of a professional gamer who can perfectly use all of the game's mechanics, map design just is a direct response to the game's mechanics. A game's mechanics however, aren't only developer made. Developers suffer the same problem as other designers: They sometimes fail to comprehend the consequences of their actions (which I guess is human). By making a game accessible to a playerbase, it is going to be tested and exploited. New dependencies arise by how the players interact with the framework that the game is and also by how they interact with each other. This effect is not immediate, it's a process driven by the contribution(s) of many. To get back to the core, map design, depends on a game's mechanics, which are not only driven by the developers but also by the players and the interaction between them. It is a node in the network of dependencies that make a good arena fps. I think it is pretty safe to say that in order to make a good level, one is obligated to understand the game's mechanics as described above.
My Proposal
How to go about that though!? In our competetive map pools, we usually have five to seven maps, all of which are essentially unique. However, all of them seem to work which shows that the issue I'm discussing here is a complex one. My research in the context of architecture has made me stumble across Christopher Alexander's concept of pattern languages. To not get too theoretical here, let's call this a language or network in which the words or nodes are essentially descriptions of situations and actions present in living environments. All of the nodes are linked to each other in a specific way so that each node needs certain sub nodes to be complemented but at the same time complements other nodes "above it".
The very idea is to help people understand problem structures and to give them an instruction on how to resolve them. This is all rooted in the idea of solving a problem by understanding a problem; which in my eyes is exactly what has to happen in respect to level design in arena fps.
How many more decent duel maps could we get if every designer knew about the design relevant nodes, "initial spawns", "inital control distribution", "playing out of control", "control shifts", "respawns", "making noise", "early game", "late game", "high ground advantage", "fake rocket jump", "armor distribution" to just name a few potential nodes of this virtual network that describes arena fps design. Enabling every map maker to understand the connection between those terms, visually comprehending what connections each one of them has, would be a first step towards creating an objective understanding of making suitable levels for arena fps.
If a single person however, was able to set up a complete "whole" network like this then surely we'd have it already. Fact is though, that pretty much no one, neither the best designers, nor the best pro players are able to put their thoughts down in a way that gives us a whole perspective like this. In my opinion, this can only be a collaborative community task.
I'd like to kick off a web interface to establish this and combine it with my architecture research next term. Please feel invited to join the discussion on this topic.
Current Pool of Patterns (To Be Updated):
Studying architecture, I've spent a great portion of the recent years thinking about what makes environments sufficient to their requirements or what makes them whole. At the same time, arena fps mapping is something that has always been in the back of my mind. The conditions are kind of similar for creating real spaces and virtual levels. There is a context for these environments, and certain geometries create forces that influence "users" in their actions. Sometimes the designers introduce forces they could not predict. Just like architecture, arena fps map making has never been fully figured out and certainly never will as long as we rely on individual intellects for telling us how maps should be made. Part of that is surely because of the fact that the Quake games which kicked off competitive arena fps, are older than the profession of the level designer as we know it today. Quake mapping has never been systematized although there have been attempts (which again nobody had the competencies to verify). I'm not claiming I have these competencies, my judgement is just as limited as anyone eles'.
Approaching The Problem
Now where am I going with this? Obviously, map design in arena fps is governed by the respective game's mechanics, and apart from that by the player skill. If we consider the case of a professional gamer who can perfectly use all of the game's mechanics, map design just is a direct response to the game's mechanics. A game's mechanics however, aren't only developer made. Developers suffer the same problem as other designers: They sometimes fail to comprehend the consequences of their actions (which I guess is human). By making a game accessible to a playerbase, it is going to be tested and exploited. New dependencies arise by how the players interact with the framework that the game is and also by how they interact with each other. This effect is not immediate, it's a process driven by the contribution(s) of many. To get back to the core, map design, depends on a game's mechanics, which are not only driven by the developers but also by the players and the interaction between them. It is a node in the network of dependencies that make a good arena fps. I think it is pretty safe to say that in order to make a good level, one is obligated to understand the game's mechanics as described above.
My Proposal
How to go about that though!? In our competetive map pools, we usually have five to seven maps, all of which are essentially unique. However, all of them seem to work which shows that the issue I'm discussing here is a complex one. My research in the context of architecture has made me stumble across Christopher Alexander's concept of pattern languages. To not get too theoretical here, let's call this a language or network in which the words or nodes are essentially descriptions of situations and actions present in living environments. All of the nodes are linked to each other in a specific way so that each node needs certain sub nodes to be complemented but at the same time complements other nodes "above it".
The very idea is to help people understand problem structures and to give them an instruction on how to resolve them. This is all rooted in the idea of solving a problem by understanding a problem; which in my eyes is exactly what has to happen in respect to level design in arena fps.
How many more decent duel maps could we get if every designer knew about the design relevant nodes, "initial spawns", "inital control distribution", "playing out of control", "control shifts", "respawns", "making noise", "early game", "late game", "high ground advantage", "fake rocket jump", "armor distribution" to just name a few potential nodes of this virtual network that describes arena fps design. Enabling every map maker to understand the connection between those terms, visually comprehending what connections each one of them has, would be a first step towards creating an objective understanding of making suitable levels for arena fps.
If a single person however, was able to set up a complete "whole" network like this then surely we'd have it already. Fact is though, that pretty much no one, neither the best designers, nor the best pro players are able to put their thoughts down in a way that gives us a whole perspective like this. In my opinion, this can only be a collaborative community task.
I'd like to kick off a web interface to establish this and combine it with my architecture research next term. Please feel invited to join the discussion on this topic.
Current Pool of Patterns (To Be Updated):
initial spawns
inital control distribution
playing out of control
control shifts
respawns
making noise
early game
late game
high ground advantage
fake rocket jump
armor distribution
Shortest Item Connection
Safest Item Connection
Narrow Threshold (choke points that don't give a lot of room to dodge)
Change in Elevation (including the different forces introduced by jumppads, teles, rocket jumping)
Control Shifts
Player Delays
Item Delays
Defendable Positions
Vulnerable Positions
Items on a Platform
Items on a Pillar
Items on Even Ground
Items in Dead Ends
Items in Alcoves
Items under Drop Downs
Items at the top of a staircase
Floating Items
Items in Water
Moving to an Item spawn
Visibility of the Item Spawn(long range vulnerability e.g. rail)
Narrowness of an Item Spawn (splash vulnerability e.g. rockets)
Close Player Respawns
I suspect this reaction is driven by the need to distinguish their designs from those made in the past 20 years or so, however, this is something like designing architecture and ignoring the rules of physics.
I look forward to whatever project you're working on, and I think a centralized database of information would actually be awesome.
The issue with arena fps mapping is that there is no set constraints, other than the gameplay mechanics. One simple constraint right off the bat would be the player jump height and step height. Geometry needs to be at a certain height range in order for the player to be able to access it without trick jumps. While this may seem obvious, things start to get extremely complicated with the movement in Reflex due to variations in jump types. This is where you can start to see that the limitations don't actually help, but rather pose a major challenge to the designer, as they can quickly start becoming subjective in their room layouts.
With that being said, A good designer would introduce their own constraints based off of a narrative. Some of the most successful designs tend to tell a story. By this, I mean a culmination of things, such as the theme, visuals, mood, intended gameplay pace, objectives, opportunities for out of control players, etc. Basically anything that will make the map feel like it has a purpose other than fragging people inside of pretty geometry.
Once the narrative is provided, the rest can easily fall into place. An example of good map design can be seen in Overwatch. The maps in OW tell a story, based off the lore and gameplay mechanics. Opportunities for the layout/architecture of the map arise from the story and from the mechanics of each character. Although difficult to compare to Reflex due to gameplay differences, I feel it is a good example of map design arising through the use of narrative and constraints.
I'm extremely interested to see what type of "nodes" you can come up with and seeing if there's a way to assign importance/influence to them in order to create hierarchy and a bit of order to such an open ended problem. Maybe this node graph can inform of unforeseen gameplay conflicts before the geometry is even planned out, thus aiding the designer in creating their narrative/layouts.
I agree with you completely, the particular difference with games is that you not only define the geometry and relations but also their context, which makes it difficult.
It's interesting that you refer to the movement complexity of reflex. This "problem" is something I definitely see as resolveable by the use of nodes. Being aware of the relations of aereas in your map, knowing what impact increased connectivity by fancy ramp jumps has on them. However, I guess this is too complex to be discussed in text form so I'll stop here.
The narrative is actually a good keyword, maybe it can be a major pattern in the network. In the case of the arena fps we know, I guess the narative would be something along the lines of fast aim heavy maps, larger item control heavy maps, weapon control heavy maps, maps leaving out certain weapons. Based on those meta targets you set for yourself, that might change how you arrange nodes for your map.
As for the visualization of these nodes, there are many ways to approach the problem. One that quickly comes to mind is using topological diagrams to convey the importance of certain item connections or to convey certain gameplay aspects that the author wants to introduce at an early design stage. You could imagine how your dependencies can be placed together with different values that affect their connectivity. Im not sure if you've used grasshopper, but that would be an great way to experiment with this sort of node network you bring up. Check out this book and look at sections 11+12, that should give you a quick visual of what Im talking about. I feel this might be a good tool for crafting an initial map narrative and layout. The rest of the geometry is then derived from context-specific situations, much like how you described your process behind Cure's mega health room.
Another good example of a map that feels somewhat systematic to me is Infinity (ctf). The "3-2-1-2-3" layout is apparent when you think about the number of major rooms as they pertain to the distance traveled into the enemy base. Middle map has a bigger open fighting area, allowing defenders to have a chance at returning their flag. It creates layers of connectivity and "defensibility", as it almost feels more dangerous the deeper you are into enemy territory. Another great example of this is ironworks. The RA room is a massive risk to the offensive player, as there is a high potential of getting noticed and killed due to noise, water physics, a window overlooking the exit, and a narrow corridor offering little cover. The defensive player taking their own RA must leave their flag room and travel to the teleport, unless they rocket jump. These sort of moments in my opinion can be very powerful to the success of a map, as they create risk/reward scenarios that when successful, and create those "dopamine" moments you mentioned.
The thing about CTF is that there is a very clear goal, provide balance and 2 flags. In Duel, the goal is very different, as the only goal is to kill the other player by creating advantageous situations for yourself and using the map as a tool to achieve the kills. Based off of this idea of a map being a tool used to create unique experiences, one can then start to create the narrative. Maybe you want to create a chaotic control-shifting map with little resources, forcing players to frag quickly while they are ahead in armor. The geometry of this map would then need to reflect this idea and help support this narrative. Toxicity is an example that comes to mind that seems to do it quite successfully.
I want to acknowledge the general debate on how to start a duel map. I think a good map, in the first place, needs to generate fun. It needs to be able to generate those moments we love about arena fps, air rockets, clutch rail shots, LG carrying, moving elegantly. I used to try and establish this quality mostly by having a "fun" idea for a certain major item setup which would give a certain range of opportunities for moving and at the same time make a player vulnerable through that way of moving. Then I would see how the rest of the map would connect to that.
In fact, for quake live's cure, it started out with the MH room, the necessity to jump to MH from different height levels, the angles from the low shards or the RL that would enable carefully timed long range shots. The rest of the map was then by a large part added additively and dynamically. Today I'd consider this way of doing it as not sufficient.
The start of a duel game is very bipolar, just because of the way stack and weapons are distributed depending on the initial spawns. The first interaction occurs during the first set of respawning items. We often see in control players attempting to delay items in order to avoid timing conflicts or out of control players trying to delay the in control player in order to create them or interrupt his item cycling. In any case, there is dynamics in place, creating forces through timing that impact the velocity with which players move into and out of certain areas. What makes a map fun is not only the geometry itself, but also and even more so the way those interactions can take place. I'd therefore try and throw the following terms into the pools of patterns to be combined in order to describe major item setups:
About the dependencies of major items:
Shortest Item Connection
Safest Item Connection
Narrow Threshold (choke points that don't give a lot of room to dodge)
Change in Elevation (including the different forces introduced by jumppads, teles, rocket jumping)
Control Shifts
Player Delays
Item Delays
About the geometry around major items:
Defendable Positions
Vulnerable Positions
Items on a Platform
Items on a Pillar
Items on Even Ground
Items in Dead Ends
Items in Alcoves
Items under Drop Downs
Items at the top of a staircase
Floating Items
Items in Water
Moving to an Item spawn
Visibility of the Item Spawn(long range vulnerability e.g. rail)
Narrowness of an Item Spawn (splash vulnerability e.g. rockets)
Close Player Respawns
Following up, you will surely agree with me, that a major item on even ground in a dead ends will assign a different kind of importance to the Rocket Launcher than an item on a platform would if we compare it to the usability of the Lightning Gun for instance. An example would be the RA on Lost World, which is most attacked using the RL from above due to its vulnerability to splash damage. The rocket launcher itself can however only really be contested having a lightning gun. The position of one weapon influences the role of another, complex dependencies can arise here. Another example, on dm6, the Red Armor on top of the large staircase which is the shortest and quickest connection between MH and RA. The staircase makes a player using it very vulnerable to LG. An out of control player with LG would try to abuse RA and MH coming up at the same time by positionng himself on top of it. A player without LG would act differently, maybe setting up a trap at Shotgun already or positioning himself on the bridge trying to block the choke point doorway at the rocket launcher jumppad.
To close it off, I think it's important to conclude that item setups have to be seen as a whole; depending on other items, geometry of areas and also the connection between them.
This list of "dopamine moments" should ideally become part of the node network because it influences map design greatly.
Not that I don't agree with streamlining and making more efficient the discourse behind mapping, it's just that there is no substitute for genuine and widespread interest in the game and mapping for it - that which we currently lack.
There is also the risk that your attempts to theoreticise the game will reduce it to terms that do not meaningfully or reasonably reflect the game as it is actually played. You can understand the game in terms of likelihoods and approach your design as such, but you cannot predict the actions of some players - and sometimes even most players. That's the beauty of mapping and the risk you take as a game designer. Again I agree with what you're doing here and I think we need to have a theoretical language and more generally ensure the maturation of the discourse of AFPS, but do not presume to create an all-encompassing, all-defining theoretical model.
Regarding the aspect of an all defining model, that's not what I am looking for. This thing is supposed to be continously modified, like a GIT repository. It's not supposed to ever reach the status of being "done".
This is the fun part! I agree that an academic intellectual nature is next to useless for something that is supposed to be used in practice. However, for things to be practical, there needs to be a uniform super accessible presentation. That's where I think a wiki is not the right medium; the dependance on how things are curated will always make it an intellectual challenge.
Unfortunately I can't show off a running status quo as I currently don't have the means to host this. I'll try to get a prototype running in the next 2ish weeks.
I got interested in the subject because it seems like the question of "what makes a good arena map?" should, at the very least, have some convincing answers. I know that it is an NP problem that cannot necessarily be boiled down to a set of instructions, but, in UT, there has to be something (something measurable) underlying maps like Erase or Deck that makes them so good. Especially Erase, in my opinion - it's mind-boggling how good that map is for 1-on-1 duels.
So I've been studying a few maps while I work on my first, just for reference, and trying to approximate certain parts of my map to maps that I consider really good. Initially, I have been looking at the map scale, the item placement, and the sight lines on Erase. Things like, if I grab the shield belt, it takes x seconds for me to have an angle to shoot towards the 100 armor, or the fastest route between the thigh pads and the 100 armor takes x seconds if I maintain the upper ground and y seconds if I drop towards the shock rifle. I need to be writing all this stuff down and looking for correlations between maps - the fact that you've put some language to these thoughts will be a huge help. Can you recommend any good reading on the concept of Pattern Languages that you mentioned in your post?
Anyway, I'm thrilled you're working on this and hope that I can contribute in some way.
Sorry, totally forgot to reply to this. I wrote a small paper on this a while back. You can grab it here: https://www.dropbox.com/s/nt9ghrt18yl2vz9/170331_A_New_Pattern_Interface.pdf?dl=0
(Note that this is in the context of architecture. The concepts should be easy to translate however.)
It is taking shape. Fought my way through simple user auth the past few days. Gonna add support for user projects next. Still trying to get hosting underway.
The presentation includes some of the pre project analysis and thus is a bit lengthy. Bad English and audio are inlcuded in the price.