Wartbed:Design/Map format
From Dark Omen Wiki
(→Internal WARTED Data Structures) |
(→Internal WARTED Data Structures) |
||
| Line 19: | Line 19: | ||
A map, or arena or theatre of war, consists of a battleground, which simply is a set of geometry and visuals, and an abstract collection of interconnected spatial nodes that describes where it is possible to go and how to get there. The map management classes are responsible for rendering ONLY, and performs no game logic, which is all strictly kept on the server side. | A map, or arena or theatre of war, consists of a battleground, which simply is a set of geometry and visuals, and an abstract collection of interconnected spatial nodes that describes where it is possible to go and how to get there. The map management classes are responsible for rendering ONLY, and performs no game logic, which is all strictly kept on the server side. | ||
| - | < | + | <table style="margin:1em; padding 0px; background-color:rgb(150,180,160);"> |
| - | namespace theatre | + | <tr> |
| + | <td><pre style="margin-left:1em; border:0px;">namespace theatre | ||
{ | { | ||
//struct Renderable {}; defined somewhere else | //struct Renderable {}; defined somewhere else | ||
| Line 56: | Line 57: | ||
void renderTroops( ListOfTroops troops ); // or something to this effect | void renderTroops( ListOfTroops troops ); // or something to this effect | ||
| - | }; | + | };</pre></td> |
| - | </pre></ | + | <td style="padding:2em;"> |
| + | If the only thing that mattered was to place geometry in 3D-space in the correct order all data could be stored as OGRE SceneNodes containing meshes or particle effects. However, we also need to store additional informations, such as state, etc, and rather than having two separate hierarchies for this all map entities are of specialised types, which contains the OGRE render pointers as well as game data. Therefore the main list o' all stuff is a vector of the most abstract type (MapEntity), and all specialised things in a map/level/field are also stored as their correct types in separate vectors. | ||
| + | |||
| + | Note that geometry is ONLY for decoration and have no bearing on game logic. For this--elevation calculations, pathfinding, LOS, etc--a structure of spatial nodes I call <code>Topology</code> is used. | ||
| + | </td> | ||
| + | </tr></table> | ||
The <code>TheatreOfWar</code> class in used by the server-side <code>Battle</code> class and the client-side <code>Game</code> classes. | The <code>TheatreOfWar</code> class in used by the server-side <code>Battle</code> class and the client-side <code>Game</code> classes. | ||
Current revision as of 17:52, 9 August 2009
| This article is a stub. You can help quell The Dread King by expanding it. |
Types of maps
Principally there are four classes of maps used in tactical war games:
- No terrain, perhaps models (f.i. space games)
- Terrain from height map, no Y-crossings (Myth)
- Terrain from height map and models, no Y-crossings (WH:DO*)
- Terrain from height map and models, Y-crossings (ST:TA)
- Terrain from model(s) only, possible Y-crossings
- * Dark Omen's visible map is a pure model, which however only has a decorative purpose. Internally height maps are used for all game calculations.
WARTBED will support height maps and models for terrain, but to accommodate all types of maps will not use this for game calculations. Instead a node matrix (a set of mutually linked nodes) will represent the arena internally. This serves both height map and pathfinding purposes. Each node will have attributes that affects events and movements in that node.
Internal WARTED Data Structures
A map, or arena or theatre of war, consists of a battleground, which simply is a set of geometry and visuals, and an abstract collection of interconnected spatial nodes that describes where it is possible to go and how to get there. The map management classes are responsible for rendering ONLY, and performs no game logic, which is all strictly kept on the server side.
namespace theatre
{
//struct Renderable {}; defined somewhere else
struct MapEntity {};
struct Terrain : MapEntity {};
struct Prop : MapEntity {};
struct Transparency : MapEntity {};
struct Animation : MapEntity {};
struct Effect : MapEntity {};
typedef pathfinding::NodeMatrix Topology;
struct Battleground
{
vector<MapEntity> all_entities; // Main storage
vector<Terrain> terrain; // subset; 1st render group
vector<Prop> props; // subset; 2nd render group
vector<Animation> animations; // subset; 3rd render group
vector<Effect> effects; // subset; 4th render group
vector<Transp> transparencies; // subset; 5th render group
//skybox, sun, moons, clouds, decorations?
};
}
class TheatreOfWar
{
Ogre::SceneManager scenemanager; //This might not belong here, thinking required
theatre::Topology topology;
theatre::Battleground battleground;
void renderTroops( ListOfTroops troops ); // or something to this effect
}; |
If the only thing that mattered was to place geometry in 3D-space in the correct order all data could be stored as OGRE SceneNodes containing meshes or particle effects. However, we also need to store additional informations, such as state, etc, and rather than having two separate hierarchies for this all map entities are of specialised types, which contains the OGRE render pointers as well as game data. Therefore the main list o' all stuff is a vector of the most abstract type (MapEntity), and all specialised things in a map/level/field are also stored as their correct types in separate vectors. Note that geometry is ONLY for decoration and have no bearing on game logic. For this--elevation calculations, pathfinding, LOS, etc--a structure of spatial nodes I call |
The TheatreOfWar class in used by the server-side Battle class and the client-side Game classes.
Movement, Pathfinding and Demands on Unit Data
Transcluded from Wartbed:Unit data/Movement capabilities
WARTBED Units movements are defined in a set of abilities, declared per-unit in their script file definitions:
| All units default to the negative on all abilities (i.e. can't move at all). Movement capabilities must explicitly be turned on. Units inherit the capabilities of their superclass (a wood elf inherits the same movement capabilities as the base elf it specialises), and if it shouldn't have an ability, it must be turned off explicitly (set to the negative). |
This design has the effect that different weights can influence the pathfinding calculations, f.i. the weight of difficult terrain will be greatly reduced for an unit with the landwalker movement capability. This is an elegant way of allowing crossing Y-paths and enable distinct differences in movement without requiring specialised pathfinding solutions.
