User:Angry Beaver/Sandbox
I get short breaks and occasional times to work on this at work and school, you'll probably see a lot of tiny updates to this but this is my way of transproting documents under development between work, school, and home. TH wiki syntax gets difficult to read and understand without the preview button :). I'd appricate any advice or suggestions you have go in talk section and that you do not modify or move any content on/from/to this page, its a constant WIP untill it gets moved to another location, then feel free to edit the article. I just wanna keep my sandbox my work page.
This is a personal page on my own namespace. If you have anything to add, questions, comments, or managed to find something I didn't, please post on the talk page instead. Thanks!
Designing a Level
(this section will be the Level Design article once compelte)
Introduction
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. Hammer makes the level it should not make the idea. Theres lots to learn about Hammer, but theres almost as much to learn about why its 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 thoose begining to learn level design is that you start with a .vmf and end with a .bsp. They need textures and models, they need compiling and cubemaps, they need 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 used and how thier 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.
| File Type | Creation | Purpose |
|---|---|---|
| VMF* | Saving in Hammer | The source file for any map, 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 actual image part of a texture |
| 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 |
| PRT | Compiling | Provides information about leafs and thier interaction |
| 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 | Detials 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 |
| VConfig | <Source SDK>/bin | Configures game setups for Hammer |
| GCFScape* | Here | Viewing and extraction of files from a gcf |
| Vmex | Here | Disputed program for decompiling a bsp into a vmf |
* indicates files/programs that should be the most familiar.
While knowing them all is helpfull its not required, its best to learn as you go. Know what the possibilities 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 procede 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 compelte feeling design and expidite the process. Hammer isn't a blind development tool, have an image, a picture, a plan. Its been proven time and time again that without one lots of time will be lost to accomodating changes and altering whats 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 theres 5 main questions Who, What, When, Where, and How? A map needs a Theme, a Storyline, and Key Points before its development can begin. A theme to give it a what and when, a storyline to give it a who and why, and key points to give it a how. Start with a blank piece of paper.
First write down what game the level is for, Counter Strike Source, Day of Defeat, or Sin Episodes? Next write down what the level is. Is it a hostage map, is it a deathmatch arena, or is it point control? Finally write down where and when it is. 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 form the theme, a counter strike hostage map based in a winter Las Veags for example.
Next comes the biggest question of all, why? What is the players motivation and who is the payer? 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 parliment 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 but the more the better. Not having sufficent ideas behind your storyline often leads to weak designs that are no fun or feel fake. With the concept storyline its impossible to go overboard.
Finally comes the key points. Its essential that these are well developed and the previous steps have been finished as they take a lot from the storyline of the level. The key points should be the 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 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's 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. The level plans to advance the story, tell part of whats 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 love intrest. What are 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. Thats 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 solid defined goal or a memorable occurance is the corner stone of good single player level design.
In multiplayer players are competing against each other. The key becomes what they are competing over. Control of hostages, the most kills, or control of the area? Make the game about that object the players are competing for. Always focus it and always keep it in mind. If its simply a competition of skill and wits give the players space to try outwit each other dont make it a race for the biggest gun. Let thier skill be a deciding factor not just location. Consider things like weapon and item placement and objective locations as the keys. If thier placed or implemented poorley players pick up on it an unbalance the game. If thier competing over a location decide it first and then think about things. Mulitplayer keys are what the player is striving for, but the true key is to keep them balanced aginast each other. Balancing the keys is the corner stone of good multiplayer level design.
Its always important to finish developing a conecpt before moving onto development, but its never done untill the map is released, always be thingkign always be revaluting. If somethings not working don't be afraid to change it; however, the happier you are before development starts the less drastic cahnges are and the smoother the design process. Concept is improtant take your time before moving on.
Development
<Making it work> "The term map and level are used almost interchangable, realistically this is not true. A map is one single area that provides an area to play in. A level is one section of the game with a consitant theme. The distiction really only matters in single player, levels can contain maps. In HL2 theres the Ravenholme level, but its not one map it's many. Decide early if the entire level plan will fit in one map. If it wont design an intergrate transitions into it at appropriate times." "; however, you can shoot yourself in the foot. If say and think to much and try and cram it all in and explain it all to the player, give them the backstory for that cut in Gordan's left suit arm, its too much. Instead lay it out as a framework, only reveal things that help or guide the player and the rest of the development. Use notes as a sub plot behind everything. It'll keep the realistic developed feel but won't flood the player with too much information."
Construction
<how to go about creating it>
Evaluation
<now you can see it, is it right? is it FUN?>
Releasing
<getting it ready for everyone else>
Mechanics
<making the map do what you want and how important it is>
Gameplay
<working you map for the game your playing>
Conclusion
<something deep and meaningfull>
Hammer in Depth
(this section will be the Hammer in Depth article once compelte)
Introduction
Now the why has been covered lets get deeper into the how. While all the menus and buttons and functions are well documented its not often clear what tool you'll need. You want a slope, should you carve, vertex manipulate, split, or even use a primitive? All will work but it becomes a trick to know which tools to use where and why.
Conclusion
<something deep and meaningfull>