Dungeon Siege Fan Site -> Training Camp -> D.S. University -> U200 - Intro to Dungeon Siege Concepts and Terminology

:: Dungeon Siege University - U200 ::

Here is the 'U200' stuff:

Siege University 200: Intro to Dungeon Siege Concepts and Terminology

Action: What a trigger does when its conditions are tested "true". Actions include the direct execution of a number of functions and the sending of messages. Messages are sent via the game's message delivery system to other objects in the game that are waiting for them, such as other triggers, gizmos, and actors.

Actor: A Game Object with AI (artificial intelligence), but also includes the party. Actors include all monsters, ambient creatures, and NPCs; they also include other objects you wouldn't normally consider an actor, but have [actor] blocks in their template, like certain doors and chests. Actors that can be manipulated in SE have a SCID, but all actors (even ones that don't appear in SE, like the starting player character or monsters spawned from generators) have a GOID.

Artificial Intelligence (AI): Code that determines how an actor interacts with the world by scanning for objects/actors the actor can see. AI sends messages to its two subsections (brain and jobs) for interaction commands.

Brain: The higher level of AI. The Brain is responsible for high-level behavior and typically runs Jobs in response to stimuli. The Individual Brain (per actor) decides how to interact with objects/actors (i.e. attack, guard, flee). Every actor can be assigned a brain, even things not assigned intelligence in the real world, like trees, chests, furniture, etc. A Party Brain can be assigned to control group tactics, like healing friends, supporting friends, or moving and attacking in formation.

Jobs: The lower level of AI. Jobs are responsible for handling specific functions, using chores to accomplish those tasks. Jobs manage:

Movement: Following, moving in formation, guarding, moving
Attacking: How to get there, what animations to use
Item manipulation: Getting items, dropping, equipping
Talking to other actors: Selecting the appropriate conversation, syncing dialog and animations, playing any special actions that occur as a result of the conversation
Other actions: Using, drinking, going unconscious/conscious, special monster behaviors, fleeing, dying

Chores: Used by Jobs, but are not a dedicated section of AI. Chores can also be used by objects through attached skrits or external gizmos. Chores are useful for controlling animations, including playing, blending, and modifying.

Component: Represents the code or skrit used to handle a certain aspect of a GO. For example, the mind component of an actor runs AI. Components are defined by the template(s) that a GO specializes (see Siege U - 201: Templates).

Conditions: A predetermined requirement or set of requirements that must be met before the trigger's actions will be executed. Conditions include testing whether a certain kind of object has entered, exists within, or has exited a specified area; whether the trigger has received a particular message from another object or the game itself; or both.

Game Object (GO): A GO, or more generally, "object", is nearly any mesh (3D object) in the game that isn't a node. Objects can be placed and moved on, above, or below nodes, and include things like actors, furnishings, gizmos, lights, etc. The generic term "object" is also used to talk specifically about meshes that don't have another more specific name (like actor or gizmo), such as trees, chairs, rocks, fences, etc. We are primarily concerned with an object's SCID, but it also has a GOID. All GO's are defined by their "template".

Gas Files: Essentially plain text files which are written in a specific format that the Siege Engine knows how to read and interpreted at run time. These files actually help define the game while the gaming engine knows how to make sense of all this data, how to properly display it, and how to allow the user to interact with it. The types of data that are defined in Gas Files vary widely. Gas Files can define what a tree looks like, where a monster is placed in the world, how the world itself is built, what happens in the world, and even what the user interface looks like or what the default preferences for the game are. The engine then takes all this information and magically makes it all work when you run the game.

Gizmo: A logical Game Object placed and manipulated in SE. Gizmos are self-contained pieces of skrit or other functionality that accomplish specific actions in the game. Gizmos are connected or "wired" to many other objects, actors, and gizmos. Gizmos include things like AI commands, elevators, creature generators, sound and sfx emitters, light manipulators, and lots more. Much of the functionality of triggers will be in activating/deactivating gizmos. The trigger itself is a gizmo. Gizmos share the same identifiers as all objects: SCIDs and GOIDs.

Identifiers: All nodes and objects have recognizable template names that you use to identify them (like krug_scavenger), but SE needs to keep track of each unique "instance" of that node or object. For example, you may have 20 Krug Scavengers in your region, but each of those 20 instances has the same template name, krug_scavenger. Internally, the game engine assigns several of the following "identifiers" to make the instances unique. Each identifier is an eight-digit hexadecimal number, preceded by "0x", which looks like this: 0xe589a1ff.

Global Unique Identifier (GUID): Each Node and Region is assigned a Node or Region GUID (pronounced "gwid") on creation. The GUID is a unique number per map (see the SE Manual for more info). We will use Node and Region GUIDs to manipulate nodes with triggers.

Static Content Identifier (SCID): A SCID (pronounced "skid") is a unique number assigned to every object placed in SE. We will use SCIDs to reference almost every kind of object, including actors and gizmos.

Global Object Identifier (GOID): We don't really have to worry about GOIDs (pronounced "goyd") for triggering, but it's nice to know they exist. Every object in the game is assigned a GOID by the game engine. They are different from SCIDs in that a SCID is used to connect objects in SE. GOIDs are used to reference and connect objects dynamically in the game engine. Sometimes an object doesn't have a SCID, like the starting player character or a monster spawned from a generator, but it always has a GOID.

Fades: The act of making nodes visible or invisible is called "fading". Triggers that activate fading actions are usually called fade triggers. When a node is faded out (completely invisible), all objects associated with that node are also invisible, as well as unselectable.

Frustum: The "world frustum" is the area around a party member where the world is "loaded" and visible to the player. It is a box-like shape whose center is permanently focused on the active party member (or members, in the case of a multiplayer game). Any node or GO outside this area is "unloaded"--compressed down into a small data structure until it comes within the frustum. As the player moves, nodes and objects are "streamed" into the frustum and loaded. Any nodes or objects leaving the frustum are "streamed out" and unloaded. We generally cannot directly "talk to" a node or object outside the frustum (since it is in an unloaded state), but any messages sent to these nodes or objects are queued by the game's messaging system to be delivered when the node/object gets loaded again.

Level Of Detail For Items (LODFI): Originally meant just as a way to remove objects from the world to reduce rendering time, LODFI ended up being a major optimization for multiplayer and save game. LODFI is a pair of values in the [common] block called lodfi_lower and lodfi_upper. They are described a bit in components.gas:

[lodfi_upper] { type = float; default = -1.0; constrain = range[ 0.0, 1.0 ]; doc = "Upper bound for level of detail for items - will always render if object detail level higher than this (set -1 for critical/global)"; }

[lodfi_lower] { type = float; default = -1.0; constrain = range[ 0.0, 1.0 ]; doc = "Lower bound for level of detail for items - will not render at all if object detail level lower than this"; }

The numbers correspond to the object detail slider on the options menu, where the lowest detail setting is 0 and the highest is 1. The upper/lower_lodfi settings in [common] define a range. If the object detail is lower than the range, it never loads, and if it's higher, then it always loads. If it's somewhere in the middle then there is a random chance it will load (this is good for shrubs). Here is the algorithm that the loader uses when deciding to load an object:

If lodfi_upper <= 0 then load always
If object detail level > lodfi_upper then load always
If object detail level < lodfi_lower then never load
Pick random number between lodfi_lower and lodfi_upper. If object detail level < this then don't load, otherwise load.

Lots of things are optimized based on LODFI settings. There are three types of objects from the loader's point of view:

Global: Objects with lodfi_upper < 0. Used for anything that is generally interactive, like monsters or doors.
Local-lodfi: Objects that are client-side only and are used for decorations and have lodfi_upper >= 0.
Local-plain: Special objects that are loaded locally but may have global effects. The server needs to load them for frustums outside its screen player's (usually reserved for blocking objects), and are set on the server if lodfi_upper == 0, we're in multiplayer, and aspect:does_block_path = true.

LODFI is used for many things even if the detail slider is not involved. For example, while the bed in a farmhouse is considered "required" and should never go away regardless of the slider, it should not be marked as -1. It should instead be marked as 0 so it's still considered a LODFI object but is always loaded. LODFI objects are not saved out in the save game (because their state cannot change) and they are not transmitted over the network in multiplayer. They do not show up in AI sensor queries and are considered 100% pure eye candy. They are specially permitted to block paths, and that's what the local-plain is meant for, but they're still considered LODFI in the eyes of the save game system.

Map: The sum collection of all stitched regions. This is the entire "world". The map is not directly referenced within SE since you are already working on a region inside it. You cannot reference a region in a different map.

Messages: Used to send events throughout the game. Messages are used to trigger the AI, activate gizmos, control animations, etc. Messages can be sent as "normal" or "delayed"; normal messages are processed immediately. Delayed messages can be sent to unloaded SCIDs (see Identifiers), which are queued until the objects are loaded. Data contained in messages includes the sender, the recipient, and optional data elements.

Moods: A block of settings that specifies the fog near and far distance, the fog color, the music and how often it repeats, the ambient track, the weather type and density, the wind speed and direction, the EAX settings, and even (in some cases) the size of the frustum.

Node: The basic building block of terrain. Nodes are individual 3D tiles locked together to create the game world. Nodes can be individually selected, and are identified in SE by a Node GUID (see Identifiers).

Parameterized Content (pcontent): Randomly generated content, defined by a set of rules. For example, a chest can be loaded with a specific range of weapons to drop, instead of adding a specific template name. For further information, examine the compressed file components.gas.

Party Member: Also considered an actor (and therefore a GO), a party member is the player's character or group of characters, including the packmule. The starting party member doesn't have a SCID, but all the party members that join him/her do since they start life as objects in SE. All party members have a GOID.

Properties: Used to define components. For example, the Aspect component has a property called "scale_base" that defines the size of the object in game.

Region: A discrete "level" composed of nodes. SE loads individual regions for editing. Regions are "stitched" to each other so they appear seamless in game. Regions are identified in SE by a Region GUID, and must be assigned to a map.

Skrit: A scripting language that can trigger and manipulate game events. Many gizmos are self-contained pieces of skrit.

Siege Editor (SE): The Siege Editor is the primary tool used for constructing maps for Dungeon Siege.

Siege Max (SM): The Dungeon Siege game pack for gmax, from discreet. Siege Max will allow for the modification and creation of custom 3D models and animations that can be directly imported into Dungeon Siege.

Siege Objects: Siege Objects are SE-specific objects that can be placed and manipulated within SE, but are never selectable within the game itself. Falling into this category are Starting Positions, Point Lights, Spot Lights, and Decals. Siege Objects are defined in the code and do not have templates at all.

Special Effects: Mainly particle effects. A particle in Dungeon Siege is a forward-facing, textured polygon, which can blend with other particles and other objects. Special effects run on two objects: a source and a target. Effects are most commonly visual, but certain effects can collide or cause damage. Also referred to as "Siege FX", "flamethrower", and "worldfx".

Templates: At the most basic level, a template tells the game engine how to use certain game resources - such as art, sound, and physics properties - to create (instantiate) a Game Object (rock, tree, sword, a Krug, etc.) in the world. A template is simply a block of text that defines the characteristics of a Game Object.

Message Board
Forum
Chat
Email