The language of arena FPS level design
This is an archived post originally published on plusforward in 2017.
Post contents
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) §
Unsorted
- 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
On 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
On 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