DRAFT
Current situation
ATM, every unit stores order given to it by the player as mWork in UnitBase.
Sometimes unit needs to create a suborder to accomplish the primary order given to it. An example might be attacking: if unit is ordered to attack a unit which is not in the range of its weapons, then the unit temporarily sets it's mAdvanceWork to WorkMove thus creating a suborder to move closer to the target unit.
Proposal
Put information specific to one order into it's own class Order.
The Order class would store its type as well as a suborder (which might be null).
The types might probably be same as WorkType (we could use same enum).
There would be subclasses of Order, one per each type (e.g. OrderMove, OrderAttack, OrderPatrol etc).
Every subclass would store data associated with this order, e.g. target unit for OrderAttack or destination point and range for OrderMove. ATM this data is stored in Unit and UnitPlugin classes.
Unit would store its current toplevel order and also its currently executed (that is, deepest) order instead of work, advanceWork and several work-specific variables (e.g. target). The currently executed order's type would define which of the advance*() methods would be called for the unit.
This provides us with a dynamic hierarchy of orders instead of being restricted to a fixed number of levels (currently 2).
This might be useful for e.g. patrolling which could make use of more than 2 order levels: primary order would be OrderPatrol which stores the points the patrolling unit must pass through. To get to the next point, OrderPatrol would construct a suborder: OrderMove. Move order would have a flag specifing what to do when enemy unit is spotted. This flag would set to AttackEnemy by OrderPatrol (as you want to attack enemies while patrolling). So when the unit notices enemy while moving, the OrderMove would create OrderAttack suborder to attack the spotted unit.
Advantages
- Orders would be independent of Unit class which is necessary for UnitGroups proposal (which would store orders in groups rather than in units)
- Unlimited levels of hierarchy
Questions
- Should intermediate data be stored in Order class or in Unit (or somewhere else)?
Such data would include e.g. BosonPathInfo* which is not directly part of the order (because order should only specify which point the unit has to go to, not how exactly to get there), but necessary to complete the order.
