Creating a Level

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.

What's 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 available 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*	Official 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 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 leafs and their interactions
PTS*	Compiling with errors	A helpful guide for finding leaks
NAV	In game parameter	All movement information and hints for 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 visibility
Vrad*	<Source SDK>/bin	Compiles and applies lighting effects
Glview	<Source SDK>/bin	Viewing the information in prt files
VConfig	<Source SDK>/bin	Configures game setups for Hammer
GCFScape*	Online	Viewing and extraction of files from a gcf
Vmex	Online	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.

Literally one major thing to learn is all the information you have just read. Knowing how the engine works is one of the best things, not only will it help you in the mapping process but it will also allow you to produce better maps.

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 accommodating 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.

Concept

Whenever something comes about there are 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 oppression, is your SWAT team's mission to defuse the bomb under Parliament before it explodes, or are you a fighting machine existing just to kill everything moving around you? Storyline can take as much space as needed and the more the better. Not having sufficient 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 are 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 interest. 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 over complicate it. A solidly defined goal or a memorable occurrence 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-evaluating. 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 research 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 accordingly. 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 interchangeably. 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 gets to be too much. If they get the back story 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 proceeds.

Evaluation

Now that the level has been constructed there comes the ever torturing question "Is it good enough?". Developers generally fall into two breeds, those so happy with their work and the fact they have achieved it that they overlook obvious flaws and their work suffers because of it, the opposite are those so caught up on perfection and their own mistakes they spend weeks aligning textures and again the work suffers. Both behaviors 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, additionally make sure it consistently 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 consistent and never ending playtesting, its guaranteed that there will be something that needs fixing or tweaking, there will be a long period where you bounce between construction, development, and evaluation. When it finally 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 judgment 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 coming 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 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 necessary 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 necessary files and combining them into an easy to distribute package. Hosts are generally available if looking in the right places. A comprehensive 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. Occasionally 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 available 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 whether 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 necessary 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 familiar with it is almost constantly happening in Half-Life 2. For example, levels like Point Insertion introduce the combine and their technology so the player becomes familiar with them, levels like Ravenholm introduce the gravity gun and the zombie variants, Route Kanal introduces vehicles and physics puzzles. Give the player something to do with that they have, allow them to experiment see what effects what and how to do interesting things, introduce them to things before it becomes a life or death situation based on their 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 unnoticed 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 inconsistent, 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 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 episode 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 arriving. 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 infinitely more difficult and frustrating, by gradually introducing components you can challenge the player by building on them later. Teaching the player how to play the game is done by the slow introduction of components and then letting the player piece it all together. A golden rule is that the player should always feel its their fault they died, if things aren't obvious enough 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 monetarily, more in terms of time, effort, and frames per second. If there is 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 compared 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 excluding 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 likelihood it wont get rendered when its not needed.

Conclusion

This guide, although introduced first, will probably be the last to be used by the beginning level designer. It takes some half finished ideas and incomplete projects before anyone becomes settled enough to design a level properly from scratch. The reason it is still introduced first is that it should be the first thing on your mind whenever planning a level, and it is extremely helpful in obtaining your own goals as a level designer.

See also

• Designing a Level (Alternative Tutorial)