 |
Fellow adventurers! This guide is a direct upload from the original author and is no longer supported by Microsoft or Gas Powered Games. It is also not supported by the wikia's administration or members. Any errors encountered are a result of the original publication. |
Introduction[]
This article covers how objects in Dungeon Siege work. We will discuss how objects are defined, the different types of objects, how they are loaded, and the different systems in the game that can manipulate these objects. This article in conjunction with Siege University 200 should provide a good overview of how the game works. Hopefully this article will show you which systems do what; and when you start to write skrits it will give you a good idea where to look to accomplish different tasks.
What You Need For This Tutorial[]
- Nothing. This is just an informational article.
What This Tutorial Assumes You Have Already Learned[]
Game Objects (GOs)[]
All of the objects in Dungeon Siege are treated in a similar way. All of the monsters, heroes, even a spell in a spell book are all very similar. The differences between the GOs are the components that are attached to them. Attaching the physics component for example will allow an object to simulate moving through the air using physics. A GO without the physics component doesn't have this ability.
Organization of GOs
- A good way to think of Game objects is to compare them to organisms. The Linnaean system sorts organisms into a tree hierarchy: they are spilt up into kingdom, phylum, class, order, family, genus and species. "Kingdoms" are the most broad category while "family" or "genus" are much more narrow. For example, animals are in the kingdom Animalia. Chordata (one of the phylums in Animilia) contains all of these creatures that also have a backbone-like structure (as well as a few other characteristics). The description of an organism gets more specific as you move down the tree. At the end it is describing just one organism instead of a group.
- Just like an organism has DNA that tells how it is made, Game Objects have templates. These templates are also sorted into a tree. The high level templates are called primary branches or roots. The primary branch templates are: actor, interactive, non_interactive, trap, emitter, command, elevator, special, test, generator and ui.
- All templates, primary branch templates included, are a set of components that define how a GO will act. Templates can be specialized to make a new template. A template that specializes inherits all of the attributes of the parent template; this new template can add new components, or change the values in the existing ones. There can be many levels of specialization.
- For more information about templates, read Siege U: 201 - Templates. Most of the skrit written for Dungeon Siege took the form of writing special components to attach to GOs to give them special behavior.
When the game loads a GO, the process can be complicated. In a single player game it's pretty straightforward: the game loads a GO, and then it's ready for action. In multiplayer it's a little more complex: all GO creation is handled on the server, the server then tells the clients that need to know about a GO to create them as well. If two players are on opposite ends of the map, then they don't need to know about the objects that the other is seeing.
Some GOs don't ever need to be loaded on any clients. These are called server-only GOs, and these mainly only consist of control gizmos, or triggers. The game automatically detects if a GO can be a server-only GO. Some GOs always need to exist on all of the clients, even if they aren't in that client's frustum. These are called all clients GOs. The players and their inventories fall into this category. The last special type of GO is the omni GO. These aren't placed in the editor like a normal object; instead they are created or cloned in a special way from code or in skrit. These objects don't have a position in the world, so they can never be unloaded. These are useful to keep track of objects that are going to be moving a lot. These are used extensively by the spell system to keep track of enchantments on a GO.
Each component is more than just a list of properties; there are also functions in that component that can be called from skrit to affect that GO. For example, if you want to make a GO run a job, you would access the mind component of that GO and run it from there.
GO Components[]
These can be added simply by referencing them in the template of an object. Here is a list of most of the available components and what they are used for.
Actor: Handles traditional RPG attributes such as skills and alignment. Stores and manipulates the Status States information. These are used to indicate if a character is in a state, and how long the state lasts. We call anything that has an actor component an Actor. This includes players, monsters, and NPCs. Having an actor component requires you to also have attack, body, defend, physics, and inventory components.
Aspect: The visual representation of a GO. The Aspect also defines how the GO interacts, whether it is currently visible, selectable, useable, collideable or path blocking. The Aspect also contains the life and mana for the GO. Another part of the Aspect is LODFI. LODFI GOs are created locally on each machine; these are non-interactive, and depending on their LODFI value they can be made to disappear with the Game Detail slider. The Aspect component provides control of the Chores that a GO can run, and can be used to set up blending. Having an Aspect component requires that a GO have a Placement component.
Attack: Contains information about how this GO attacks. Used to define the attack information for weapons, projectiles, and Actors. Contains information like damage, reload time, and attack ranges. The Attack component handles loading and launching ammo for projectile weapons. Requires the Common component.
Body: Contains information about how an Actor moves and animates. Contains the bone translator, which maps Bones in the model into common bone names that are used by simulation and effects. Specifies the chores that an object has, which animations those chores contain, and which skrits drive those chores. Requires the Aspect component.
Common: Contains common attributes about a GO. Also contains all of the triggers for an object. The Common component contains membership that is used to determine which GOs can damage each other, immunity to spells, and dynamic party creation.
Conversation: Contains a list of the conversations that this GO can access. The Conversation component has controls to select and activate those conversations. Used in AI talk jobs to control conversations.
Defend: Info about defense such as armor type and defensive value.
Gizmo: Gizmos are objects that show up in the editor, but not the game. If you wanted to make an invisible controller GO, then you would put a gizmo on it so you could see it in SE. Also useful for keeping track of which direction is which on objects where it matters, such as chests.
Gold: Used to set the price of items, also contains info about how gold looks on the ground.
GUI: How an object looks in and interacts with the inventory.
Inventory: Defines the inventory layout. Can be used to list, equip, remove, or put items into a GO's inventory.
Magic: Defines the properties for casting a magic spell. Can store and apply enchantments, these can be for a spell, an enchanted weapon, or even a potion.
Message: Storage for text messages to print to the screen, they are stored here for easy localization.
Mind: Defines properties on how an actor uses AI, specifies which skrits to use for AI. Has several high level AIQuery and Inventory routines to make AI specifically easier. Contains controls to run and manage AI jobs.
Party: Defines party light, sets up how dynamic parties form and the AI that they use. The Party component has controls for adding and removing actors from the party. This component also handles moving the party in formation.
Pcontent: Specifies the pcontent values on an item, what the power level is, what enchantments the object can have, all of this for all of the various quality types of a weapon.
Physics: Defines how an object will fall, burn, and break.
Placement: Stores position information about an object. Can get and set the placement or orientation.
Potion: Manages how a potion represents its full state in the inventory.
Store: Manages NPC stores, which items restock, the prices of the items, and even if the person can put themselves up for hire.
Skrit Components: These can contain custom properties and behavior. Hooking up a new Skrit component is relatively easy: you just need to put the skrit in the right directory, and then the game will automatically detect it and make it available.
Streaming And The Frustum[]
Nodes are the building block of the world's terrain. Nodes have connectors where they can be connected to other nodes; these connectors are called doors. Doors can be any size to link two nodes. Typically we make the door the full size of the connection between the nodes. Doors are used for path finding and determining which nodes to stream in.
Nodes can be any size or shape. We tend to make then a uniform size and shape to make construction easier; this also limits the number of custom pieces needed. Nodes can be moved with special gizmos called elevators. Elevators take a node and change which door it is connected to. It can even connect it to a completely separate node. Each node can have a "floored" area. The floored area is the part that is walkable by an actor.
A frustum is a big volume that we want the world to be in; the game tries to keep nodes loaded to fill the frustum. The frustum has a width and height; these sizes can be modified as part of a mood. Each character in a game has a frustum. This means that an 8-player MP game has eight frustums. The center of a frustum is the node that a character is on. This node is called the target node. The game looks at the target node and recursively checks all of the doors on that node, looking for the nodes that are connected by these doors. When the game finds a new node it loads it, then tries to load the nodes connected to it. The game continues to look for new nodes to load in this fashion until it fills up the frustum, or runs to the edge of the world. When the character moves, the target node moves with them. Moving the target node causes the frustum to move as well. When nodes that were loaded are no longer in the frustum they get unloaded.
Each region has a list of the Scids that are in each node. When the node is loaded the game looks at the Scids in that node and loads them as well. Loaded GOs are given Goids to be able to reference them later. When an object is killed or the node that an object is on gets unloaded, then that object starts to expire. Expiration is a timer that an object is going to last for before it gets deleted. If an object is expiring because it left the world, then the node it is in is reloaded then it stops expiring. Goids are a valid way to reference an object until it finishes expiring.
One of the common pitfalls that we run into when making content for the game is how to handle connected objects when they stream in and out. For example, let's say that you wanted to trigger a scripted ambush in the game. You could set up a treasure chest to activate a generator behind the player. The newly-generated monsters could then run towards the player. If the generator was far enough away from the treasure chest, then it might not be in the world when triggered, and nothing would happen.
In addition to the world frustum there is also a view frustum. The way that the view frustum works is similar to that of the world frustum: the game determines which nodes are in the view frustum, and only draws those. Objects are drawn the same way: if the node that an object is in is drawn then the object itself will be drawn. Fog can decrease the amount that is drawn but those nodes are still loaded.
Systems[]
There are several Game Systems in Dungeon Siege. These control different parts of the game. The systems can be accessed from skrit to perform different actions to affect GOs or the world as a whole. Here is a list of the most important systems, and some of the functions they serve.
AIQuery: AIQuery is used to look at the surrounding area. One of the main uses of these queries is to get the GOs that are near this object. You can either look for one GO or all of them in a certain area. You can also set up filters so you only get certain types of actors. AIQuery also provides distance and visibility checking. You can also use AIQuery to find points on the ground, you can find a point that would have a clear line of sight, or just find a point relative to another object.
CameraAgent: The CameraAgent can be used to control the position of the camera. You can offset the camera position, or transition it to a new point. The CameraAgent is used for NIS camera control.
ContentDb: ContentDB can be used to get information from a GO's template. You can also create formulas and evaluate them with this system.
GameAuditor: The GameAuditor can be used to set global named values. You can use this to set when a global event has occurred, or if there is a global value that needs to be saved it can be stored with this.
GoDb: The GoDB handles low level GO manipulation. You can create new GOs from a template, or make a copy of an existing GO. You can also delete a GO in about 25 different ways. You can use the GoDB to set ScidBits. ScidBits store information about a GO that can store its state. This provides much lower memory usage than just saying everything about an object. Another use of the GoDb is to watch another GO. When you are watching a GO you get a carbon copy of the message that was sent to it.
MCPManager: The MCPManager is used to make Chore requests to the MCP. Chores are used by the AI Jobs. Chores can move the character and play different animations.
Mood: Moods are the ambient mood in the game. Things like fog, rain, and the music playing are all part of the mood. The mood system can be used to set which mood is being played, or what parts are being used from the different players' moods. You can also change which music tracks are playing.
Physics: Physics handles simulation of objects. This is used to explode objects or flip a weapon when it is dropped to the ground. Physics can also be used to create areas of damage, either from explosions, or just an area that does damage.
Rules: The Rules system handles Gameplay code. This includes chances to hit, determining and applying damage, even awarding experience.
SiegeFx: SiegeFX manages effect scripts. You can use SiegeFX to start local or global effects, and when you are done with them you can turn them off. You can also use SiegeFX to store temporary positions.
Server: Server is used to keep track of the players that are in the game. You can get a local player, all of the players in the party, or all of the players in a MP game.
Victory: The Victory System manages parts of the game related to major gameplay events like quests or winning the game itself. You can use the Victory system to assign quests and advance them through their various states. You can then complete the quest when it's done. Chapter transitions are handled through victory. You can also set up victory conditions and check them through the victory system.
World: The World system is useful for drawing debug HUDs in the game.
WorldTerrain: The WorldTerrain system is used to move nodes, and connect or disconnect doors. All of the elevators were written using the world terrain system. The HUB teleport pads are just node transition and connections.
Conclusion[]
We have talked about how objects work in Dungeon Siege. You should now have a basic understanding about how different objects are constructed. Also how some of the different systems that work on those objects function.
