Source : Forum post by Dragonne From the urt dev team, with permission granted to me to post it here
http://forums.urbanterror.net/index.php/topic,12357.0.htmlhttp://www.urbanterror.info/forums/topic/11164-virtual-multiplayer-team-based-level-design-theory/I wrote this for the benefit of those that want to learn. By no means is it definitive or should you consider this the only way to design a level. It's just how I've found that I've learned over the years to do things, and I finally put my thoughts on paper. It's kinda a generic discussion, but obviously points at UrT. Enjoy.
Virtual Multiplayer Team-based Level Design Theory
By Dragonne
There are many different issues that face a virtual level designer before they even open up their software of choice to begin construction. In most situations, the level designer only really has creative input into their own design in 2 phases of development: initial concept, and details. I say this because ever environment that is designed has to fit within the parameters of the game they are creating the world for, and that the game was not created by the level designer. The designer comes along well into production of the game, and sometimes after the game is essentially complete. You will have to work within the premise of the game, and possibly restricted by many other factors, the technology of the game itself being the base factor but only one of many. Time period, location, in-game technology, and much more come into play. It’s even possible that you may be given the entire level concept and only be left to flesh out the details. With that being said, once you know the limiting factors, you can begin to design the layout for the virtual environment, and we’ve reached the focus of this discussion: designing effective playing environments for team-based multiplayer games.
Level Design is all about creativity. Making something literally out of nothing, but we’re talking about team-based level design. This inherently adds more restrictions to your design than free-for-all or single player progressive mission based (for example DooM3) level design. The pitfall many designers fall into is forgetting to ask themselves a few very important questions before sitting down to their development tools:
1. Is this level going to fit multiple gametypes?
2. How many teams must it accommodate?
3. Are the gametypes being played goal oriented?
4. Does the concept itself define the routes and pathing?
We’ll come back to those questions and how they apply to this discussion in a moment. It’s very simple to sit down with a concept, have a few primary area ideas within that concept, drop in those areas and connect them together. In the end, what does that give you? It gives you a set of connected areas with little reason for them existing the way they do. This leads to dissatisfaction among the eventual players, poor reviews during testing, and often either a complete rework of the level or simply trashing it and starting over with all of your previous effort going to waste. Now, I’m not about to tell you any definitive way to design your level. What I am going to explain is one method that I have realized I use quite frequently as a base for all of my levels. You will slowly come to realize that evidence of similar thought processes can be seen in many multiplayer level designs over the years. What I am doing is putting these techniques that I have learned and observed over the years together into a set of guidelines, and putting them on paper for the benefit of anyone who wishes to learn from my years of experience in both designing and playing in multiplayer environments, both for fun and competition.
So, to start answering those questions for the sake of this discussion, let’s assume that our level is for multiple gametypes (Free-for-All, Capture the Flag, Team Survivor, Team Deathmatch, and a Bomb Diffuse mode), some with specific goals (Capture the Flag) and some without (Team Deathmatch). For simplicity sake, let’s say our level will have 2 teams maximum, and our level concept is of a public, undefined area so no routes or paths are pre-defined. To explain how a concept could pre-define your routes and pathing, if your level is to mimic a real life location that you must (or wish to) stick to as closely as possible for player recognition of that location, then you already have your layout pre-defined and don’t have much room to work with. I do not recommend this kind of rigid inflexibility. How often do you think an architect designs a building/structure/courtyard/etc. with the idea of people running around strategically trying to kill each other while carrying around giant flags as the primary focus of their design? Never. So with this all determined, let’s move on.
My theory for design of a goal oriented level I like to call “Single Path Extentionism”. Yes, it’s a fancy way of saying start with a single route and then add connecting routes to it, but it’s a bit more complicated than that. The basis of the theory is to always loop back to an established path when creating a new path. This inherently keeps the flow of the level moving from place to place. Your paths need not be symmetrical, in fact levels are more interesting when they are not symmetrical, but if you don’t want symmetry in visualization, then you must maintain symmetry in access to areas for all teams involved in the game or the level will be unbalanced.
The first thought you should have is to design for the most complex game type and work backwards from there. In our case, let’s assume CTF (Capture the Flag) is more complicated than the others. So with our basic parameters defined, here we go with starting our design and some visuals:
Fig 1
Here is the most basic design. Team A is Red. Team B is Blue. The green depicts “neutral” space. You have “home” or “base” locations for both teams defined, and a hallway connecting them. Congratulations, you have a level design. The obvious issue being it’s horribly boring and will turn into a gunfight right in the middle every time. For those of you unfamiliar with what this is called, the term is “chokepoint”. Remember this term because I will be using it quite a bit. A “solid chokepoint” is really what we’re looking at here because the space at which the chokepoint occurs is too narrow for one team to even push past the other team. There is only one way to reach the goal points for either team as well, which is simply a bad thing as it makes defense of the goal too easy. Let’s spice the design up a bit, by extending the available routes a little more and opening up that solid chokepoint:
Fig 2
Excellent. So we’ve now extended the pathing to include two more connecting hallways. We’ve easily corrected a few of the basic design flaws from our first diagram. We corrected the solid choke point in the center path and turned it into a more desirable chokepoint that is wide enough for teams to strategically work around, but we’ve also created two new solid choke points. We have allowed three angles of entry to both bases, which is much more desirable. It’s still pretty bland though and presents a new set of problems to players. Think about this. If Team A commits it’s attack forces to the center and leaves minimal defenders behind, choosing the center path, while at the same time Team B does the same and chooses the upper attack path, what will likely happen? Given equal skill teams, the defenses will be overwhelmed and the opposing goal reached by both teams. Now, both teams retreat to their bases, having a 1 in 3 chance of encountering each other on the return run. Either they will and there will be a nice firefight with one side retrieving their own flag and returning for a capture, or they will both safely return to their bases to set up heavy defense and become stuck in a stalemate. Not much strategy there. So, let’s extend things a little farther:
Fig 3
Well, what have we done here? Simply added two “crossover” tunnels. Now that the routes are linked, the capability for increased strategy becomes apparent. I’m not going to dig too far into player and team strategy, but the improvement should be obvious. If the teams now meet in one of those outer routes, they can divert off to another route and continue their attack from a different path instead of getting stuck in a “furball” (a fight to the death). We’ve also begun to establish hallways that are under basic control of each team simply by the nature of the design. The flow of the level is coming together, but still lacks complexity. This would be perfectly fine as-is for a small level with low player counts. Let’s take this farther and explain a bit more about why:
Fig 4
Looking pretty complicated now, isn’t it? What we’re doing is expanding the potential for strategy, removing fixed choke points, and adding in Z-axis game play. Note that there is a common theme to every additional piece being added. No path simply stops in a dead end. This is one of the most significant negative game play factors. Essentially, every hallway returns back to one of our three primary routes that we established in Fig 3. At this point, we have a sufficiently complex level that allows from many different strategies, but it’s designed for CTF only, and we’re still missing something. We need to have locations where the players start (spawn) at the beginning of the game and after dying. Let’s throw those in quickly and discuss:
Fig 5
We’ve added 3 small rooms, behind each base, for spawning. Each room will have individual spawns dispersed within them. Now you may ask, why 3 rooms each? The reason is fairly simple. This alleviates a complaint from players about “spawn camping”. This occurs when a player from the opposing team gets into the spawn area for his or her enemy and eliminates players before they can get going. With separate areas, this tactic is minimized. One player cannot cover several spawn areas. An alternative to this method is having the spawns in a single, large area, but spread around the area sufficiently enough to make it difficult for a single player, or even multiple players, to cover them all. Both methods have been used effectively over the years. Whichever method you use (if you even decide to use one of these methods) should be determined by the premise of the level and your own personal taste.
Now we have to look at our other game types. We have Free-For-All, to consider, but in all honesty, almost any level design without dead ends will work for FFA, so let’s not worry about that game type. Let’s look at Team Deathmatch. Basically, TDM is CTF without the specific goal of stealing and returning the flags. Players respawn when they die, and are in essence hunting to kill the other team. Have a look at Fig 5 again. There’s not a lot missing is there? We don’t need the base areas, but they are perfectly valid areas for fighting. You can place the TDM spawns in the same spawn locations as CTF. Does the game you are designing for allow multiple possible spawn areas for TDM? There are already multiple options for that. The upper and lower rooms can be used as spawn areas as well. The main factor in setting TDM spawns is to give the players direction towards the enemy. Placing spawns at the opposing ends of the level naturally cause the players to move towards each other. So it seems that in building for CTF, we’ve covered TDM as well. How about Team Survivor? This game mode is essentially the same as TDM, except that there is no respawn. Once a player is eliminated, he/she has to wait until all other players on their team, or all players on the opposing team, are eliminated at which point the a new round starts and all players are spawned again. So back to Fig 5 once more. We have the CTF spawn areas, and we have alternate spawn areas. We don’t have any dead ends either. What we do have is significant distance between the CTF spawns, and those areas, while well designed for CTF, allow timid players to retreat far from the enemy instead of looking for strategic engagement of the enemy. If possible in the game you are designing for, you may want to block off the CTF spawn areas for TS and instead use the CTF bases for TS spawns. This would be your choice of course, but it will alleviate some of the stalemates in TS while hunting down that last enemy player. So let’s move on to Bomb Diffuse. Since this mode is similar to CTF in that it has a specific location based goal, we shouldn’t be too far off. Our CTF spawns are fine and we can reuse them. Let’s assume that our Bomb Diffuse mode has 2 locations, a primary and a secondary location that can be bombed. We need to figure out where we would put these two locations. Consider this, If the location is important enough to be bombed, then it’s important enough to be guarded. The guards (our defending team, let’s say Blue, or Team B) will already be on site and at least nearby the locations. So we would have to place the bomb targets closer to the defending team, but be careful, if they are too close and they can easily get dug in, every round will be an ambush and a slaughter for the attacking Red team. This is bad for game play, and quite demoralizing. So, with this in mind:
Fig 6
So, here we’ve added our two Targets. We’ve left our spawns for CTF in place, and if the game allows you can vary the spawns across the 3 rooms each round. What we’ve done is made a primary target in a central location and shifted it just slightly towards the defenders. We’ve also placed our secondary location, but given even more advantage to the defenders for it. With our layout, there are many possible strategies to attack, draw the defenders off, and hit the other target, or vice-versa. It’s dynamic enough and with the extended pathing will keep many rounds fresh with varying tactics.
So now we have our very basic design for a team play based level. Our focus is on flow, with every path leading directly to another path, preventing isolation of any path, and easily allowing for support of multiple gametypes. Obviously, this is a very angular design, and your actual level should never look this plain. The concepts of the design are what are important for you to understand. Multiple spawn locations, several angles of attack on goal areas, no dead ends, variety in pathing, no isolated routes, and though you should have choke points you should never have solid chokepoints where two forces are stuck fighting to the death or retreat.
I hope that this discussion has given you some insight into the method I use to design multiplayer, team play based environments that are fun for non-competition use, and fun and balanced for competition. Go forth, and create!
Here's a link to download the MS Word doc:
http://www.otb-server.de/LevelDesignTheory/LevelDesignTheory.doc
