View source for Creating a Level

[[Category:Theory]]
==Introduction==
{{Int lvl design}}
Level design begins deep where that first spark of inspiration comes from. It has many forms to take with a lot of work to be done before, during, and after [[Hammer]] has been loaded. Hammer is a tool for level design. It allows the creation, design, and building of entire levels for the player to explore; thus, a deeper understanding of the level design process would allow the use of Hammer in the most effective way. It's important to remember Hammer makes the level; it should not make the idea. There's a lot to learn about Hammer, but there's almost as much to learn about why it's used and the process using it takes, what other programs help, and where Hammer sits in the level design process.

==Whats Involved==
Levels are not self contained entities. The common misconception of those beginning to learn level design is that one starts with a .vmf and ends with a .bsp. Levels need textures and models; they need compiling and cubemaps; they need lots and lots of things. Making a level does not require one file and will never leave just one file. The following is a rundown of exactly what files and programs are used and how they're important. Some are optional; others only appear when an error occurs. A full explanation is avalible through the link. The tables below only summarize the information.

{|
! Extension || Creation || Purpose
|-
| [[VMF]]* || Saving in Hammer || The source file for any map; it contains all brushes entities and properties
|-
| [[VMX]] || Saving in Hammer  || A backup version of the .vmf should anything go wrong with the original
|-
| [[GCF]]* || Offical Release || Contains all original content for the game
|-
| [[FGD]]* || Released with game/mod || Hammer's reference guide of all the properties of entities and how to use them
|-
| [[MDL]] || Released with game/mod || A 3D model that can be placed inside of the level
|-
| [[VMT]] || Released with game/mod || The properties and name of a texture used in the level
|-
| [[VTF]] || Released with game/mod || The image part of a texture, referenced by vmt
|-
| [[BSP]]* || Compiling || The version of the map that can be run in game
|-
| [[AIN]] || Compiling || All movement information and hints for [[NPC|NPCs]] in the map
|-
| LOG || Compiling || The entire compile log of all the compilers run on the vmf in txt format
|-
| [[PRT]] || Compiling || Provides information about [[Visleaf|leafs]] and thier interactions
|-
| [[PTS]]* || Compiling with errors || A helpful guide for finding [[Leak|leaks]]
|-
| [[NAV]] || In game parameter || All movement information and hints for [[Bot|Bots]] in the map
|-
| [[CFG]] || Released with program || Information used to configure a program's options
|-
| [[VCD]] || [[FacePoser]] || All NPC interaction and sounds for one scene, as defined by faceposer
|-
| [[RES]] || Manually || Lists all custom resources used inside the level
|}


{|
! Program Name || Where || Purpose
|-
| [[Hammer]]* || <Source SDK>/bin || To edit and create maps
|-
| [[Vbsp]]* || <Source SDK>/bin || Compiles physical spaces and entity properties
|-
| [[Vvis]]* || <Source SDK>/bin || Compiles all calculations for visiblitiy
|-
| [[Vrad]]* || <Source SDK>/bin || Compiles and applies lighting effects
|-
| [[Glview]] || <Source SDK>/bin || Viewing the informationn in prt files
|-
| [[Game Directory#Using VConfig to set the game directory|VConfig]] || <Source SDK>/bin || Configures game setups for Hammer
|-
| [[GCFScape]]* || [http://nemesis.thewavelength.net/index.php?p=26 Online] || Viewing and extraction of files from a gcf
|-
| [[Vmex]] || [http://www.geocities.com/cofrdrbob/vmex.html Online] || [[Decompiling Maps|Disputed]] program for decompiling a bsp into a vmf
|}

''* indicates files/programs that should be the most familiar.''

While knowing them all is helpful, it's not required. It's best to learn as you go. Know what possibilities there are; then find out how to use them when the need for them arises.

==Start to Finish==
Taking a level from start to finish is a difficult process and is often the hardest thing to do. Developing a working level requires a breakdown of steps to consider and proceed through. The key, though, is not forgetting to consider what decisions are going to have to be made and what decisions have been made earlier. Flowing from one stage to the next will ensure a complete feeling design and expedite the process. Hammer isn't a blind development tool. Have an image, a picture, a plan. It's been proven time and time again that without a plan lots of time will be lost to accomodating changes and altering what's already been made. Start with a pencil and paper and work all the way up to final product. Images on the right correspond to an example of the process being followed.

{{todo|the images I just referenced}}


===Concept=== 
Whenever something comes about there're 5 main questions: Who, What, When, Where, and How? A map needs a Theme, a Storyline, and some Key Points before its development can begin. A theme gives it a what and when; a storyline gives it a who and why;  the key points give it a how. Start with a blank piece of paper and a pencil.

First write down what game the level is for: [[Counter-Strike: Source]], [[Day of Defeat]], or [[Sin Episodes]]? Next write down what type of level it is to be. Is it a hostage map, is it a deathmatch arena, or is it point control? Finally write down where and when it takes place. Is it in Iraq now, is it on the moon in the future, or is it a bunker being stormed by nazis in 1983? These three concepts form the theme - a counter strike hostage map during winter in Las Vegas, for example. The theme is the most basic requirement.

Next comes the biggest question of all: why? What is the player's motivation and who is the player? What is the storyline of this level? Is Gordon Freeman still fighting for freedom from opression, is your SWAT team's mission to defuse the bomb under Parliament before it explodes, or are you a fighting machine exsisting just to kill everything moving around you? Storyline can take as much space as needed and the more the better. Not having sufficent ideas behind the storyline often leads to weak designs that are no fun or feel fake. With the concept storyline it's impossible to go overboard. Write down all the details, all the plans, and all the ideas that are driving this concept or that seem relevant to its design.

Finally come the key points. It's essential that these are well developed and also that the previous steps have been finished as the keys take a lot from the storyline of the level. The key points should be the reason the player is on the map, the things the player walks away from the game and uses to describe the level to everyone else. The key points are, simply put, "the point of the level." Guides for each game are the best places to learn how to develop its key points, but as a general overview here're some tips.

In single player there is a storyline. One player is facing a story and every step he takes he discovers something about it. Develop the level's plans to advance the story, to tell part of what's going on. Define what the major plot points are that this level is supposed to develop: finding the secret lair, defeating the biggest boss, and/or killing off the main character's love intrest. Decide the things in the level that advance the storyline. It should be short; it should be concise; and it should be burned into your mind while you develop the level. For example: "This is the one where Blake looses his eyesight." It doesn't matter that it was in a stalemate war between street gangs where the battle rolled between cover as a hail storm fell. No. That's storyline material. It's the level where "Blake looses his eyesight," nothing more, nothing less. Never forget the reason behind the level and never overcomplicate it. A solidly defined goal or a memorable occurance is the corner stone of good single player level design.

In multiplayer the players are competing against each other. The key becomes what they are competing over. Is it control of hostages, the most kills, or control of the area? Make the game about the object(s) the players are competing for. Always focus on that and always keep it in mind. If it's simply a competition of skill and wits, give the players space to try to outwit each other. Don't make it a race for the biggest gun. Let their skill be a deciding factor, not just location. Consider things like weapon and item placement and objective locations as the keys. If they're placed or implemented poorly, players pick up on it and unbalance the game. If they're competing over a location, decide where it is first; then think about things that link to it. Multiplayer keys are what the player is striving for, but the true key is to keep them balanced against each other. Balancing the keys is the cornerstone of good multiplayer level design.

It's always important to finish creating a concept before moving on to development. But a concept is never done until the level is released. Always be thinking; always be re-evaluting. If something isn't working, don't be afraid to change it; however, the more work applied before development starts, the less drastic changes are and the smoother the design process. Concept is important. Take time to create it fully before moving on.

===Development===
Development is in some ways a bridge between concept and construction. Concept is the idea and construction is its creation; however, there needs to be an idea about how it's going to be built, the blueprints, if you will. That's development. Development picks and chooses aspects of the concept. It then considers how to implement them and how they interact. The first step comes back to the keys decided on earlier. As the purpose of the level, they need to be the first developed idea. Pick aspects of the storyline that correspond to the keys. Decide how to present it all and how it's going to work. If you're artistically inclined, concept sketches are an excellent idea at this point. Slowly build the map outwards from the key points; link them together and the flesh out the details. Pull on the storyline created earlier as the source for details and information. Sit and plan how every aspect of the level interacts with the others. While the planning proceeds, the technical aspects begin to creep into the development. There's a need for a power core, so how is it implemented? Will there be a need for a custom model or will brushwork and particle effects be enough? Decisions need to be made about how to implement parts of the design. Creating simple test maps "to get a swinging blade working, etc." should probably occur now along with reasearch for guides to similar effects. If the ability to implement or the cost of implementing an effect is not determined early it can cause issues covered later in this series.

While developed rooms and ideas are vital, bringing it all together into one single creation is even more vital. Use a simple block diagram to think ahead and plan out the rooms and their interconnectivity. Decide the layout of the level and shift objects around accodingly. Look at how the player will move through it. Is it efficient? Can he take the wrong route? If so, how would that be prevented? Designing flow for the map requires a deep understanding of the mechanics of the game. How the players move through the level is the key factor to determining its success. A more in-depth discussion can be found in the [[Level Flow]] article. A key thing to remember is that the terms ''map'' and ''level'' are used almost interchangably. Realistically, this is not true. A map is a single area of gameplay. A level is a section of the game with a consistent theme. The distinction really only matters in single player; levels can contain maps. In HL2, for example, there's the [[Ravenholm]] level; but its not one map, it's many. Decide early if the entire level plan will fit in one map. If it won't then design and integrate [[Level Transitions]] into it at appropriate times. Timing them is a key aspect of designing the flow for the level.

Put all the work, effort, and detail possible into the level; however, you can shoot yourself in the foot. If the concept is too broad and it's all being crammed in and explained to the player, it get's to be too much. If they get the backstory for that cut in Gordan's suit's left arm, its too much. If they learn Gordon has been fighting recently, its good. The distinction is not how much storyline you've developed, but simply how much the player needed to know. Though they both explain the cut and add depth, the latter is more appealing to a player. Instead of telling the player everything, lay it out as a framework; reveal only those things that help or guide the player and the rest of the development. Use notes and the concept as a sub-plot behind everything. It'll keep the realistic developed feel but won't flood the player with too much information.

===Construction===
Now the blueprints are made its time to begin construction. This is where Hammer begins to shine, while possibly used for test maps before now it is solely responsible for bringing together all your development and giving a realistic feel to it all. The rest of the tutorials are actually about construction, so this section would link everything again or be the size of the Level Design category; therefore, all the text truly needed here is to say start building and keep in mind everything decided in concept and development as the work procedes.

===Evaluation===
Now that the level has been constructed there comes the ever tourturing question "Is it good enough?". Developers generally fall into two breeds, thoose so happy with thier work and the fact they have achieved it that they overlook obvious flaws and thier work suffers because of it, the opposite are thoose so caught up on perfection and their own mistakes they spend weeks aligning textures and again the work suffers. Both behaviours are very counterproductive; however, the healthy attitude to take is a balance between them. Be willing to overlook slight errors and let tiny mistakes slide, experience shows very few players actually notice them, additonally make sure it consitantly and reliably does what it is supposed to. If it's a fun balanced place to play then balance the gameplay, if its to present a storyline then ensure the player can't skip it and feels involved. This is the stage of consistant and never ending playtesting, its guarenteed that there will be something that needs fixing or tweaking, there will be a long period where you bounce between construction, development, and evalution. When it finaly comes time to play the single player fight that was scripted so perfectly it may become horrifically apparent it sucks. Such is level design, rely on your judgement and also that of your peers, its very easy to develop a one sided opinion. Often taking a step back from the project and doing no work on it then comming back fresh helps a lot. Another good tactic is to employ Beta testers to help you gain perspective and test the level, it is such a good tactic that there is a [[Testers|resource]] on the VDC for that reason. The only time the evaluation step is left is when you are happy with the product, you feel its good enough to finally be released.

===Releasing===
Depending upon the scope of what is being released the process can change drastically. Releasing a mod is exponentially more work than a map pack which is still more work than a single level. At its base it's collecting only the neccesary files, combining them into an easy to distribute package and then obtaining a location to host them at. Often the biggest issues come with obtaining only the neccesary files and combining them into an easy to distribute package. Hosts are generally avalibe if looking in the right places. A comprehesive guide upon how to release a map to the public and resources to do so can be found in the [[Releasing a Map]] tutorial.

==Mechanics and Gameplay==
While mentioned throughout the Start to Finish guide this is a more comprehensive look at establishing game mechanics. The underbelly of getting the level to play properly. This is a guide of weighing benefits and disadvantages of implementing certain features and some advice on the best way to approach the decisions. Gameplay is 9/10 why a user is playing the game. Occasioanlly its for the storyline or the artwork but the average player wants to enjoy playing the game. While simply stated its the most challenging aspect of level design and the one it is most responsible for. A good level gives the player the ability to use anything at his disposal to complete the required objective, it challenges the player by getting him to figure how to use the avalible resources, or in a multiplayer situation it pits players against each other. In a standard FPS the player has to figure out which weapons to use and how to move between cover, which hallway to attack from and wheter to deal with the biggest enemies first or the closest. As such what weapons a player has, what enemies he meets where, and what the environment is likely to pretty much define the play experience.

Sometimes the key point for a level is not its only purpose, its neccesary to have levels where the player ends up being familiarized with a weapon, an enemy, or an environmental factor. Giving a player an experience and giving him time to become familar with it is almost constantly happening in Half Life 2. For example, levels like [[Point Insertion]] introduce the combine and thier technology so the player becomes familar with them, levels like [[Ravenholm]] introduce the gravity gun and the zombie variants, [[Route Kanal]] introduces vehicles and physics puzzels. Give the player something to do with that they have, allow them to eperiment see what effects what and how to do interesting things, introduce them to things before it becomes a life or death situation based on thier understanding of it. Show the player ways to interact and what they can't interact with, let the player jump around figure out movement, the coolest weapon in the game may go un-noticed because the level never allowed the player a good opportunity to use it. If the player never gets this opportunity the game feels difficult and incositent, everything feels like its coming out of left field. An example of good practice can be found with the antlions between Half Life 2 and [[Half-Life 2: Episode 1|Episode 1]]; the player is first introduced to antlions burrowing up from the ground in [[Highway 17]], next the player is shown that antlions can't burrow through concrete and other materials but holes can be made for them to get through in [[Nova Prospekt]], then in episdoe one the player is introduced to the idea of blocking off a hole by moving heavy objects on top, then later the player is challenged to find the heavy objects in a parking garage to advance, all this finally leads up to a fight with an antlion guard and combine forces with antlions constantly ariving. The antlions are burrowing up up from holes in the pavement. If the player had not been introduced to the the burrowing or the holes the would of assumed they flew in or never looked for the hole, without the idea of moving a heavy object on top the player wouldn't of know to look for them or that it could be done. Lacking any of this knowledge would of made the fight infintley more difficult and frustrating, by gradualy introducing components you can challenege the player by building on them later. Teaching the player how to play the game is done by the slow introduction of componenets and then letting the player peice it all together. A golden rule is that the player should always feel its thier fualt they died, if things aren't obvious enoguh due to poor placement or lack of experience the player gets angry at the game not his own failing.

When planning on implementing a feature it is essential to know how much its going to cost, not moniteraly, more in terms of time, effort, and frames per second. If theres a plan for the citadel to be in the map, implement the citadel and see how much it effects the speed of the map, use [[+showbudget]] to show the changes it makes. Weigh how import the effect is to the gameplay as comapred to the cost it incurs. This can apply to more than just graphics, is the media presentation of the storyline too long? Does it sacrifice the pace of action in the game or is the pause brief enough for breath and that the player can feel like he never got stopped and still long enough to give the storyline. Weigh the consequences of including it versus the consequences of exluding it, judge each interaction and object on its own merits starting with the most important and visible objects first and working your way down. Maybe instead of scrapping the idea it can be shifted or tweaked, that great reactor effect could eat fps, so move it somewhere where it cannot be seen from long distances and reduces the likeyhood it wont get rendered when its not needed.

==Conclusion==
This guide although introduced first will probably be the last to be used by the begining level designer. It takes a while of half finished ideas and incomplete projects before anyone becomes settled enough to design a level properly from scratch. The reason it's still intorduced first is that it should be the first thing on your mind whenever planning a level and is extremley helpfull to obtaining your own goals as a level designer.