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 transporting 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!

---

Level Flow intergration

The below is aditional topics and ideas that need intergrating into the Level Flow tutorial.

Determine a Route Through the Entire Level

• A sketch on paper of the entire route through a level lays the foundation for a later more detailed design of the entire level. This is particularly important in a level intended for "single-level" play - a single level to be played from beginning to end.
• Without a concept of where the player will start out or end up in a level can result in a patchwork of ladders, steps or bridges which detract from the consistency of a level's design.

Layout The Level Very Simply

The initial phase of level construction blocks out the route the player must take.

• Use just three or four textures, such as the orange and gray dev textures, nodraw and the skybox texture. Detailed texturing should be much later in the process.
• Layout undetailed blocks for buildings, bridges and open doorways to outline the route the player must take through the level. Swing doors or lift gates can be added later.
• For outdoor levels, add a single light environment. Scene lighting is expensive with regard to compiling time.
• For indoor levels, limit the number of light entities to that necessary to test the route through the level. Again, scene lighting takes a lot of compile time.
• During this phase of design, do not add unnecessary entities or models such as NPCs, barrels or pipes. An exception may have to be made if, for instance, the level requires piling crates on one another as part of the primary route through the map.
• If the level requires stairways, use simple stairs without rails or supports. However, ensure the steps are sized correctly and room layout is sufficient to allow the proper height to be reached. Having to later resize a room that is too small for a long enough run of steps to reach the proper height can be time-consuming. See the section below on making separate test maps.
• Test the layout often, perhaps after adding just a few blocks or hallways. Determine if the size of the map and areas within the map give the "feel" for the level that is desired.

In this screenshot from Hammer, there are only four primary textures used: dev/dev_measurewall01a (orange), dev/dev_measuregeneric01b (gray), tools/toolsnodraw and tools/toolsskybox. The retaining wall and the street are textured but, at this point in the construction, unnecessarily. Although early NPC testing (ground and air nodes, triggers, etc.) has begun, detailed architecture and texturing will be done much later. Note that areas which the player cannot see (roofs, rear walls, etc.) are not even constructed. The backside of walls, floors and sky are all textured in nodraw. At this point, a single light environment entity serves the entire map.

Make Separate Maps to Test the Layout

Using separate small maps to test portions of the larger level map saves large amounts of compile time.

For instance, if the level requires an assault by a patrol, create a new map to layout simple block obstacles or cover and determine the general desired movement of the troops. From this map, the required area needed in the level map can be more precisely layed out. However, don't add the NPCs to the level map until later.

If the level requires jumping across gaps or moving entities to gain access to ledges or stair sizing, a test map can be used to determine the proper distances without requiring a complete compile of the level map. Once the information has been determined, adjust the level map but do not add entities such as crates or barrels to the level map unless required.

---

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>

Entities in Depth

(this section will be the Entities in Depth article once compelte)

Template:Int lvl design

Introduction

Entities provide the level of interaction found in all levels, from the car that explodes to the antlionguard throwing you acoss the room it all originates with entities. Entities provide all the interaction a level designer can create and also provide a lot of functionality. Entities are essential to level design.

What it is

An entity is a collection of special information that informs the game how to behave and how this object will behave. All the information that defines what entities can do is hidden away within the game's code; therefore, for Hammer to know what possibilities exsist a reference files is written. The refernece file is know as an FGD, its important to note because it lists all the information about entities as far as Hammer is concered. Its key to understand the FGD does not create the entities it just tells Hammer how to use the code in game. As far as a level designer is concered there are two types of entities, point and brush. Each categorizes a different set of properties and effects which are then created and used in different manners; however, they both work exactly the same.

Point Entities: A point entity is usually the first type of entity you will come across. It has no physical size it merley occupies an infintley small point in space and half the time this point is irrelevant. Point entities are used to define things like timers, and random choices or position an effect such as a sprite or a decal. Point entities can even have sizes and shapes attached to them like a model or even apply rules to objects like a hinge, point entities make up the logic and rules of the level that eitheir effect the entire level or one tiny position in it. Creating one is done with the entity tool.

Brush Entities: Brush entities differ from point entities in the fact that they occupy physical spaces, brushes are taken and then turned into a brush entitiy. Using a brush entity you can monitor when a play steps in an area or create a door to block his progress untill he is able to open it. Brush entities occupy or represent physical space their essential to optimization and high level effects. Brush entities are created differently thoguh as they need brushes to be tied to. Select all the brushes you want making into one entity, Press Ctrl+T to send it "toEntity". Ctrl+W will sned it back to world brushes.

An entity consists of several different groups of information, Properties, Flags, and I/O. Below the three are detailed. All go together to make 1 entitiy and often work together, inputs can change properties and flags can define defualt states or what triggers an output. Looking through all sections will reveal exactly what an entity can do.

Properties

Properties are the variables of an entity, they can contain any value or a set range of values. The properpties detail information such such as name, color, rendering effects, what gun barney spawns with. There is a property and a key value. The key value stores the information about the property, whether the Color propertery is blue, red or green. Hammer will put detailed names and descriptions of the effects up on the screen with the feature "Smart Edit", turning it off removes the user friendly names and help.

Flags

Flags represent simple boolean conditions of an entity. They often change the fundamental behaviour of an entity. Often overlooked, usefull conditions are often found in here such as "Motion disable" for a prop_physics to stop it moving at all. Flags often set defualt states or allow a certain behaviour.

Inputs and Outputs

Text

Using Entities

Text

Conclusion

<something deep and meaningfull>