Game Object Model
The Game Object Model (aka the GOM) databases are the actual data of the entire game universe. Essentially a GOM is a giant collection of nodes (derived from classes) which have been created by scripts or GameMasters. These nodes are linked together via the association engine.
GOM data is always based on the classes and definitions that have been defined in the DOM (the Data Object Model).
NOTE: Classes and Fields can be created via the CLI or DOM Editor, but cannot be created or modified via HeroScript. The CLI and DOM Editor are the only tools that can make additions or changes to the class and field definitions in the DOM.
How GOM Data is stored and modified
There are actually multiple versions of GOM data in existence at one time, and different versions may have different quantities of the data. Defining these different versions is complex, but here is a very general explanation of how it works.
GOM data has two major components: The DOM definitions (fields and classes), and the data that uses those definitions (nodes and variables).
For the most part, the nodes of the GOM are persisted (saved) in a giant database via the Javelin System. However, not all nodes are loaded into memory at one time (the world is made up of a lot of nodes!). So, an appropriate subset of the nodes are in memory on any particular server, where they can be modified by the CLI or HeroScript. There is also a very special reduced form of "lightweight" nodes which is on the Client.
It's very important to understand that just because a change is made to a particular node, does not mean that the change will be saved to the permanent database. Most versions of the GOM are temporary and not saved. Also, even in a version of the GOM that does get saved, only certain types of nodes will have their data saved to disk. Other nodes in that same database are just created on the fly while the game is running, and are not saved. The difference between these nodes, is called their Persistence. A Persistent Node (also called a persisted node) is saved to the database. Non-persistent nodes are not. For more information, please see the section on Node Persistence.
Making changes to a GOM
A GOM can be modified, and nodes created, via the HeroScript Scripting Language or a CLI command. HeroScript makes changes to whichever GOM is in the same location that the script is running. So, for example, a server-side script could make changes to an Area Server GOM, and a client-side script could make changes to the client GOM. Note that there is a very special syntax required when making changes to a client GOM. See Built-InNodeProperties for more details.
The CLI, on the other hand, can be used to make changes to several different GOMs, by prepending a specific character to theCLI command which specifies which GOM it should make the change in. For more information on how to do this, please see the section on the CLI.
Area Server GOM
On an Area Server, each instance of the area loads a portion of the GOM from the Javelin System database. This is done by the appropriate Area Server loading the area root node from the database and then bringing in the entire tree of things that are associated with it (the rooms, their assets, and so on).
The Area Server GOM gets its structure from the Server database schema.
On the client, each time it starts up, it gets the latest DOM definitions from the Repository. Then, when a character enters an Area, their Client loads .DAT files from the repository which generate a subset version of the GOM -- nodes on the Client that correspond to the Area.
There is a major difference, however, between nodes that are on the server, vs. nodes that are on the client. A node on the server is a very memory-intensive object, with multiple classes and fields, and data in those fields. Because of the quantity of nodes that are required in a game world, and the limited amount of processing power available on a particular user's home computer (the client), nodes are a very different kind of data structure on the client. On the client, a special kind of lightweight node is used, which does not have any classes or fields. It does have data in it though, which can be modified through a special system called modifying the Node's "Properties" via the HeroBlade Front End.
Important: Changes made to a node's Properties via HeroScript are not permanent. If it is desired to make a permanent change, then either the node's fields on the appropriate Area Server should be changed, or the change should be made via the HeroBlade FE, such as modifying the Properties panel.
For more information on Properties, please see the section on Built-InNodeProperties.
The Client GOM can also have "normal" nodes in it. For example, if a client-side script is creating GUIControls, these are all normal nodes, and their fields are set the same way on the client as if they were nodes on the server. Client nodes are never persistent though - they are only created on a temporary basis.
If unsure whether a particular node is a lightweight node with properties, or a normal node with fields, check the node's class. Lightweight nodes are always going to be either of class
hbnode, or some other class which derives from
hbnode (hbnode stands for HeroBlade Node). Other nodes that are created on the fly, such as GUIControls, are all normal nodes.
The Client GOM is loaded from the Client database schema.
- Replication, which copies GOM data between servers, or between client and server