Wartbed:Data structures

From Dark Omen Wiki

(Difference between revisions)
Jump to: navigation, search
(OGRE Rendering engine structures)
(Future extendibility)
Line 96: Line 96:
|'''Mor'''||Morale ||  
|'''Mor'''||Morale ||  
|}
|}
 +
 +
==Future extendibility==
 +
Let's face it, WARTBED will (hopefully) grow to include more games over time, which will mean adding additional features and rules. At the same it should continue to support existing modules without they too needing to be updated. Thus, all game rules should be kept in some kind of set where they can be toggled. All additional rules after the first stable release should also default to OFF so older modules will not be affected by them.
 +
 +
Perhaps it is possible to device some clever add-on or scripting systems for rules, so that modules will register themselves and their rules with WARTBED. Worth contemplating. [[User:Mikademus|Mikademus]] 20:24, 2 August 2008 (UTC)
==Game engine structures==
==Game engine structures==
Line 104: Line 109:
{{see|Rendering Engine Structures}}
{{see|Rendering Engine Structures}}
Overview and discussion of the rendering engine data structures.  
Overview and discussion of the rendering engine data structures.  
-
<!--
 
-
==<tt>wartbed</tt> namespace==
 
-
 
-
enum FLOCKING_BEHAVIOUR
 
-
{
 
-
    FLOCK_none    = 0,
 
-
    FLOCK_mill    = 1,
 
-
    FLOCK_formate  = 2,
 
-
};
 
-
 
-
This enum will determine which algorithm that controls the immediate movement behaviour of an unit.
 
-
 
-
enum UNIT_STATE
 
-
{
 
-
    STATE_normal    = 0,
 
-
    STATE_routing  = 1,
 
-
    STATE_fleeing  = 2,
 
-
    STATE_inactive  = 3,
 
-
    STATE_destroyed = 4,
 
-
    STATE_gone      = 4,
 
-
};
 
-
 
-
Both "destroyed" and "gone" (left battle field) are the same for in-battle purposes.
 
-
 
-
enum TARGET_MODE
 
-
{
 
-
    TARGET_position,
 
-
    TARGET_unit,
 
-
};
 
-
 
-
Control enum for all targeting, which is relevant for orders.
 
-
 
-
struct Position;
 
-
struct Unit;
 
-
 
-
class Target
 
-
{
 
-
    TARGET_MODE target_type;
 
-
    union
 
-
    {
 
-
        mutable Position *pPos;
 
-
        Unit const *pUnit;
 
-
    }
 
-
 
-
public:
 
-
 
-
    Target( Position const &rPos ) : target_type(TARGET_position)
 
-
    {
 
-
        pPos = new Position( rPos );
 
-
    }
 
-
 
-
    Target( Unit const &rUnit ) : target_type(TARGET_unit)
 
-
    {
 
-
        pUnit = &rUnit;
 
-
    }
 
-
 
-
    ~Target()
 
-
    {
 
-
        if (TARGET_position == target_type)
 
-
            delete pPos;
 
-
    }
 
-
 
-
    Vector3 operator* () const
 
-
    {
 
-
        return (TARGET_position == target_type) ? **pPos : pUnit->getPosition();
 
-
    }
 
-
};
 
-
 
-
Might seem as a complex class for its purpose, but it will be very convenient for a uniform interface when issuing orders.
 
-
 
-
class Unit
 
-
{
 
-
    FLOCKING_BEHAVIOUR flocking_mode;
 
-
    UNIT_STATE state;
 
-
 
-
    Target target;
 
-
};
 
-
 
-
Very preliminary stub.
 
-
 
-
===<tt>orders</tt> namespace===
 
-
Sub-namespace to <code>wartbed</code>. Contains control structures and values for all orders that can be issued to units.
 
-
 
-
enum MOVE_ORDER
 
-
{
 
-
    MOVE_no_order      = 0,
 
-
    MOVE_to            = 1,
 
-
    MOVE_approach      = 2,
 
-
    MOVE_avoid        = 3,
 
-
    MOVE_keep_distance = 4,
 
-
    MOVE_face          = 5,
 
-
    MOVE_continuous    = 0xF0000000,
 
-
};
 
-
 
-
enum HOLD_ORDER
 
-
{
 
-
    HOLD_no      = 0,
 
-
    HOLD_grounds = 1,
 
-
    HOLD_pursue  = 2,
 
-
};
 
-
 
-
enum ATTACK_ORDER
 
-
{
 
-
    ATTACK_no_order    = 0,
 
-
    ATTACK_await_charge = 1,
 
-
    ATTACK_at_will      = 2,
 
-
    ATTACK_charge      = 3,
 
-
    ATTACK_fire_missile = 4,
 
-
    ATTACK_continuous  = 0xF0000000,
 
-
};
 
-
 
-
enum FIRE_ORDER
 
-
{
 
-
    FIRE_no_order = 0,
 
-
    FIRE_hold    = 1,
 
-
    FIRE_at_will  = 2,
 
-
    FIRE_normal  = 3,
 
-
    FIRE_force    = 4,
 
-
};
 
-
-->
 
[[category:WARTBED]]
[[category:WARTBED]]

Revision as of 20:24, 2 August 2008

Contents

WARTBED Data Structures

Atm I (Mikademus) am using this article to jot down structures and ideas about the internal functioning of (OMG-)WARTBED. Please feel free to partake and discuss. Both the discussion page and this article can be used, use your judgement.

Unit characteristics

The Warhammer attributes

In Warhammer, units are defined by a set of attributes ranging from 1 to 10 (where humans average at 3).

Warhammer unit attributes
M Movement (in inches per turn)
WsWeapon Skill
BsBallistic Skill
SStrength (punching power)
TToughness (resistance to strength of attack == save against wounds)
WWounds (hit points, usually only 1)
IInitiative
AAttacks (# of attackes per turn)
LdLeadership (save against routing, fear etc)
Warhammer 40K adheres to this set too, but units there lack the Movement attribute and has a Sv (armour saving throw) as part of the set (in fantasy battle armour saving throw is contingent on which armour you equip the unity with).

While the Warhammer attribute set is tested and refined, there are two issues at hand. (1) WARTBED will be able to accommodate more games than "just" Dark Omen and those games might not easily lend to the Warhammer set; and (2) it might not be wise to use the Warhammer set straight off for reasons of IP rights (meh).

Issues and shortcomings with the Warhammer attributes

  • Stupidity in Warhammer is a racial attribute (a boolean switch). This could be better represented as an analogue value.
  • Fear: Warhammer system good: units can cause fear and terror; terror > fear; terrific creatures are unaffected by terror or fear and fearsome creatures feat terrific ones. We can generalise this to a fear attribute, which is usually zero, but in Warhammer, undead and trolls would have 1 ("cause fear") and dragons 2 ("cause terror").
  • Solidity. Units can be of different size. IIRC in Warhammer v3 or 4 push-backs were determined by comparing #wounds dealt in a round. In Dark Omen there are no push-backs. However, in 3D units could (should?) have weight.
  • Training: Some manoeuvres might be too difficult for certain units. Experience and leadership reflects these. Perhaps units could try difficult manoeuvres but need to pass both a leadership and stupidity test or be confused?
  • Which leads us to Leadership: the Warhammer notion is a gross simplification for the sake of making a table top game manageable. It subsumes things such as training, experience, discipline, psychological stability, cultural disposition and "anti-stupidity" (it all boils down (1) manoeuvres, (2) save against rout and (3) roll to rally). It reminds a bit of Black Adder's Lord Wellington who believes that leadership is all about shouting. Really, things like psychological stability, stoicism, fatalism, bravery, training, discipline and much more all would weigh in.
  • Other RTT games, such as Close Combat and Total War, includes other attributes not part of orthodox Warhammer, These include fatigue, morale and ammunition. Provisos for using these should be made, but these are types of attributes that shouldn't be necessary to be used. Having them optional would also allow difficulty and realism settings.

Suggested set

  1. Multiply the Warhammer values by 10, giving us a range of 0--100, with humans averaging at 30. This gives us more room to adjust values.
  2. Renaming certain (all?) attributes. If we assume that size equals strength, and size can be used as solidity, then S can be called "power" or "might" or something, and used for both weapon power and unit solidity.
  3. Add Fearsomeness as an attribute.
  4. Change Ld from being an kitchen-sink attribute to a bonus to the attributes below.
    1. Add Tactics attribute that represents unit level of training (manoeuvres and formations; resist pursuing)
    2. Add Steadfastness attribute that represents unit discipline and psychological stability (resistance against feat and routing; rallying) - basically anti-cowardice.
    3. Add Ferociousness attribute that represents an unit's disposition to charge and pursue - basically anti-discipline.
    4. Add Stupidity attribute - much better in game context than an "intelligence" attribute.
  5. Add optional attributes
    1. Stamina, recovery rate and fatigue
    2. Morale
    3. Ammunition - this rather belongs with the weapons definition and as a game play option than an unit attribute!

The attribute set

Suggested WARTBED unit attributes
Physical attributes
Mov Movement In game units per game time unit (meters/second?)
WSk Weapon Skill Melee prowess
BSk Ballistic Skill Missile accuracy
Pow Power Strength and weight
Tgh Toughness
HP Hit Points (wounds)
Ini Initiative
Att Attacks
Sta Stamina Endurance
Rec Recovery rate Reduction to fatigue/time unit
Fat Fatigue Tiredness
Psychological attributes
LdrLeadership Bonus to tests
TacTactics What manoeuvres can be performed
StdSteadfastness Resistance to fear, panic, rout etc
FerFerociousness Berserking etc
StuStupidity Risk of confusion etc
MorMorale

Future extendibility

Let's face it, WARTBED will (hopefully) grow to include more games over time, which will mean adding additional features and rules. At the same it should continue to support existing modules without they too needing to be updated. Thus, all game rules should be kept in some kind of set where they can be toggled. All additional rules after the first stable release should also default to OFF so older modules will not be affected by them.

Perhaps it is possible to device some clever add-on or scripting systems for rules, so that modules will register themselves and their rules with WARTBED. Worth contemplating. Mikademus 20:24, 2 August 2008 (UTC)

Game engine structures

Further information: Game Engine Structures

When making a game it is extremely important to as far as possible separate the "logic" from the "view" or "presentation" (what this means in simple terms is basically that the game should be able to run without graphics). If nothing else, a huge advantage of this is that the game can easily be ported to other rendering contexts (==platforms).

OGRE Rendering engine structures

Further information: Rendering Engine Structures

Overview and discussion of the rendering engine data structures.

Personal tools
communication