Wartbed:Design
From Dark Omen Wiki
Contents |
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
|
3. | The system is divided into a Model-View-Controller design layout to decouple dependencies.
|
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 written in ANSI C++ without proprietary extensions (f.i. MSVC++ extensions). STL containers are preferred for storage and data management throughout, unless for very specific reasons. |
6. | WARTBED is intended to be data-driven to as far en extent as possible.
|
Dependencies
External and third party dependencies are being avoided. Nonetheless, some aspects of a modern game system are impractical or impossible to produce in-house. For such, open-source, free-licensed (Free or LGPL, but not GLP), well testedm stable and actively maintained solutions are acceptable.
- For 3D graphics the open-source 3D API OGRE 3D is being used.
- For input the open-source framework OIS (Open Input System) is being used. It comes with OGRE 3D for easy integration.
- Currently dull-scale physics support isn't needed. The physics required consists of gravity, wind and trajectories, which can be sufficiently simulated in native code (air/liquid pressure variance, medium drag etc is unnecessary, and still there is no reason for ragdoll animation or fprward kinematics). Candidates would be the Newton framework, ODE (Open Dynamics Engine) or Bullet (preferred due to licencing), all have existing OGRE integration modules.
- For memory management nedmalloc is being evaluated. It is used internally in OGRE and is highly speed- and anti-fragmentation efficient under random usage.
- No system has yet been chosen for networking.
- Boost is currently not included in WARTBED.
Coding standard
Though not religious on the topic WARTBED is coded according to a set code style which is an adaptation of the Allman style.
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.
+-----------------------------------+ | Model | +------------------------------+--+-+ ^ The model ! ^ | can send ! | | messages ! | The controller | ! | The View can issues orders | V | read the Model +--------------+-+ +---------------+--+ | Controller | | View | +----------------+ +------------------+
Model and View
As example, assume a game class "Ship":
//------------------------------------------------------------------------- // Basic classes: f.i. in (made-up file) "MVC_base.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 ); } };
- Notice that the Entity interface (abstract base class) doesn't know anything about the specifics of its representations. Also notice that it is required of any Representation to register itself with its Entity.
//------------------------------------------------------------------------- // Example Entity (model) class, f.i. in "Ship.h" //------------------------------------------------------------------------- #include "MVC_base.h" struct Ship : Entity { VECTOR3 position; // Example game long hull_points; // object data };
- As can be seen, for a Model-layer class, in this instance "Ship", being an Entity is fully non-intrusive. The effect is that it can now send messages to any registered representations.
//------------------------------------------------------------------------- // Example Representation (view) class, f.i. in "game_display.h" //------------------------------------------------------------------------- #incluide "Ship.h" struct ShipRepresentation : Representation { Ship const *pShip; OgreSceneNode *pNode; ShipRepresentation( Ship const *pShip ) : Representation(pShip), pShip(pShip) {} void receiveMessage( MESSAGE &msg ) {} void update() { pNode->setPosition( pShip->position ); } };
- A specialised representation needs, however, to implement the receiveMessage() function, and must pass an Entity to the superclass constructor. Also note that the ShipRepresentation stores a (const) pointer to its associated Ship object: Representations can see and read its Entity (but not alter it).
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).