What Is The Problem?

Approaching The Problem

My Proposal

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

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. 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 couldpredict. 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'.Now? 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(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 playersthe 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.!? 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 canbe 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.