Piece-Of-Data - the core Class

In the interoperable process between a game and players, information transits. Games send what players can perceive and players send action description in return.

That information is structured as Pod (Piece-Of-Data) to be serialized, transmitted and rebuilt. a Pod includes raw data (sequence of characters, intergers, floating points values) and cand be a part of a tree structure of information.

Implementation:

• hackapy: pod.py

The example here are presented accordingly to the Python implementation (hackapy).

Pod Components

Pod is composed of 5 elements of fixed type:

• family: an string permitting to identifiate the type Pod. It is generally used as a key to make the other elements interpretable.
• status: an string describing the individual in the family, its current state.
• flags: a vector of integer values.
• values: a vector of floating points values.
• children: a vector of other Pod elements, sub-part of the Pod.

Accessor methods permit to get string elements as list : aPod.family(), aPod.status() and list elements: aPod.integers(), aPod.values(), aPod.children(). It is also possible to get a specific element is the lists with: aPod.integer(anInteger), aPod.value(anInteger), aPod.child(anInteger). To notice that, in HackaGames conventions element in list are indexed starting from 1. The first element is accessed with index 1: (aPod.integers(1) for instance).

Tree Structure

Children componnents of a Pod permits to defines complexe information structured as trees. For more information about tree data structure, Wikipedia is a good entrance point. Trees are very famous in Web technoligies for instance through HTML, XML, Json, Yaml etc formats.

In HackaGames most of the game states perceived by players (one Pod) are composed by several elements each one modeled by child Pod. For instance, a Board would be composed with Cells and Cells would welcome Pieces. The pieces would be the childrens of a Cell, Cells the children of a Board etc.

Interface versus Inheritance

HackaGames conventions prefer to separate game elements in the implementations from Pod. A Pod imposes specific structuration of elements (flags, values, ...). This structuration is not always efficient in the game mechanisms and not even readable in its implementations.

That for, we discourage developers from using inheritance of Pod in game and player implementations and we propose interface mechanisms to generate pods from the game elements and vice versa, when it is pertinent to do it. Game elements should include Pod interface methods:

    # Pod interface:
    def asPod(self, family="Pod"):
        # Should return a Pod describing self.
        # ...
        pass

    def fromPod(self, aPod):
        # Should regenerate self form a pod description
        # HackaGames conventions aim to return self at the end of the method.
        # ...
        pass