Wartbed:WARTBED
From Dark Omen Wiki
(+Logo) |
(→Structure: Restructure, infobox with TOC-like links) |
||
| Line 14: | Line 14: | ||
==Structure== | ==Structure== | ||
WARTBED is designed according to a strict set of principles. It is structured to the Model-View-Controller layout, employs third-party middleware for major game engine features, but otherwise dissuades third-party dependencies. | WARTBED is designed according to a strict set of principles. It is structured to the Model-View-Controller layout, employs third-party middleware for major game engine features, but otherwise dissuades third-party dependencies. | ||
| - | |||
| - | |||
WARTBED defines a number of standard data formats. These are open and intended to be easy to modify. WARTBED also defines a game implementation structure where the highest level is a "module", which is an implementation of a particular game, which means a self-sufficient collection of maps, units, etc. Any module should contain one or several campaigns, consisting of a number of missions. | WARTBED defines a number of standard data formats. These are open and intended to be easy to modify. WARTBED also defines a game implementation structure where the highest level is a "module", which is an implementation of a particular game, which means a self-sufficient collection of maps, units, etc. Any module should contain one or several campaigns, consisting of a number of missions. | ||
| - | + | ||
| + | <div style="border:1px solid darkgray; margin:1em; padding:1em;"> | ||
| + | For a general overview, see the '''[[Wartbed:Design|WARTBED Design Document]]''' | ||
| + | |||
| + | For in-depth view of specific topics and aspects, see | ||
| + | <div style="padding-left:1em;padding-right:1em;"> | ||
| + | * [[Wartbed:Code style|Coding standard]] | ||
| + | * [[Wartbed:Files/Formats|File formats]] | ||
| + | * [[Wartbed:Files/Structure|File structure]] | ||
| + | * [[Wartbed:Framework|Framework reference]] | ||
| + | * [[Wartbed:Data structures|Internal data structures]] | ||
| + | * [[Wartbed:Design/Map format|Map format]] | ||
| + | * [[Wartbed:User interface|User interface]] | ||
| + | </div> | ||
| + | </div> | ||
==Interchangeability of data== | ==Interchangeability of data== | ||
Revision as of 15:46, 27 April 2009
Contents |
Wargame And Regimental Tactics Battle Engine Deluxe Code name for a regimental tactical real-time war game engine, in which Bright Portents will be implemented. WARTBED's second stage includes the possible or actual support of more games, which will entail a name change to OMG-WARTBED (Open Multi-Game Wargame And Regimental Tactics Battle Engine Deluxe).
- See also Power goals
- Suggest and discuss features in Brainstorming
Overview
Intention
(OMG-)WARTBED is intended as a framework of enough flexibility to implement and capture varying and distinctive real-time tactical (RTT) games. There are three explicit goals of WARTBED: Firstly to reimplement certain older and seminal RTT titles that are problematic to run on modern operating systems. Secondly to allow easy creation of new and/or novel RTT modules. Thirdly, to allow "what-if" scenarios where units of different modules can confront each other.
Structure
WARTBED is designed according to a strict set of principles. It is structured to the Model-View-Controller layout, employs third-party middleware for major game engine features, but otherwise dissuades third-party dependencies.
WARTBED defines a number of standard data formats. These are open and intended to be easy to modify. WARTBED also defines a game implementation structure where the highest level is a "module", which is an implementation of a particular game, which means a self-sufficient collection of maps, units, etc. Any module should contain one or several campaigns, consisting of a number of missions.
For a general overview, see the WARTBED Design Document
For in-depth view of specific topics and aspects, see
Interchangeability of data
WARTBED is aware of all installed modules, and missions and campaigns can require other modules to be installed when running. Thus missions and campaigns can use data of other modules. The most interesting aspect of this is allowing multi-player confrontations of units from different modules on various maps. Any such cross-over setting requires all involved parties to have the required data installed.
High-level TODO-list
- A network system should be designed. For this suitable libraries should be located and existing projects should be investigated, for instance Glest and the Spring project. There is a lobby for Spring (SpringLobby) done in wxWidgets that might be of use.
