This section describes the defined things that make up the core of the default world in the game. The role playing system provides extenstions to this model.
For a more detailed description of the things see the section in the game engine on Things and Defined Things.
There are two types of things. Defined Things are the templates on which the world is constructed. Things are the specific implementation of the defined thing in an actual game. In general a thing will behave as defined by it's template, but the engine allows mechanics for this to be altered in unexpected ways.
For example: There may be a definition in thedefined things for a rug. This would define items like the fact that the rug is made of cloth and that is can be rolled up. In a game an actual rug is created from the defined rug. A magic spell is cast that makes this ordinary rug into a flying carpet. The game would add the ability to fly to the specific rug. This prevents all rugs from getting the ability to fly.
Things
A thing can contain other things. For example a bag contains other thing objects. Care needs to be taken as sometimes things are attached rather than contained.
A thing can be connected to other things. For instance a person wearing armour has the armour attached to them. This is reverse containment, where in reality the armour contains the person. Unfortunately people do not normally thing in this terminology. Conversely a sign may be nailed to a post. The nail is acting as a connector. Finally a table-top can hold several items by dint of gravity. If the table is tipped or the gravity reversed the connection no-longer holds true.
A thing can be composed of other things. This composition could be optional. For example: a biro would be composed of plastic tube and a writing object containing the ink and ball. Optionally it can also have a lid and end stopper. I you replace one item with another equivalent item, you still have the same biro. If the inner and tube become irrevocably separated then you now have 2 broken biros. This is a "component-object" relationship.
This is a subset of the possibilities. A component can be consumed by being a component or it can add functionality. A stopper on the end of the pen is consumed and does not add a "stopper" function to the pen.
A thing provides capabilities. For instance a biro creates the ability to write. Some attributes are generally very common. A biro could be used as a leaver. Though it may break if too much force is applied. A capability allows the thing to perform actions. The capability provides a feature-activity relationship.
A thing can have many characteristics. Each would represent an appropriate set of conditions that can be modified by other things. The biro could have ink or no ink or an amount in-between. A state allows the game thing to respond to actions.
Other relationships that need to be considered are: member-collection (tree/forest), portion-mass (slice/cake), stuff-object (aluminium/aeroplane), place-area (Cammeray/Sydney) and phase-process (adolescence/growing up). Are these special types of characteristics?
Characteristics and capabilities are gained from components, they are not gained from things that are contained.
Future items...characteristics...need to be easily extensible...so therefore make objects of them.
- Visibility = text... where can the object be seen from...a number relating to the number of levels up the tree?
The game things have the following definitional components:
| Part | Description | Example |
|---|---|---|
| name | The name of the thing. | Room |
| component things | A list of things that are contained within this game thing. | Table Chair |
| connector things | A list of all things that connect to other things across the tree. | Door Opening Walls |
| characteristics | A list of all the state machines that can be used to describe this game thing. | air quality air opacity |
| Attachments | A list of all the attachments to this object. some interesting thoughts
are:
|
|
| Capabilities | A list of things that this object can do. | Run jump write |
Templates of game things are used extensively to save on data storage space and data transfer times. A template could be used for an item such as a door. All doors are nominally the same. So unless something is done to modify a door then the door remains the same. An example of modifying a door is breaking the door. This door would then be stored as a specific instance of a (broken) door. A more specific instance is where a person inscribes their name on a door. It is likely that there may be several doors but only one graffitied door.
Default World Defined Things
The world is comprised of things. These things (including the world itself) have characteristics that describe them. As this system is meant to be extensible and flexible, the system provides the tools to create the things but leaves it up to the authors of the worlds to actually specify the level of detail important in their world.
Things have an underlying description and a set of operations that can be performed onto that thing.
The hierarchy here is one based on "is a type of", providing inheritance down the tree in the form of characteristics and operations.
Numbat Data Definition
<?xml version="1.0"?> <!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <!--I am really confused as to where this tag belongs.--> <schema name="file:///"> <head> <title>Numb.bat V3.0 default world definition</title> </head> <body> <h1>Thing</h1> <p>This is the start of the trees in the numb.bat model. </p> <DefinedThing> <name>Thing</name><description>The top level of thing within this game system.</description><subclass>None</subclass> </DefinedThing> <h1>Physical Thing</h1> <p>This is the class that describes all physical things.</p> <DefinedThing> <datatype name="name">PhysicalThing</name><description>Represents a real thing in the game system.</description><subclass>Thing</subclass><!--All physical things may have a current context.--> <context>none</context><!--All physical things have a location within the current context.--> <datatype name="location"> <basetype name="point3D"/> </datatype><!--All physical things consume space.--> <datatype name="shapeModel"> <basetype name="collection"/> <... </datatype><!-- All physical things have a mass. Even if it can be zero or negative. --> <datatype name="massModel"> <basetype name="collection"/> <... </datatype><!--All physical things have a electrial charge map.--> <datatype name="electricalModel"> <basetype name="collection"/> <... </datatype><!--All physical things magnetic flux map.--> <datatype name="magneticModel"> <basetype name="collection"/> <... </datatype><!-- All physical things have a current velocity within the current context. --> <datatype name="velocity"> <basetype name="vector"/> </datatype><!-- All physical things have an angular momentum within the current context. --> <datatype name="angularVelocity"> <basetype name="?"/> </datatype><!--All physical things may have components which are of type Thing.--> <datatype name="components"> <basetype name="collection"/> <... </datatype><!--All physical things may contian things which are of type Thing.--> <datatype name="contains"> <basetype name="collection"/> <... </datatype><!--All physical things may be attached to other Physical Things.--> <datatype name="attachments"> <basetype name="collection"/> <... </datatype><!--All physical things may perform actions.--> <datatype name="actions"> <basetype name="collection"/> <... </datatype> </DefinedThing> </body> </schema> </html> |
This section is now obsolete. The concepts need to be incorporated into the things section in the game engine.
Builders and Factories
The database engine uses the thing builders and factories to create the things as they are complex products, from the data storage location or using the cache.
Thing builders and factories are used to allow the building of complex representations of objects.
Any thing can request the construction of another thing. The game window can also request the construction of things. It is responsible for the construction of the single instances of GameThing and Player Thing.
The Director Of Construction controls the construction of the complex thing representation by making appropriate calls to builders in the appropriate orders.
For each type of thing, capability and characteristic, there is a custom builder.
The category builder builds all the generalised categories in the game, starting with the root category object.
The builder then gets the data from the specified location through a data fetcher. The data fetcher hides the different implementations of different storage mechanisms from the builder. It also allows the caching of data, in an object pool, to speed loading for standard components and templates. The fetcher also allows multi-threading of data loads with each component in it's own thread when loading data over the internet.
The loading section uses builders to load and initialise the data into the game.
The game thing actually uses a separate director of construction for each of the objects, category builder, game thing builder, player thing builder and thing builder. All directors of construction have their own characteristic builders and capability builders.
Things to do:
- change the name of the game processor in the above diagram to game thing... and the cascade changes.
Object Model
The game thing is comprised of several parts.
Things have a complex containment, aggregation and association roles. These relationships provide the complex interaction required to keep the things generic and yet allow the full flexibility that the game requires.
A thing can be composed of other things, contained within other things or attached to other things. The basic relationship here is containment. At the core of the database is a thing that is the universe to the game. All other thing as are contained within this thing. Attachments provide horizontal associations across this hierarchy. They do not necessarily occur at the same level. Components are a special type of containment. They indicate that the components are part of the higher level thing rather than merely contained in the higher level thing. Another important issue with components, is that a component can currently be some-where-else.
Special classes are created for the player thing and game thing.
The game thing only occurs once per game session. It controls the game, loading, saving, joining and leaving functions. However, a player may be playing more than one game session, such as playing a game within a game.
The player thing normally only occurs once per game. This records and provides the functionality for the person playing the game.
Examples:
In the above example, the game points to the universe and player. The universe contains a room. The room contains the player, a wall, a picture hook and a picture. The picture is attached to the picture hook which in turn is attached to the wall. The picture is composed of a frame and a painting.
GameThing.java
All Packages Class Hierarchy This Package Previous Next Index Class bvyy.database.GameThingjava.lang.Object | +----bvyy.database.Thing | +----bvyy.database.RealThing | +----bvyy.database.GameThing
|
PlayerThing.java
All Packages Class Hierarchy This Package Previous Next Index Class bvyy.database.PlayerThingjava.lang.Object | +----bvyy.database.Thing | +----bvyy.database.RealThing | +----bvyy.database.PlayerThing
|
All Packages Class Hierarchy This Package Previous Next Index Class bvyy.database.RealThingjava.lang.Object | +----bvyy.database.Thing | +----bvyy.database.RealThing
|
Thing.java
All Packages Class Hierarchy This Package Previous Next Index Class bvyy.database.Thingjava.lang.Object | +----bvyy.database.Thing
|
Using Things
16/02/00