Save Me! news

This time 'round a lot of work went on behind the scenes in areas where you can not really show screenshots or videos. Nevertheless this is important work for any serious game and I required to continue working on the engine side in areas still in need of implementing.

Configuration and Saving

In a previous news post in the Drag[en]gine profile the Virtual File System has been discussed about. One of the possibilities is handling user specific data in a cleaner and multi-user friendly way. The Launchers (and the game code) have been changed to use this now properly. Configuration and various saved files end up now in one of the special directories designated for them by the Launchers. In short these are:

The game defines which path in the VFS maps to these. Hence in a game you just write to /config or /capture and it ends up in the proper place without you having to worry. For the user (and the Launchers) this allows to easily handle everything that is user specific playing games. Backing up configurations or saves is as simple as dealing with screenshots or videos you capture in a game. All in a tidied up fashion.

In addition the Console Launcher has been rewritten to use the same files as the GUI Launcher does while adding various command line arguments for power users. This way you can now switch between the two at any time obtaining the same result.

Save States

At first I had in mind to create a Module for handling save states. In the course of thinking up this system though it showed that games are too diverse to implement a reasonable Save Module that is easy to use and flexible enough for all case. Due to this the philosophy now is that the Scripting Module of your choice is responsible to provide the game developer with an adequate way of handling Save States.

The DragonScript module handles this by providing you with a File Reader and File Writer stream object. This is a low level approach where you write/read values one by one to and from files. You can write basic primitives like Integer or String as well as complex objects like Vector or Matrix. This is typically called Marshalling, Pickling or any other strange name programming languages invented for this process. This system is very flexible and still simple to use although low level in a way.

The Game classes have been now all rewritten to support Saving and Loading using these streams. It is implemented in a simple way which on one side is easy to use for me (and potential future co-developers) as well as modders or game-devs trying to do their own project. Right now Quick-Saving and Quick-Loading is supported. A full featured Load/Save Screen will be added later on. Using this system it is not difficult since it's just GUI work. As a matter of fact you are free to use saving any way you want as long as it ends up in your designated config directory somewhere (defaults to /config).

Handling default configurations is also simple. Just create in your game directory on disk a "config" directory with the default configuration files. The Launchers lay then the {user-game-directory}/config on top of it before running the game. If there is a user configuration it is used otherwise the default configuration shows up. Writing it ends up in the user directory anyways. Hence you do not have to worry about handling default configuration or first-run yourself.

Miscellaneous

Besides these a bunch of other tasks have been tackled.

For one the game scripts had a lot of experimental classes lingering around used during the development of the basic system. These have now been weeded out and replaced by proper Element Classes and XML Class Files. The Epsylon game uses the philosophy of using XML Class Files as much as possible. In a nutshell Element Classes in the game support all XML Sub-Classing. This allows artists to create a simple XML Class File that defines a new game class derived from an existing Element Class but specifying a bunch of Class Properties to customize it. This way no scripts have to be written for creating new object classes similar to existing ones but with different properties. What these Class Properties are can be defined individually in each Element Class and can be complex if required. The bed as seen in the last news post video for example is defined using XML Sub-Classing (interaction zones and so forth). This cleaning up has been required to better continue with the game.

Outlook

The next step is to work on engine areas which are not yet up to the level I want them to be. This includes a proper 2D graphic system as well as an overdue static lighting code. Furthermore I'm evaluating VSM and ESM for cube shadow maps as the current PCF version is heavy on the hardware. Also the sun shadows are not yet to my liking and I need to figure out something good for them too.