Model Design Documentation
This is the article/part of the Architecture_Documentation referring to the internal representation of model. Model contains the essential engine structures that are used to represent the game world. The picture below shows the most important model elements and their relationships.
Note: Elevations have been removed from FIFE. Maps now directly include layers.
Model is the "root point" for the game world data. Model contains a metamodel and list of maps.
Metamodel is the abstraction of model data. When new world is created, things get instantiated from metamodel space into model space. For concrete example, see the definition of Object. Actual metamodel space definitions are done in the datasets. Metamodel can contain any number of datasets.
Dataset is a container for object definitions. When objects are defined with xml, dataset is the xml file where objects are distributed. Datasets can be re-used from one game (or game level) to another, and they can even be design in separation to any game. As a concrete example, one dataset could e.g. contain definitions for jungle tiles & related objects (like monkeys and palm trees). Datasets can be hierarchical so that one dataset refers to definitions found from other dataset.
Object is abstract representation of instances shown on map. As an example, we can have Monkey object that defines what is a monkey (what monkey looks like, what are monkeys attributes and what kind of actions it supports). In the game, we can istantiate monkey objects to the world. This basically means that monkey is created to some map location, and it can be commanded using the related actions. All the instances shown on map are based on objects. This means e.g. all the tiles, buildings, heros and monsters. This also means that you can treat them using the same methods, e.g. you can command monster to attack or tile to disappear.
Objects have one associated AbstractPather instance. This instance defines the path finding algorithm that is used when object instances are navigating in the game world.
Actions represent things that object instances can do. E.g. monkey can run, stand or climb to trees. Animations contain also handles to activity representations meaning e.g. animations and sound clips. There is no direct dependency from action definition to concrete representations, instead abstract ids are used. These ids are used by the view module.
Map is the entry point to game world itself. Game world is divided into layers.
Maps are divided into layers. Layer is a space into which instances are placed on the elevation. Layers may contain different kinds of cellgrids to divide their space in different ways ("tiling"). Visually, Layers are viewed "stacked" on top of each other.
Note: The picture here refers to an outdated "Elevation" concept. "Elevation" and "Map" should now be considered synonymous.
Cellgrids define how the space inside the layer is divided. They also define the used coordinate system inside the layer. The following lists the available cellgrids
Square cellgrid is formed from square shapes thus resulting the ordinary coordinate system. X coordinates run from left to right, while y coordinates run from top to bottom. Coordinate system does not have any limits.
Hex cellgrid is formed from hexagon shapes. X coordinates run from left to right with a twist that even odd row is intended a bit to the right. Y coordinates run from top to bottom. Coordinate system does not have any limits.
Instances are instantiations of objects. Essentially almost everything visible on the game world is an instance; tiles, buildings, plants, characters and so on.
Game scripts can listen instance activities using InstanceListener interface.
When object is instantiated, it gets a location. Location identifies the spot into which instance is placed in the game world.