If an entity has this trait, specified units are able to garrison (be contained) within it.

"Garrisoned" is a generic term for any entity that is being contained within another entity. This could include units garrisoned in a building, troops being transported by a ship, a Relic being carried by a Healer, or even inventory items in RPG-style mods.

Note: A garrison flag will normally appear over an entity when entities are garrisoned inside it.

Note: We don't specify a Garrison Action in this case, although the usual circumstances for Actions do apply for Garrisoning (a unit has a Garrison cursor, a Garrision GUI button, etc). Instead we assume that any entity could potentially be garrisoned ... it's a matter of whether the entity it's trying to garrison in will let it. That's what these attributes specify.

Example:

        <Traits>
  		<Garrison>
  			<Max>4</Max>
    			
  			<List>Infantry, Support</List>
  			<EjectHealth>0.1</EjectHealth>
    			<BuffHeal>2</BuffHeal>
  			
  			<PropPoints>PropBattlement1, PropBattlement2</PropPoints>
    			<PropList>Infantry Javelinist, Infantry Slinger, Infantry Archer</PropList>
  			
  			<AutoGarrison>Infantry, Female Citizen</AutoGarrison>
  		</Garrison>
  	</Traits>

Example Description:

  • The structure can garrison 4 infantry (foot Citizen Soldiers) and support (Female Citizens, Traders, etc) units, assuming that each costs 1 Population.
  • If it gets damaged to 10% health, they're automatically ungarrisoned.
  • Garrisoned units heal +2 HP/sec faster than normal.
  • Only ranged infantry will appear at this entity's prop points.
  • If the player rings the Town Bell, entities will garrison in this structure if free.

Max

BRIEF DESCRIPTION :: The number of "garrison slots" in the entity.

Not yet implemented. The property is implemented in XML, but not used as yet.

This attribute determines the maximum number of entities that can be garrisoned in this entity. Note that it isn't based on just the number of entities, but the Traits.Population.Sub attribute of each entity.

So if an entity costs 2 Population, it also occupies 2 garrison slots when garrisoned.

An additional property, Traits.Garrison.Curr is initialised when an entity is created (almost always starting with an initial value of zero). It stores the current number of this entity's "garrison slots" which are currently occupied.

List

BRIEF DESCRIPTION :: A list of the entities or categories of entities that can be garrisoned in this entity.

Not yet implemented.

If an entity isn't covered by this list, it can't be garrisoned in this entity.

See the Traits.Id traits for lists of valid names for this list.

EjectHealth

BRIEF DESCRIPTION :: Percentage of hitpoints that triggers ejection of garrisoned entities.

Not yet implemented.

If an entity has this attribute, if it suffers too much damage, all garrisoned entities will be automatically ungarrisoned. It cannot be regarrisoned until the damage is repaired past this % tolerance level (range 0..1).

BuffHeal

BRIEF DESCRIPTION :: Increases health regeneration of garrisoned units.

Not yet implemented.

If an entity has this attribute, the Traits.Health.Regen of the garrisoned entities is modified by the specified amount.

PropPoints

BRIEF DESCRIPTION :: List of prop points (sockets) on the actor which will be used as prop points for garrisoned entities.

Not yet implemented.

If the name of a prop point (eg PropHead) from the entity's Actor attributes is listed here, then if an entity is listed in the Traits.Garrison.PropList and is garrisoned, it will appear attached to the entity at this node location.

Other than being able to move, the propped entity will retain its normal abilities (it will fire ranged attacks at opponents, take damage from attacks, and so on).

Note: As with Traits.Garrison.Max, an entity will occupy a number of prop points equivalent to its Traits.Population.Sub. For example, siege weapons are much larger, therefore need more room, therefore need a higher Traits.Population.Sub.

PropList

BRIEF DESCRIPTION :: List of garrisoned entities that will appear at the entity's socket (prop point) positions.

Not yet implemented.

If an entity is in this list, it will appear at a Traits.Garrison.PropPoint (if one is available) when garrisoned, instead of being hidden inside the parent entity.

If it can attack from this distance, it will attack opponents in range.

AutoGarrison

BRIEF DESCRIPTION :: List of the unit types (see Traits.Id) that will automatically garrison inside this entity when its Town Bell is rung.

Not yet implemented.

An entity doesn't have a Town Bell unless this attribute has a value.

Notes: Visible Garrisoning

Implementation: Graphics 10-20 hours. AI 1 or 2 days (substantially less without walking on walls).

Not yet implemented.

Prop Points

http://wildfiregames.com/misc/overview.jpg

Overview of the power of propping.

0 A.D. is already speced to feature an attachment system, where props can be attached to other objects (weapons in the hands of units, helmets on their heads, eyecandy on structures).

This same principle can be used to attach units to the decks of ships and buildings. We can use this to make units stand on battlements, position animals in corrals, etc.

A "prop point" is one of these predefined positions on the parent object, where a unit of a certain type will appear if garrisoned. They are also called "sockets" or "nodes".

Rules of Propping

http://wildfiregames.com/misc/buildings.jpg

Units on buildings.

http://wildfiregames.com/~gamedesign/Level1Images/garrison/scr_koh_0008-sml.jpg http://wildfiregames.com/~gamedesign/Level1Images/garrison/scr_koh_0053-sml.jpg

Units on buildings in Knights of Honour.

Most entities that can be garrisoned also have a number of preplaced slots for propping garrisoned units (typically about a fifth of its garrison capacity).

  • A garrisoned unit is attached to a prop point and made visible if:
    • There is an available slot.
    • The unit is of a compatible type for this building/ship.
    • It is the strongest compatible unit out of those that are garrisoned. Ranged units have a higher priority than melee units.
  • Any garrisoned units not at prop points are concealed inside (assumed to be inside the building or below deck). A garrison flag indicates that the building is garrisoned.
  • Propped units cannot be selected. Selecting just selects the building/ship as a whole.
  • Giving a command to the building/ship commands any propped units that can follow that command (for example, specifying a target for them to attack, if close enough). Specifying the building/ship's stance will instruct all propped units to also use that AI stance.
  • When propped, the AI controls the unit's behaviour. A propped unit on a Field gathers Food, for example. If a unit is capable of attacking opponents at range, it will do so. If it has nothing to do, it will idle.
  • Units that are garrisoned but not propped can't actually do anything. So for a unit to harvest a Field, or for a Merchantman to carry a Trader on a naval trade route, the necessary unit must occupy a prop point.

* No building has intrinsic attack capabilities. They are dependent upon the ability of propped units to attack opponents.

  • Propped units will swap slots to maximise their range, but otherwise cannot move from their slot.
  • If a unit is damaged to a significant degree, then if an eligible unit with much higher hitpoints is waiting for a vacant prop point in the building, they will swap positions so that the weakened unit returns to the safety of the building.
  • Propped units tend to have certain bonuses when propped (such as improved armour or an elevation bonus). This is dependent upon the building's/ship's attributes.
  • Propped units still retain their passive abilities; they are effectively just displaced in 3D space and taken out of player control. Their LOS will push back Fog of War, their Auras will affect units in range, and so forth.
  • Opponents pick their targets (the propped units, or the building/ship itself) based on their own AI awareness of their strengths. They will first launch attacks against whichever target they are most effective, and can reach.
  • Opponents must be able to reach a target in order to attack it. Since propped units are typically elevated off the ground, melee units are typically only able to attack the parent building/ship.
  • If one gets killed, the next strongest compatible unit (if any) from below will replace him, and so on. A prop point is only empty when there are no compatible units left inside.
  • When all units at prop points are killed, with no other targets left the opponent will focus all his attention on attacking the building. Note that units non-compatible for occupying prop points could still be garrisoned in the building at this time. They are not damaged when the building is attacked.
  • Buildings will typically auto-ungarrison any garrisoned units when damaged to a certain level. They cannot be regarrisoned until repaired.
  • Buildings are vulnerable to capture if they do not contain garrisoned units.

Propping of Ships

http://wildfiregames.com/misc/ships.jpg

Units on ships.

http://wildfiregames.com/~gamedesign/Level1Images/garrison/MDHafer-shipscale-various001-sml.jpg AoM Mockup of approximate scale of ships, siege and units for 0 A.D., by Michael Hafer.

http://0ad.wildfiregames.com/~art/mythos/reference/MDHafer-shipscale-fullsize001.jpg AoM Mockup of approximate scale for a 0 A.D. Trireme, by Michael Hafer.

http://wildfiregames.com/~gamedesign/Level1Images/garrison/aaa-sml.jpg AoM Alpha Ships 1. http://files.heavengames.com/aom/albums/es2001/aab.jpg http://wildfiregames.com/~gamedesign/Level1Images/garrison/aab-sml.jpg AoM Alpha Ships 2. http://wildfiregames.com/~gamedesign/Level1Images/garrison/aac-sml.jpg AoM Alpha Ships 3. http://files.heavengames.com/aom/albums/es2001/aai.jpg http://wildfiregames.com/~gamedesign/Level1Images/garrison/aai-sml.jpg Another large ship -- note raised sail; we could do this when the ship stops moving.

Ships are basically buildings that the player can move around on bodies of water. All the standard rules for garrisoning apply. There are, however, a couple of important differences for ships:

  • A ship that is ungarrisoned reverts to gaia control (neutral, not controlled by anyone, sitting duck). Garrisoning units in a ship transfers control of it to that player. A player could therefore capture an enemy ship by killing its crew, getting close enough to ungarrison, and transferring one or more of his own crew into the ship. (When garrisoning the first unit, the ship gets a marginal boost to health to restore it to above auto-ungarrison health, otherwise it would just kick out the new units.)
  • Units cannot ungarrison onto water, so they can only be ungarrisoned onto land or another player ship. The ship can also be given a target location to ungarrison (such as a shore), and will move to that position and ungarrison.
  • When a ship auto-ungarrisons due to critical damage, the crew have nowhere to go, so are effectively destroyed. Without a crew, the ship reverts to gaia. The opponent can now choose to either keep attacking the ship and sink it, or transfer some of his crew to take control of it.
  • Unlike buildings, some ships do have a personal means of attack ... the sea ram. If a ship is given the order to attack, and has any units aboard with ranged attacks, it will close to the range of the shortest-ranged unit aboard. If it has no ranged units, it can only attack with the ram. Since the ram cannot reach propped units, it can only attack the ship's hull. Ram attacks can also be forced by double-right-clicking the target.

Things that Won't Happen

The following have been declared technically infeasible by the Programming Department:

  • dynamic Melee Battles (units boarding a ship and visibly attacking units aboard another ship in melee),
  • units walking freely on decks,
  • controlling individual units on the deck,
  • units visibly walking between ships (planks, ladders, etc).

Backburner: Units on Walls

http://wildfiregames.com/misc/wall.jpg

An extension to be added in the Expansion Pack, once Visible Garrisoning is comfortably implemented and we know the engine inside out.

In this more advanced suggestion, Ranged Infantry units can be garrisoned to Walls as with most buildings (one unit per wall segment: one Garrison slot and one Ranged Infantry Prop Point), and the above rules for garrisoning any building apply. However, with walls we are able to do one thing differently ...

Once garrisoned, the unit will appear on top of the wall and patrol along its length along a pre-defined track. Once it encounters an obstacle (Wall Tower, Gate, end of the Wall) or has travelled a certain distance, it will turn back and continue the circuit.

They'll basically act like paper targets on a firing range, moving back and forth along a track (except that they will be realistically animated and pointed in the right direction).

There will be two 'lanes' in the wall, one for left-to-right traffic, the other for right-to-left traffic. Possibly also a 'parking lane' for units that are standing still.

The walls will be quite thick, but units will still be to scale while on walls.

As with ships and buildings, units can't be selected while garrisoned on walls. If they encounter enemies on the ground while on the walls, they will stop patrolling and open fire on them.

To ungarrison units on walls, ungarrison the Wall through the GUI in the normal way and the unit will appear back on the ground adjacent to the wall.

Because Walls will soon look too damaged to be feasibly walkable, once this level of damage is reached, any garrisoned units will automatically ungarrison from the Wall.

Last modified 9 years ago Last modified on Feb 23, 2008 3:18:58 AM