How DimensioneX Works – 4

1.2.11      Multi-Area support (Clustering)

DimensioneX offers you the possibility to build a complex game by combining several independent areas into CLUSTERs of worlds.

 

Worlds belonging to the same CLUSTER must declare it in their WORLD definition. From then on, characters and objects can be moved between areas by using the MoveOutside instruction.

 

Clustered worlds do not share a memory space, even though they will use the same settings database (named after the cluster). Information to be shared can be safely passed to other areas by attaching it as a property to dummy message objects, which can be detected and destroyed after the information has been received.

 

For more details on how to use the clustering feature, see the following sections:

1. • DimensioneX DXW Reference->WORLD->CLUSTER
   • DimensioneX SmallBasic Reference->Instructions->MoveOutside
   • Basics->Developing a Game->Developing Multi-Area Games

 

1.2.12      Persistence

Game persistence is the property your game has to persist features, such as to let the world envirnoment to be the same after a server restart, and to let the user retain her objects after she logs off and in again.

 

DimensioneX provides to the game programmer a number of facilities to ensure game persistence.

We divide these facilities according to what you need to make persistent: world envinronment/context and user items.

1.2.12.1     World environment/context

 

The persistence of the game status is not guaranteed automatically by the system, so the game programmer must ensure that the relevant game status information are saved at regular basis and restored at restardt, by wisely using the saveSetting/getSetting instructions:

 

• By using the onTick event, possibly every N ticks, you can save relevant context information via the saveSetting instruction.
• By using the onStart event, you can read back the saved information via the getSetting() function, and reconstruct the relevant context.

 

Warning!: The saveSetting instruction produces a disk access and therefore quickly degrades game performance. For this reason, it is recommended to:

• use it only for really relevant information
• use some programming logic to save game status at every N ticks (where n can be equal to 4 or more) in order to decrease performance degradation.

 

1.2.12.2     User items

Since user properties are saved by the system each time the user executes the SAVE or the SAVE & EXIT commands, the persistence issue only affects the owned items.

 

DimensioneX simulates real life so, when a user logs off, the owned items drop to the floor and can be used by other characters. This behaviour is drastically different to that of single-user games, where everything is related to the only user and everything can be destroyed and reconstructed together with the user.

Nevertheless, DimensioneX helps users to have their items back along three levels of restore:

 

1. Save and Restore via the object’s unique ID.
   This system is fully automatic.
   How it works: When the game is saved, all owned object IDs are saved. When the user logs back in, she will re-obtain the same objects IF those objects are still unused by other characters and are not locked somewhere in container objects (closets, etc.), nor any event cancels this restore operation.
2. Save and Restore via the object’s type (AutoRestore).
   This system is fully automatic provided the game designer has consistently used the object type property to specify object types. This system can be disabled.
   How it works: When the game is saved, all owned object types are saved. When the user logs back in, if the restore based on unique ID fails (see above), then the system searches for a free object having a type matching that of the saved item. If also this search fails, it will search for an object with at least the same main type.
   Example: John owns an iron sword. He saves and exits, then logs back in. His sword is in use by another character now so the system searches for another sword of the same type (“sword.iron”). If this search fails he will search for objects of the same main type (eg. “sword.silver”, “sword.simple” will then match). If a positive match is found, the object is assigned to John.
3. Serialization/Deserialization.
   This system must be implemented by the programmer via two scripts: saveInfo( ) and restore( ) and it is similar to what happens in other languages (Java) for similar needs.
   For this system to work you should have implemented the following:
   1. A function that is capable of building objects starting from their type and, optionally, extra information that can change from different object types
   2. A serializing saveInfo( ) function that, based on the object’s type, can extract relevant information and serialize them into a string that is returned as a result. This string will be saved along with object’s type for later restore.
   3. A deserializing restore( ) function that, taking as input the desired object type and the saveInfo string generated by saveInfo( ) function, can deserialize the object and thus reconstruct it, possibly calling the item-creation function mentioned at the point a).

 

The following rules apply for game save:

• All players’ properties are saved in the player profiles’ database, under the key: “username_properties”. References to objects are converted in object IDs
• All objects ain inventory are saved in the player profiles’ database, under the key: “username_items”.
• For each object, the ID is saved.
• If the object has a TYPE, the TYPE is saved, too.
• If the user has performed SAVE & EXIT, object has a saveInfo( ) event attached, this EVENT is called. If its result is different than NULL, then it is saved.

 

The following rules apply for game restore:

• If a restore() event was defined, it is called with the object information which is contained in the saved game profile. The restore() event is supposed to restore the object by using the provided information. If the restore() event’s result is true, the system clears the saveInfo information it has in the saved profile and advances to the next object in the list, if not, the system attempts to use the Auto-Restore feature.
• For performing Auto-Restore on an object:
  • the system tries to search current world for an object with the same ID.
  • If TYPE information was saved, it will check against object TYPE too.
  • If a match is found, and the object can be moved, it is reassigned back to the player’s inventory.
  • If a match cannot be found, then the current world is searched for a free, moveable object with the same TYPE. If the operation succeds, the object is assigned to the player’s inventory.
  • If a match cannot be found, the system gives up and a message “cannot restore…” (or equivalent) is displayed.
  • The system then advances to the next object in the list.
• The Auto-Restore feature can be disabled. Use the worldnav.properties setting disableAutoRestore for this purpose.