Custom Map Makers Wiki - User contributions [en-gb]

Layout:Dragonne

2011-11-19T14:26:26Z

Majkifajki: one of the images was wrong

Virtual Multiplayer Team-based Level Design Theory By Dragonne a.k.a. Michael Conger 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:

[[File:Fig1.jpg|center|Fig1.jpg]] 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:

[[File:Fig2.jpg|center|Fig2.jpg]] 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:

[[File:Fig3.jpg|center|Fig3.jpg]] 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:

[[File:Fig4.jpg|center|Fig3.jpg]] 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:

[[File:Fig5.jpg|center|Fig5.jpg]] 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:

[[File:Fig6.jpg|center|Fig6.jpg]] 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!

Main Page

2011-11-19T14:23:06Z

Majkifajki: Added link to Dragonne's article

__NOTOC__
== Introduction ==
Welcome to the '''Custom Map Makers wiki''' - a repository for all information relating to mapping for the popular first person shooter [http://www.urbanterror.info/ Urban Terror].

If you feel you'd like to contribute to this wiki, please email '''john@custommapmakers.org''' for more information.

The wiki is divided into the following sections, each of these contains further sub-topics. You can also search the wiki using the search box on the top.

== Beginning ==
{| cellspacing="5" width="100%"

|
{{RyMainPageBox|radiant.png|[[:Category:Radiant|Radiant]]|
* [[Radiant:MacRadiant|MacRadiant]]
* [[Radiant:ZeroRadiant|ZeroRadiant]]
* [[Radiant:NetRadiant|NetRadiant]]
* [[Radiant:Using|Using Radiant]]
* [[Radiant:Shortcuts_And_Menu_Options|Keyboard shortcuts/menu options]]
|HEIGHT=200px}}

|
{{RyMainPageBox|mapping.png|[[:Category:Mapping|Mapping]]|
* [[Mapping:Brushwork|Brushes]]
* [[Mapping:VIS|VIS]]
* [[Mapping:What is a patch|Patch Meshes]]
* [[:Category:Models|Models]]
* [[Mapping:Sky|Sky]]
* [[Mapping:Terrain|Terrain]]
* [[Compiling:Healthy_Map|Healthy Map]]
|HEIGHT=200px}}

|
{{RyMainPageBox|textures.png|[[:Category:Textures|Textures]]|
* [[Textures:Texturing|Texturing]]
* [[Textures:Shaders|Shaders]]
* [[Textures:Sites|Websites]]
* [[Textures:Formats|Formats]]
* [[Textures:Advanced Normal Maps Creation|Normal Maps]]
|HEIGHT=200px}}

|-

|
{{RyMainPageBox|lighting.png|[[:Category:Lighting|Lighting]]|
* [[Lighting:General|General]]
* [[Lighting:Leaks|Light leaks]]
* [[Lighting:Painting|Annoying FrankieV]]
* [[Lighting:Light Style|Light Style]]
|HEIGHT=176px}}

|
{{RyMainPageBox|entities.png|[[:Category:Entities|Entities]]|
* [[Entities:Func|func_*]]
* [[Entities:Info|info_*]]
* [[Entities:Target|target_*]]
* [[Entities:Trigger|trigger_*]]
* [[Entities:Misc|misc_*]]
* [[Entities:UT|ut_*]]
|HEIGHT=176px}}

|
{{RyMainPageBox|compiling.png|[[:Category:Compiling|Compiling]]|
* [[Compiling:q3map2|q3map2]]
* [[Compiling:Commands|Commands]]
* [[Compiling:Surface sounds|Surface sounds]]
* [[Compiling:Setup|Setup]]
* [[Compiling:Batch Files|Batch Files]]
* [[Compiling:Scripts|Scripts]]
|HEIGHT=176px}}

|}

== Advanced ==

{| cellspacing="5" width="100%"
|-
|
{{RyMainPageBox|packaging.png|[[:Category:Packaging|Packaging]]|
* [[Packaging:Levelshot|Making a levelshot]]
* [[Packaging:Minimap|Making a minimap]]
* [[:Category:Packaging|Packaging]]
|HEIGHT=128px}}

|
{{RyMainPageBox|bots.png|[[:Category:Bots|Bots]]|
* [[Bots:Adding bots to your map|Adding bots]]
* [[Bots:Issues|Issues]]
* [[Bots:Advanced|Advanced topics]]
|HEIGHT=128px}}

|
{{RyMainPageBox|urt_hd.png|[[:Category:UrTHD|Urban Terror HD]]|
* [[UrTHD:Setup|Setup]]
* [[UrTHD:Tools]]
* [[UrTHD:Mapping|Mapping]]
|HEIGHT=128px}}

|
{{RyMainPageBox|layout.png|[[:Category:Layout|Layout]]|
* [[Layout:Level Design|Level design]]
* [[Layout:Bens Bible|Ben's small bible]]
* [[Layout:Dragonne|Dragonne's article]]
|HEIGHT=128px}}

|}

== Further reading ==
{| cellspacing="5" width="100%"

|
{{RyMainPageBox|modelling.png|[[:Category:Models|Modelling]]|
* [[Models:Programs|Programs]]
* [[Models:Exporting|Exporting]]
* [[Models:Texturing|Texturing]]
* [[Models:Resources|Resources]]
|HEIGHT=176px}}

|
{{RyMainPageBox|resources.png|[[:Category:Resources|Resources]]|
* [[Resources:Tips|Tips and tricks]]
* [[:Category:Inspiration|Inspiration]]
* [[Resources:Tools|Tools]]
* [[Resources:Links|Links]]
* [[Sound:Websites|Sound websites]]
* [[IRC|CMM IRC Channel]]
|HEIGHT=176px}}

|
{{RyMainPageBox|funstuff.png|[[:Category:Funstuff|Funstuff]]|
* [[Funstuff:Creating|Creating]]
|HEIGHT=176px}}

|
{{RyMainPageBox|xreal.png|[[:Category:XreaL|XreaL]]|
* [[XreaL:About|About]]
* [[XreaL:Setup|Setup]]
* [[XreaL:Games|Games]]
|HEIGHT=176px}}
|}

Layout:Dragonne

2011-11-19T14:20:23Z

Majkifajki: This is Dragonne's article about layout. Thought it is a good thing to preserve it.

Virtual Multiplayer Team-based Level Design Theory By Dragonne a.k.a. Michael Conger 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:

[[File:Fig1.jpg|center|Fig1.jpg]] 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:

[[File:Fig2.jpg|center|Fig2.jpg]] 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:

[[File:Fig3.jpg|center|Fig3.jpg]] 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:

[[File:Fig3.jpg|center|Fig3.jpg]] 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:

[[File:Fig5.jpg|center|Fig5.jpg]] 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:

[[File:Fig6.jpg|center|Fig6.jpg]] 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!

File:Fig5.jpg

2011-11-19T14:18:08Z

Majkifajki: Part of Dragonee's article

Part of Dragonee's article

File:Fig6.jpg

2011-11-19T14:14:41Z

Majkifajki: Part of Dragonee's article

Part of Dragonee's article

File:Fig4.jpg

2011-11-19T14:14:28Z

Majkifajki: Part of Dragonee's article

Part of Dragonee's article

File:Fig3.jpg

2011-11-19T14:14:15Z

Majkifajki: Part of Dragonee's article

Part of Dragonee's article

File:Fig2.jpg

2011-11-19T14:14:02Z

Majkifajki: Part of Dragonee's article

Part of Dragonee's article

File:Fig1.jpg

2011-11-19T14:11:31Z

Majkifajki: Part of Dragonne's tutorial

Part of Dragonne's tutorial

Textures:Sites

2011-10-29T16:35:27Z

Majkifajki: added Burning Well

Here is a list of websites that contain textures you can use in your maps or models.

Please note that you mostly need to credit the authors, please make sure to check the license first.

If you have any suggestions for additional texture sites, please post on the [http://www.custommapmakers.org/viewforum.php?f=19 Custom map makers forum].

* [http://www.spiralgraphics.biz/packs genetica]
* [http://paulbourke.net/texture_colour Paul Bourke textures]
* [http://www.lughertexture.com/index.php Lugher textures]
* [http://webtreats.mysitemyway.com Webtreats]
* [http://www.fatstrawberry.com/content/vintage_2.shtml The Fat Strawberry]
* [http://cgtextures.com CG textures] [[Image:check_box.png]] '''Tip!'''
* [http://www.rendertextures.com Render textures]
* [http://www.deviantart.com deviantArt]
* [http://www.openfootage.net OpenFootage] [[Image:check_box.png]] '''Tip!'''
* [http://www.imageafter.com/ Image After]
* [http://www.mayang.com/textures Mayang]
* [http://tellim.com/texture_cd/html/menu1.html Tellim]
* [http://wombat.worldforge.org/ WorldForge asset repository]
* [http://www.davegh.com/vg/home.htm Davegh]
*[http://www.bildburg.de/texturen/index.html Bildburg: (german)]
*[http://www.texturecase.com Texturecase]
*[http://www.ulf-theis.de/tutorials/texturen/metall Ulf Theis]
*[http://www.mb3d.co.uk/mb3d/maxTextures_Home_-_Free_Seamless_and_Tileable_High_Res_Textures.html maxTextures]
*[http://textures.forrest.cz/ Forrest textures]
*[http://www.goodtextures.com Good Textures]
*[http://www.sharecg.com/b/6/Textures ShareCG]
*[http://www.terminal26.de/e_index.php Terminal 26 Game textures]
*[http://www.magnet-textures.com/en Magnet-textures]
*[http://www.burningwell.org Burning Well]

==Mirrored at Custom Map Makers==
We've managed to collect a few texture packs from around the internet before they're lost.

*[http://www.custommapmakers.org/storage/resources/keres4.rar Keres Pack 4]
*[http://www.custommapmakers.org/storage/resources/keres3.rar Keres Pack 3]

*[http://www.custommapmakers.org/storage/resources/azlcmb1/azlcmb1_texture1.zip JohnnyEnglish texture pack (170 textures)]

*[http://www.custommapmakers.org/storage/resources/ILB_texPak01.zip ILB_texPak01 specially for video games]
*[http://www.custommapmakers.org/storage/resources/ILB_texPak02.zip ILB_texPak02 specially for video games part 2]

==q3 Custom texture packs==
Older texture packs stored here at CMM

*[http://www.custommapmakers.org/storage/resources/q3/arctic.pk3 Arctic]
*[http://www.custommapmakers.org/storage/resources/q3/dsitextures.pk3 dsitextures]
*[http://www.custommapmakers.org/storage/resources/q3/e6.pk3 e6]
*[http://www.custommapmakers.org/storage/resources/q3/e7.pk3 e7]
*[http://www.custommapmakers.org/storage/resources/q3/e8.pk3 e8]
*[http://www.custommapmakers.org/storage/resources/q3/ecel_textures.pk3 ecel_textures]
*[http://www.custommapmakers.org/storage/resources/q3/evil4.pk3 evil4]
*[http://www.custommapmakers.org/storage/resources/q3/kilt_texpack02.pk3 kilt_texpack02]
*[http://www.custommapmakers.org/storage/resources/q3/kilt_texpak01.pk3 kilt_texpack01]
*[http://www.custommapmakers.org/storage/resources/q3/mrcleantex_1.pk3 mrcleantex_1]
*[http://www.custommapmakers.org/storage/resources/q3/mrcleantex_2.pk3 mrcleantex_2]
*[http://www.custommapmakers.org/storage/resources/q3/mrcleantex_3.pk3 mrcleantex_3]
*[http://www.custommapmakers.org/storage/resources/q3/mrcleantex_4.pk3 mrcleantex_4]
*[http://www.custommapmakers.org/storage/resources/q3/multiplant_v2.pk3 multiplant_v2]
*[http://www.custommapmakers.org/storage/resources/q3/q3evil1.pk3 q3evil1]
*[http://www.custommapmakers.org/storage/resources/q3/q3evil2.pk3 q3evil2]
*[http://www.custommapmakers.org/storage/resources/q3/q3evil5.pk3 q3evil5]
*[http://www.custommapmakers.org/storage/resources/q3/p-egypt0tga.pk3 p-egypt0tga]
*[http://www.custommapmakers.org/storage/resources/q3/tp-tech10tga.pk3 tp-tech10tga]

[[Category:Textures]]

Category:Inspiration

2011-10-17T00:54:28Z

Majkifajki: added afterthefinalcurtain.net

== Trainstations ==
* [[Inspiration:TrainstationRylius|Darmstadt]]

== Industry ==
* [[Inspiration:EvonikRylius|Evonik, Darmstadt]]
* [[Inspiration:WasteIncinerationRylius|Waste incineration plant, Darmstadt]]
* [[Inspiration:IndustrialRylius|Misc images, Darmstadt]]
* [[Inspiration:PaperFactoryRylius|Paper factory, Mühltal]]

== Military ==
* http://englishrussia.com/2011/05/16/ghost-military-base/
* http://www.spacerywirtualne.pl/spacery-wirtualne/miedzyrzecz.html
* http://www.devicemag.com/2010/04/29/abandoned-technology-scattered-across-the-globe/

== Cities ==
=== Ohio ===
* http://blog.defgrip.net/2011/05/photogallery-the-snake-pit/
=== Darmstadt ===
* [[Inspiration:DarmstadtRylius|Day]]
* [[Inspiration:DarmstadtNightRylius|Night]]

== Abandoned ==
=== Hospitals ===
http://qbanez.wordpress.com/2011/08/25/278-beelitz/

== Churches ==
* http://qbanez.wordpress.com/2011/08/09/266-kosciol-w-zeliszowie/

== Theaters ==
http://afterthefinalcurtain.net/

Hinting NuIL method

2011-09-30T13:04:52Z

Majkifajki: Created page

''The blue lines in these shots show the points that the hint brushes touch on the walls. These would be the points I would place the clipper points, then just slice the hint plane out of a big brush.''

1. Place a hint face against the structural side of the building marked with blue; extend the hint to the next structural wall to the far left and right. This will stop anyone who's standing on the paved part of the alleyway having to render the fenced off area (red ctf spawn) or anything outside thats further back.

[[File:Tp hint3.jpg|thumb|center|700px|Tp hint3.jpg]]

----

2. Run a hint face through the corners marked in blue and extent to the warehouse on the left and to the next structural wall on the right. This will stop anyone standing by the pillars having to render anything past the left hand side of the hint plane in the fenced off area.

[[File:Tp hint4.jpg|thumb|center|700px]]

----

3. Similar to the previous. Run a hint from the corner of the building in the bottom-right of the picture, past the corner of the office building and to a structural wall at the far side of the supply yard. Has a similar affect as the previous but is tighter and so causes more culling.

[[File:Tp hint5.jpg|thumb|center|700px|Tp hint5.jpg]]

----

4. Run a hint from the lift, use the corner I've highlighted, along side the sticky-out-bit and to the other side of the office. This will stop anyone standing by the desks from rendering any further than the side of the lift.

[[File:Tp hint6.jpg|thumb|center|700px]]

----

5. Run a hint from the outer edge of the door frame past the right side of the archway, and to the structural wall. This stops anyone standing by the desks from rendering the alley way with the pillars.

[[File:Tp hint7.jpg|thumb|center|700px|Tp hint7.jpg]]

----

6. Run a hint along the face of the building marked with blue, and extend from the fence to the structural hull at the far side of the map. This stops anyone standing by the blue flag spot rendering the red spawn or the paved section near the pillars.

[[File:Tp hint8.jpg|thumb|center|700px|Tp hint8.jpg]]

----

7. Have a hint touch the structural corners of the two buildings marked with blue lines; extend the hint to the fence on the left and to the large doorway on the right. This stops anyone in the red spawn/on the street near the zebra crossings from rendering the garden area.

[[File:Tp hint9.jpg|thumb|center|700px|Tp hint9.jpg]]

----

8. This ones just being picky. Have a hint touch the sides of the archways marked and extend it to the outer building wall and to the toilets. Anyone hiding by the toilets doesn't render much at all.

[[File:Tp hint10.jpg|thumb|center|700px|Tp hint10.jpg]]

----

The hint face needs to touch the corners of the walls I've marked out with blue lines; the hint should extend to the outer walls of the building in either direction. This hint stops anyone whose standing by the door in the lower right of the image from rendering anything by the wooden frame/toilets in the center of the image nor the office area; and vice-versa, hints work both ways. It also stops anyone standing by the door just above the centre of the image from rendering anything lower down, including the bin area and door in the lower right.

[[File:Tp hint2.jpg|thumb|center|700px|Tp hint2.jpg]] Have fun, NulL

Original post was written by Rayne on old CMM Site.

File:Tp hint3.jpg

2011-09-30T12:36:23Z