Jump to content

/gluon/engine/replay

From KDE Community Wiki
Revision as of 16:01, 30 March 2012 by Vsrao (talk | contribs) (Idea: Support 'replay' options in Gluon.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Enabling replays:

Two approaches come into picture for this feature:

1) Absolute method: Saving complete information about all the objects, along with timestamps of respective events. And all of this is simulated again through the game engine. In Gluon, this can be probably be implemented by mapping all the attributes of objects, instantiating when required. According to the timestamps, the attributes are changed, and the simulation engine maps them as required, thus creating a replay.

2) Deterministic solution: This approach takes into consideration that a game is more or less deterministic. Here, only necessary states are stored. This would mainly be external inputs by the user, with the timestamp. The game is set to behave in a certain way, and this is taken advantage of. The properties and movements of objects are governed by set rules, so the replay looks exactly the same.

However, since Gluon is a creator(this is stated, to be compared against standalone games), APIs need to be generic enough to handle multiple types of games. So, APIs are provided so the developers don’t have to start from scratch.

Depending on the nature of games, the developers can be given a choice between the two methods, since the 1st works quite elegantly with small games/small timeframes.

Implementing the methods:


1) Absolute method: Here, the developer is asked to specify a time interval for the game to record changes. He/she may also be asked to specify a list of objects that are to be recorded within sub-scenes in the game. The engine records the states of the objects at each interval. Since this method saves attributes at each interval, user-inputs and changes aren’t recorded. The implementation of this method is straightforward. The obvious drawback though, is the size of the save-file. It proves to be quite big.

2) Deterministic way: This method aims at reducing the size of the save file. However, this requires the knowledge of rules that the game follows; thus enabling a deterministic approach. The developer can be asked to provide a set of rules, with details regarding which attributes are affected with each input of the user. Rules that govern the relative positions of objects are specified too. To take this further, an algorithm can be implemented, to make associations based on a few rules given, to make it easier. A simple example: Position ObjectofClassA affects ObjectofClassB: On collision, ObjectofClassA is destroyed. This can be be applied to all objects of classes A & B. Following such a path, only user-inputs need to be recorded. This would also require the developer to specify in the rules, when new objects are instantiated, with their attributes. Such a system would greatly reduce the amount of data saved.