Wartbed:Design

From Dark Omen Wiki

Revision as of 19:51, 16 February 2009

Overview

WARTBED is being designed according to a set of principles and assumptions.

1. WARTBED is multi-platform and should be natively compilable on at least Win32, Linux and OSX.
2. External dependencies are to be kept to a minimum
   1. For major components (3D, physics, network, audio/multimedia) third party systems are preferred over native ones
      1. OGRE 3D is used for 3D graphics.
      2. OIS is used for input (OIS is also bundled with OGRE).
   2. Otherwise, third party middleware are dissuaded and avoided to decrease dependencies. This includes Boost until a very good reason for including it emerges.
3. The system is divided into a Model-View-Controller design layout to decouple dependencies.
   1. The MVC design structure is interpreted and adhered to as strict as possible (within reason).
   2. Game objects belong to the Model aspect of the MVC division, whereas their graphical and auditory representations belong to the View type. Input and unit ordering belongs to the Controller distinction.
4. The structural composition is indented to be as simple as possible. This does not mean that is must be simple, only that it shouldn't be over-complicated or over-designed, which is a common source of failure. Too great complexity means unmaintainable code, while too simple code is limiting, restrictive and incapable of representing a complex game.
5. WARTBED is intended to be data-driven to as far en extent as possible.
   1. Data files are as a rule to be written in as human-readable a format as possible. Currently, the poorly named Script V2 is used.

Model-View-Controller

Everything that can interact is a "game object" (or an "entity"). The WARTBED game objects exists in the abstract knows or cares nothing about their representation. In principle, since all game logic takes place in the Model layer, a WARTBED game can run completely in the abstract without any graphical or auditory output at all. Every Entity have one or more corresponding Representations that may read "their" Entity but not change it. Entities CAN communicate with their Representation(s) by sending messages. As example, assume a game class "Ship":

Model and View

//-------------------------------------------------------------------------
// Basic classes: f.i. in (made-up file) "CoreClasses.h" 
//-------------------------------------------------------------------------

typedef shared_ptr<Message> MESSAGE;
typedef std::set<Represenation *> REP_SET;


struct Entity
{
    mutable REP_SET representations;

    virtual ~Entity() {}

    void registerRepresentation( Representation *pRep ) const
    {
        represenations.insert( pRep );
    }
};


struct Representation
{
    virtual void receiveMessage( MESSAGE &msg ) {} = 0;

    Representation( Entity const &rEntity ) { init(rEntity); }
    virtual ~Representation() {}

    void init( Entity const &rEntity )
    { 
        pEntity->registerRepresentation( this );
    }
};


//-------------------------------------------------------------------------
// Example Entity (model) class, f.i. in "Ship.h"
//-------------------------------------------------------------------------

struct Ship : Entity
{
};


//-------------------------------------------------------------------------
// Example Representation (view) class, f.i. in "game_display.h"
//-------------------------------------------------------------------------

struct ShipRepresentation : Representation
{
    Ship const *pShip;

    ShipRepresentation( Ship const *pShip ) : Representation(pShip), pShip(pShip) {}

    void receiveMessage( MESSAGE &msg ) {}
};   

Controller

In real-time tactics games, no units are directly controlled by the player. Instead, all game objects are interacted with through orders. Therefore, the task of the Controller layer is to read input (from players, network or AI) and dispatch orders. In the very simplest terms the Controller is an order-dispatcher that is aware of the Model layer, but cares nothing about the View aspects. (This is however a little to clean to be practical since GUI interfaces bridge the distinction View and Controller).

Layout

 +-----------------------------------+
 |               Model               |
 +------------------------------+--+-+
               ^      The model |  ^
               |      can send  |  |
               |      messages  |  | 
The controller |                |  | The View can
issues orders  |                V  | read the Model
+--------------+-+ +---------------+--+
|   Controller   | |      View        |
+----------------+ +------------------+