Wartbed:Design

From Dark Omen Wiki

(Difference between revisions)
Jump to: navigation, search
(→"Regimental tactical warfare")
(→Dependencies: Updated dependencies)
 
(25 intermediate revisions not shown)
Line 1: Line 1:
 +
<div style="float: right; margin-left: 3em;">__TOC__</div>
 +
<span style="font-size:large; font-weight: bold;">War And Regimental Tactics Battle Engine Deluxe (WARTBED) High-Level Design Document<br /></span>
 +
 +
[[image:Castle_Assembly.png|200px|left]]
 +
<i>''This document outlines the large-scale principles and design underlying the WARTBED tactical battles meta-engine. </i><br />
 +
{|
 +
|<span style="font-size:25pt;">'''⇐''' </span>
 +
|WARTBED: Building Blocks for Medieval Tactical Warfare Games
 +
|}
 +
<br clear="all" />
 +
 +
 +
<!-- MAIN CONTENTS -->
 +
<div style="padding:1em;">
==Overview==
==Overview==
 +
{{WARTBED-Infobox}}
At its highest level and end goal WARTBED is a meta-[[Ref:Engine|engine]] for tactical wargaming. More precisely, though, WARTBED is a [[ref:Framework|framework]] to automate a number of tasks related to this:
At its highest level and end goal WARTBED is a meta-[[Ref:Engine|engine]] for tactical wargaming. More precisely, though, WARTBED is a [[ref:Framework|framework]] to automate a number of tasks related to this:
Line 7: Line 22:
* A [[Ref:GUI|GUI]] system (currently implemented through the CEGUI middleware)
* A [[Ref:GUI|GUI]] system (currently implemented through the CEGUI middleware)
* Human-readable data file parsing
* Human-readable data file parsing
 +
* Audio layer (as of yet unimplemented)
* Scripting language support (as of yet unimplemented)
* Scripting language support (as of yet unimplemented)
* Network support (not yet implemented)
* Network support (not yet implemented)
-
''It is yet undecided whether game module support (Bright Portents etc) will be implemented as parts of the WARTBED code; WARTBED will be a library modules will use; or modules will be implemented in script languages using the WARTBED framework. ''
+
===Remaining design decisions===
 +
* How game modules (Bright Portents etc) should be implemented:
 +
** First option: As  '''internal parts of WARTBED''' framework itself.
 +
** Second option: Modules are '''stand-alone applications''' using WARTBED as a library modules will use.
 +
** Third option: Modules will be fully '''implemented in script''' languages using the WARTBED framework.
==="Regimental tactical warfare"===
==="Regimental tactical warfare"===
Line 21: Line 41:
* Unit and regiment ordering system
* Unit and regiment ordering system
* Suitable and flexible AI
* Suitable and flexible AI
-
 
+
</div>
 +
<div style="background:rgb(170,185,170);padding:1em;">
==Design principles==
==Design principles==
[[WARTBED]] is being designed according to a set of principles and assumptions.
[[WARTBED]] is being designed according to a set of principles and assumptions.
Line 33: Line 54:
|style="background:rgb(225,230,225);"|'''External dependencies are to be kept to a minimum'''
|style="background:rgb(225,230,225);"|'''External dependencies are to be kept to a minimum'''
* For major components (3D, physics, network, audio/multimedia) third party systems are preferred over native ones
* For major components (3D, physics, network, audio/multimedia) third party systems are preferred over native ones
-
* Otherwise, third party middleware are dissuaded and avoided to decrease dependencies. This includes Boost until a very good reason for including it emerges.
+
* Otherwise, third party middleware are dissuaded and avoided to decrease dependencies.  
|- style="vertical-align:top; outline:1px solid gray;"
|- style="vertical-align:top; outline:1px solid gray;"
|'''3.'''
|'''3.'''
Line 52: Line 73:
===Dependencies===
===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.
+
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 tested, stable and actively maintained solutions are acceptable.
-
* For '''3D graphics''' the open-source 3D API [http://www.ogre3d.org OGRE 3D] is being used.  
+
 
 +
<div style="margin:1em; padding:1em; border:1px dashed darkgray;">'''To be considered for inclusion, any 3rd party library must'''
 +
* be multi-platform for at least Windows, Linux and OSX
 +
* be fully stand-alone (atomically portable and not introduce additional dependencies)
 +
* be mature and stable
 +
* Be under a liberal, non-viral FOSS licence (f.i. LGPL, MIT, zlib)
 +
</div>
 +
<div style="margin:1em; padding:1em; border:1px dashed darkgray;">'''3rd party libraries currently in WARTBED:'''
 +
{| style="padding:2em;"
 +
| '''Purpose''' || '''Package''' || '''Version''' || '''Notes'''
 +
|-
 +
| style="padding:0.25em;" | ''3D Graphics:''
 +
| style="padding:0.25em;" | [http://www.ogre3d.org OGRE 3D]
 +
| style="padding:0.25em;" | 1.6 ("Shoggoth")
 +
|
 +
|-
 +
| style="padding:0.25em;" | ''Input:''
 +
| style="padding:0.25em;" | OIS (Open Input System)
 +
| style="padding:0.25em;" | 1.7
 +
|
 +
|-
 +
| style="padding:0.25em;" | ''In-game GUI:''
 +
| style="padding:0.25em;" | [http://www.cegui.com CEGUI]
 +
| style="padding:0.25em;" | 0.7.1
 +
| style="padding:0.25em;" | See ''[[wartbed:GUI evaluation|GUI evaluation]]'' and ''[[wartbed:GUI widgets|GUI widgets]]''
 +
|-
 +
| style="padding:0.25em;" | ''Networking:''
 +
| style="padding:0.25em;" | Boost::ASIO
 +
| style="padding:0.25em;" | 1.45
 +
| style="padding:0.25em;" | See ''[http://www.boost.org/doc/libs/1_46_0/doc/html/boost_asio.html Boost::ASIO]''
 +
|-
 +
| style="padding:0.25em;" | ''General-purpose:''
 +
| style="padding:0.25em;" | Boost
 +
| style="padding:0.25em;" | 1.45
 +
| style="padding:0.25em;" | See ''[http://www.boost.org Boost]''
 +
|}
 +
 
 +
<!-- * For '''3D graphics''' the open-source 3D API [http://www.ogre3d.org 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.  
* For '''input''' the open-source framework OIS (Open Input System) is being used. It comes with OGRE 3D for easy integration.  
-
* For in-game (in-framework) [[ref:GUI|GUI]] several frameworks are being considered. OGRE's preferred GUI is CEGUI, which however has proven difficult to initialise and use. See ''[[wartbed:GUI evaluation|GUI evaluation]]'' for more information.
+
* For in-game (in-framework) [[ref:GUI|GUI]] several frameworks are being considered. The current library is CEGUI, which is the preferred system in OGRE. See ''[[wartbed:GUI evaluation|GUI evaluation]]'' and ''[[wartbed:GUI widgets|GUI widgets]]'' for more information. -->
-
* Currently full-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.
+
''' Libraries considered for WARTBED:'''
 +
* Currently full-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 forward 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''' [http://www.nedprod.com/programs/portable/nedmalloc nedmalloc] is being evaluated. It is used internally in OGRE and is highly speed- and anti-fragmentation efficient under random usage.  
* For '''memory management''' [http://www.nedprod.com/programs/portable/nedmalloc 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.
+
* For '''audio''' libraries being avaluated, see [[Wartbed:Architecture/Audio|Audio evaluation]].
-
* [http://www.boost.org Boost] is currently not included in WARTBED.
+
* For '''networking''', Boost::ASIO is currently being used.
 +
* [http://www.boost.org Boost] is included in WARTBED, but sparingly because of certain overheads. Beyond ASIO, possibly the [http://www.boost.org/doc/libs/1_45_0/libs/filesystem/doc/index.htm Boost filesystem] may be used.
 +
* Though there is no immediate need for scripting as of yet, alternatives are being evaluated: see [[Wartbed:Architecture/Scripting|Scripting evaluation]].
 +
</div>
===Strictness of MVC organisation===
===Strictness of MVC organisation===
-
Had all code been locally written WARTBED could maintain ideal separation between the components. However, the Controller will have to react to purely cosmetic (user interface) user input and dispatch appropriate orders to View subsystems (f.i. selecting and outlining a particular unit). The controller will thus need knowledge about and access to View objects.  
+
:''See [[Wartbed:Architecture/MVC|Architecture/Model-View-Controller]]''
 +
WARTBED strictly separates the game rules and logic (the model) from the session and player management (the controller) and the visual and auditory representation of the game universe (the view). This is emphasises by the client/server architecture used where even local games are clients that connects to a local server, where the clients are strict views removed from any direct model access, and the server is the controller dispatching all communications between player input and underlying game data.  
-
Likewise OGREs built-in functions for line-of-sight, geometry collision and object picking will be utilised, which will validate the separation between Model and View.
+
Strictly speaking, WARTBED employs a two-tier controller architecture, where client is a controller with a view module and the server is a controller with a model module, wherefore the two controllers communicate.
-
 
+
-
We will see how this can be managed.  
+
===Coding standard===
===Coding standard===
Though not religious on the topic WARTBED is coded according to a set [[WARTBED/Code style|code style]] which is an adaptation of the [http://en.wikipedia.org/wiki/Indent_style#http://en.wikipedia.org/wiki/Indent_style#Allman_style_.28bsd_in_Emacs.29 Allman style].
Though not religious on the topic WARTBED is coded according to a set [[WARTBED/Code style|code style]] which is an adaptation of the [http://en.wikipedia.org/wiki/Indent_style#http://en.wikipedia.org/wiki/Indent_style#Allman_style_.28bsd_in_Emacs.29 Allman style].
 +
</div>
 +
<div style="padding:1em;">
-
==Model-View-Controller==
+
</div>
-
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.
+
<div style="background:rgb(170,185,180);padding:1em;">
-
<pre>
+
==Strict client/server game architecture==
-
+-----------------------------------+
+
{placeholder text ...}<br>
-
|              Model              |
+
WARTBED intended to be strictly client server to the extent that even single player games entail the game being a front-end to a local server.<br>
-
+------------------------------+--+-+
+
-
              ^      The model !  ^
+
-
              |      can send  !  |
+
-
              |      messages  !  |
+
-
The controller |                !  | The View can
+
-
issues orders  |                V  | read the Model
+
-
+--------------+-+ +---------------+--+
+
-
|  Controller  | |      View        |
+
-
+----------------+ +------------------+
+
-
</pre>
+
-
===Model and View===
+
'''Pros:'''
-
As example, assume a game class "Ship":
+
* item
-
<pre>
+
'''Cons:'''
-
//-------------------------------------------------------------------------
+
* Item
-
// Basic classes: f.i. in (made-up file) "MVC_base.h"
+
{...placeholder text}
-
//-------------------------------------------------------------------------
+
</div>
 +
<div style="padding:1em;">
 +
==Graphics specification==
 +
{{see|Wartbed:Design/Map_format}}
-
typedef shared_ptr<Message> MESSAGE;
+
* The base measurement unit is 1 meter. All 3D graphics are designed with 1 unit == 1 meter.
-
typedef std::set<Represenation *> REP_SET;
+
</div>
-
 
+
[[category:WARTBED]]
-
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 );
+
-
    }
+
-
};
+
-
</pre>
+
-
: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.<br><br>
+
-
 
+
-
<pre>
+
-
//-------------------------------------------------------------------------
+
-
// 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
+
-
};
+
-
</pre>
+
-
: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.<br><br>
+
-
 
+
-
<pre>
+
-
//-------------------------------------------------------------------------
+
-
// 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 ); }
+
-
}; 
+
-
</pre>
+
-
: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).
+
-
 
+
-
==Graphics spefification==
+
-
 
+
-
* The base measurement unit is 1 meter. All 3D graphics are designed with 1 unit == 1 meter.
+

Current revision as of 19:13, 10 March 2011

Contents

War And Regimental Tactics Battle Engine Deluxe (WARTBED) High-Level Design Document

This document outlines the large-scale principles and design underlying the WARTBED tactical battles meta-engine.

⇐ WARTBED: Building Blocks for Medieval Tactical Warfare Games



Overview

For a general overview, see the WARTBED Design Document
For an overview of the WARTBED technical architecture, see the Architecture document

For in-depth view of specific topics and aspects, see

WARTBED

 0.1 "Clausewitz"
0.2 "Jomini"


WARTBED Codenames

At its highest level and end goal WARTBED is a meta-engine for tactical wargaming. More precisely, though, WARTBED is a framework to automate a number of tasks related to this:

  • 3D graphic of contemporary standards (implemented through the OGRE middleware)
  • Input bindings and input handling (where raw input hardware is accessed through the OIS middleware)
  • Flexible camera handling suitable for a wide spectrum of strategy game styles
  • A GUI system (currently implemented through the CEGUI middleware)
  • Human-readable data file parsing
  • Audio layer (as of yet unimplemented)
  • Scripting language support (as of yet unimplemented)
  • Network support (not yet implemented)

Remaining design decisions

  • How game modules (Bright Portents etc) should be implemented:
    • First option: As internal parts of WARTBED framework itself.
    • Second option: Modules are stand-alone applications using WARTBED as a library modules will use.
    • Third option: Modules will be fully implemented in script languages using the WARTBED framework.

"Regimental tactical warfare"

What being a framework for implementing tactical regimental warfare games more specifically means is providing a number of standard formats (and data converter to these formats):

  • A unit and regiment ability and statistics set capable of accurately represent most games, periods and battle types.
  • A regiment representation system capable of handling several individual units organised into formations (which can consist of other regiments), and formatted movement (manoeuvres) of these.
  • Battle arena (battlefield) description
  • Campaign definition and flow handling
  • Unit and regiment ordering system
  • Suitable and flexible AI

Design principles

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
  • For major components (3D, physics, network, audio/multimedia) third party systems are preferred over native ones
  • Otherwise, third party middleware are dissuaded and avoided to decrease dependencies.
3. The system is divided into a Model-View-Controller design layout to decouple dependencies.
  • The MVC design structure is interpreted and adhered to as strict as possible (within reason).
  • 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 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.
  • Data files are as a rule to be written in as human-readable a format as possible (i.e. not XML). Currently (the unimaginatively named) Script V2 is used.

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 tested, stable and actively maintained solutions are acceptable.

To be considered for inclusion, any 3rd party library must
  • be multi-platform for at least Windows, Linux and OSX
  • be fully stand-alone (atomically portable and not introduce additional dependencies)
  • be mature and stable
  • Be under a liberal, non-viral FOSS licence (f.i. LGPL, MIT, zlib)
3rd party libraries currently in WARTBED:
Purpose Package Version Notes
3D Graphics: OGRE 3D 1.6 ("Shoggoth")
Input: OIS (Open Input System) 1.7
In-game GUI: CEGUI 0.7.1 See GUI evaluation and GUI widgets
Networking: Boost::ASIO 1.45 See Boost::ASIO
General-purpose: Boost 1.45 See Boost

Libraries considered for WARTBED:

  • Currently full-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 forward 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.
  • For audio libraries being avaluated, see Audio evaluation.
  • For networking, Boost::ASIO is currently being used.
  • Boost is included in WARTBED, but sparingly because of certain overheads. Beyond ASIO, possibly the Boost filesystem may be used.
  • Though there is no immediate need for scripting as of yet, alternatives are being evaluated: see Scripting evaluation.

Strictness of MVC organisation

See Architecture/Model-View-Controller

WARTBED strictly separates the game rules and logic (the model) from the session and player management (the controller) and the visual and auditory representation of the game universe (the view). This is emphasises by the client/server architecture used where even local games are clients that connects to a local server, where the clients are strict views removed from any direct model access, and the server is the controller dispatching all communications between player input and underlying game data.

Strictly speaking, WARTBED employs a two-tier controller architecture, where client is a controller with a view module and the server is a controller with a model module, wherefore the two controllers communicate.

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.

Strict client/server game architecture

{placeholder text ...}
WARTBED intended to be strictly client server to the extent that even single player games entail the game being a front-end to a local server.

Pros:

  • item

Cons:

  • Item

{...placeholder text}

Graphics specification

Further information: Wartbed:Design/Map_format
  • The base measurement unit is 1 meter. All 3D graphics are designed with 1 unit == 1 meter.
Retrieved from "http://wiki.dark-omen.org/do/Wartbed:Design"
Personal tools
communication