gametoolset
What is this?
This is a Lazarus package containing some abstract base classes which help dealing with (game) data.
Feature overview
- Baseclass for easy serialization from and to XML
- Event lists ("observers")
- Class managers ("factories")
- Baseclass for generic editor component development
- Object inspector with "user friendly properties" and the according registry
It is the core of the X³ Toolset, meaning gametoolset is developed with and for the X³ Toolset. I abstracted it from the x3toolset package as I saw that some of the classes could become useful in other projects too (and I was right).
Structure
As mentioned, these classes are quite abstract and have nothing to do with any specific game data at all. They are just a good basic to implement the handling of (game) data.
The core of the core is the TGTBaseClass. Most classes which contain game data derive from this one, as it serves powerful methods for xml serialization and some base stuff to work with observers and factories.
The xml serialization is based on the RTTI information which is generated by FreePascal during compiletime. So to reflect a new xml node, I just need to add a property to the class. Well, it's more the other way round. I add a property and it will be reflected during save to/load from xml.
Editing
Another important base class of the GT I often forget to mention is the editor base class. It works together with the LCL and provides a base to implement a graphical editor for a class which derives from TGTBaseEditable.
It provides plenty of methods to describe itself (tell what it is able to do, e.g. not all editors are capable of copying or undoing) and take actions form its surroundings, like, for example, the well known editing functionallities like cut, copy, paste, undo and redo or calls from the surrounding to add or remove custom controls in various panels.
These editors are registered during program launch so that other components of the application can access them.
Inspecting
The other way of editing an object is using the generic object inspector. This class is derived from the TTIObjectInspector the LCL provides. There are some improvements though.
There is a registry for properties where "user friendly" display names can be declared, for both properties and enum values. This makes the interface a lot better to use, as the user does not need to deal with "developerish" names like "GODStationSeedAmount", "soStationRaceConstraint" and "miOre" but sees the "fancy" names like "GOD seed station amount", "Station race constraint" and "Ore". There is also support for tooltip messages which may even improve the experience of inspecting objects.
As the object inspector is independent of the underlying object, it is usually the preferred method to edit them. Only for really complex objects one should implement a separate, more designed editor.
There is no need to use this editor though. If you do not need "fancy" property names, you can also use the default inspector.
Sessions
Another big thing which is implemented by the gametoolset is the session base class. It contains various multi-flavour methods which allow to design the session information in a very differentiated way.
As the session needs to be stored between program runtimes, the focus is set on loading and saving data. There are actually three ways a session can store its state. It can either use a binary stream, a xml file or store anything into a directory which is then wrapped up by the framework as a tar file. Whatever the session decides to do, the framwork adds an header to the file to recognize that kind of file in the future and verify it before the loading process starts. It may even compress the file if wished, which may be very efficient when storing to XML is used.
Virtual file system
Talking about files this topic is rather interesting too. The GT comes with a basic virtual file system and very abstract mount classes. The only specified mount the GT supplies is mounting a directory from the os' file system. In the x3toolset I derive from these mount classes to create mounts for the X³ game data archives.
There are also special file stream classes which deal with "heading" and "deheading" files transparently. They work like normal stream classes, but they take care of (de-)compression and header verification in an unified way.