User:Angry Beaver/Sandbox: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
mNo edit summary
m (breakpoint)
Line 1: Line 1:
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 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. TBH 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.
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.




{{Namespace}}
{{Namespace}}


=Designing a Level=
=Designing a Level=
Line 11: Line 12:


==Introduction==
==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.
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. Its important to remember 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==
==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.
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. 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.


{|
{|
Line 31: Line 32:
| [[VMT]] || Released with game/mod || The properties and name of a texture used in 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
| [[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
| [[BSP]]* || Compiling || The version of the map that can be run in game
Line 39: Line 40:
| [[LOG]] || Compiling || The entire compile log of all the compilers run on the vmf
| [[LOG]] || Compiling || The entire compile log of all the compilers run on the vmf
|-
|-
| [[PRT]] || Compiling || Provides information about [[Visleaf|leafs]] and thier interaction
| [[PRT]] || Compiling || Provides information about [[Visleaf|leafs]] and thier interactions
|-
|-
| [[PTS]]* || Compiling with errors || A helpful guide for finding [[Leak|leaks]]
| [[PTS]]* || Compiling with errors || A helpful guide for finding [[Leak|leaks]]
Line 49: Line 50:
| [[VCD]] || [[FacePoser]] || All NPC interaction and sounds for one scene, as defined by faceposer
| [[VCD]] || [[FacePoser]] || All NPC interaction and sounds for one scene, as defined by faceposer
|-
|-
| [[RES]] || Manually || Detials all custom resources used inside the level
| [[RES]] || Manually || Lists all custom resources used inside the level
|}
|}


Line 84: Line 85:


===Concept===  
===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.
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 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 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.
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.
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 and 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. Write down all the detials, all the plans, and all the ideas that are driving this concept or that seem relevant to its design.


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.
Finally comes the key points. Its 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 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 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.
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 that link to it. 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.
Its always important to finish creating a conecpt before moving onto development, but a concept is never done untill the level is released, always be thinking always be re-evaluting. If something is not 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 improtant take time to create it fully before moving on.


===Development===
===Development===
<Making it work>
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 its going to be built, and thats 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 decide earlier. As the purpose of the level they need to be the first developed idea. Pick aspects of the storyline that corespond to the key. Decide how to present it all and how its going to work. If artistically inclied concept sketches are an excellent idea. Slowly build the map outwards from the key points, link them together and the flesh out the details. Pull on the storyline created eariler as the source for detials and information. Sit and plan how every aspect of the level interacts with the others.
"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."
 
"While planning technical aspects begin to creep into the development. Theres a need for a power core so how is it implemented. Are you going to need a custom model or will brushwork and particle effects be enough. Desicions need to be made about how to implement parts of the design. Creating simple test maps to get a swinging blade working should probably occur now"
 
"The term map and level are used almost interchangable, realistically this is not true. A map is one single area that provides a place 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 [[Ravenholm]] 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."
"; 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."



Revision as of 14:32, 12 November 2006

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. TBH 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)

Template:Int lvl design

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. Its important to remember 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. 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.

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 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
PRT Compiling Provides information about leafs and thier 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 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.

Todo: the images I just referenced


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 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 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 and 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. Write down all the detials, all the plans, and all the ideas that are driving this concept or that seem relevant to its design.

Finally comes the key points. Its 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 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 that link to it. 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 creating a conecpt before moving onto development, but a concept is never done untill the level is released, always be thinking always be re-evaluting. If something is not 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 improtant 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 its going to be built, and thats 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 decide earlier. As the purpose of the level they need to be the first developed idea. Pick aspects of the storyline that corespond to the key. Decide how to present it all and how its going to work. If artistically inclied concept sketches are an excellent idea. Slowly build the map outwards from the key points, link them together and the flesh out the details. Pull on the storyline created eariler as the source for detials and information. Sit and plan how every aspect of the level interacts with the others.

"While planning technical aspects begin to creep into the development. Theres a need for a power core so how is it implemented. Are you going to need a custom model or will brushwork and particle effects be enough. Desicions need to be made about how to implement parts of the design. Creating simple test maps to get a swinging blade working should probably occur now"

"The term map and level are used almost interchangable, realistically this is not true. A map is one single area that provides a place 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 Ravenholm 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)


Template:Int lvl design

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.

Todo:  guide the user through the toolbar documentation, recomend tools and procedures

Conclusion

<something deep and meaningfull>