User:Angry Beaver/Sandbox: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
m (Breakpoint)
m (→‎Layout The Level '''Very''' Simply: Unicodifying, replaced: [[Image: → [[File:)
 
(4 intermediate revisions by 3 users not shown)
Line 30: Line 30:
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.
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.


[[Image:Bj simple textures.JPG||Simple Layout]]
[[File:Bj simple textures.JPG||Simple Layout]]


=== Make Separate Maps to Test the Layout ===
=== Make Separate Maps to Test the Layout ===
Line 51: Line 51:
==Introduction==
==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.
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)
{{Int lvl design}}
==Introduction==
Entities provide the level of interaction found in all levels, from the car that explodes to the antlionguard throwing you across 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 period.
===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_entity|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, occasionally the point itself does not matter. Point entities are used to position an effect, or model ([[env_sprite]], [[prop_static]]); or to keep track of information ([[math_counter]]). Point entities are placed via the [[Hammer_Entity_Tool|entity tool]].
{{note| When trying to resize or reshape point entities as they have no physical shape they will not be altered but their position will, as such models cannot be resized}}
:'''[[Brush_entity|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. As brush entities occupy physical space they can block the player ([[func_door]]) or monitor an area ([[trigger_multiple]]). As they rely on brushes they aren't created with the entity tool, select any brush and press Ctrl+T or the "toEntity" button in the lower right.
{{note| Brush entities can span multiple brushes so all selected brushes will be turned into one single entity}}
{{note| Use Ctrl+W or the toWorld button to remove the entity information from the brushes}}
An entity consists of several different groups of information, Properties, Flags, and I/O. All go together to make 1 entitiy and often work in conjunction, for example inputs can change properties, flags can alter a properties effect and properties can define what triggers an output. Looking through all sections will reveal exactly what an entity can do. Below the three set of information are detailed.
===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, or rendering effects. 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 and reveals the properties and values as is.
===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 dis/allow a certain behaviour. Flags themselves cannot be changed in game, but sometimes the proeperties they affect can be.
===Inputs and Outputs===
Inputs and outputs are how information is passed between entities. Outputs and Inputs are directly linked to each other, when an ouput condition is met its triggered and that information is then passed into an input. That input will the effect certain changes within the entity. When a player walks into a [[trigger_once]] the OnStartTouch output is fired this can then trigger any Input on another entity making a light go on or an alarm sound. Simple at first glance the I/O system is incredibly powerfull and can even go so far as reproducing simpler games. Looking at an entities avalible inputs can tell you what you can change, but often a bit of experimentation is need to figure out when each output is fired.
===Using Entities===
Proper use of entities is one of the topics that goes far beyond the scope of any one article...


==Conclusion==
==Conclusion==
<something deep and meaningfull>
<something deep and meaningfull>

Latest revision as of 02:38, 7 January 2024

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.

Simple Layout

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.

Conclusion

<something deep and meaningfull>

Retrieved from "https://developer.valvesoftware.com/w/index.php?title=User:Angry_Beaver/Sandbox&oldid=370626"