Wartbed:Data structures

From Dark Omen Wiki

Contents 1 WARTBED Data Structures 2 Unit characteristics 2.1 The Warhammer attributes 2.2 Issues and shortcomings with the Warhammer attributes 2.3 Suggested set 3 wartbed namespace 3.1 orders namespace

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.

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)
Ws	Weapon Skill
Bs	Ballistic Skill
S	Strength (punching power)
T	Toughness (resistance to strength of attack == save against wounds)
W	Wounds (hit points, usually only 1)
I	Initiative
A	Attacks (# of attackes per turn)
Ld	Leadership (save against routing, fear etc)

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.

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. a) Add Tactics attribute that represents unit level of training (manoeuvres and formations; resist pursuing)
5. b) Add Steadfastness attribute that represents unit discipline and psychological stability (resistance against feat and routing; rallying) - basically anti-cowardice.
6. c)Add Ferociousness" attribute that represents an unit's disposition to charge and pursue - basically anti-discipline.
7. d) Add Stupidity attribute - much better in game context than an "intelligence" attribute.
8. Change Ld from being an kitchen-sink attribute to a bonus to a, b, c and d.

wartbed 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.

orders namespace

Sub-namespace to wartbed. 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,
};