This post is a continuation/extension of my previous, much older post on Force Organization. This post is intended to complement unit groups, and work in conjunction with them for wide-ranging applications. While orders as first class entities idea captures one aspect of the kind of abstracted command and control PA might have, I don't think it goes far enough as a concept compared to what might be possible. Abstract Orders Each unit's orders are a queue of commands, including commands like move, attack, build, or other actions. Abstracting orders separates the queue from needing a unit. A player might create a queue of orders independent of a unit, and insert a queue of orders into any unit. Orders might be copied between units, or saved for later to be insert into, append onto, or overwrite any unit's orders. Messages Messages are used by units or other objects to send information or orders to each other, as the player specifies. Obvious cases of this- a group issuing a move order to one of its members, or a member informing its group that it is nearly dead. References References are map markers, including points, lines, regions, etc. that the player can draw. However unlike Spring's map drawing system, which is largely for communication, references can be used in conjunction with unit logic. And the reference is referred to independently, so it can be moved. Orders or anything else that points to the reference still points to it; using its new location. References can also send messages to units, groups of units, or other objects. When a unit arrives at the point, the point might copy orders into that unit's order queue, or do something else. As a simple application, a player can create a network of points to rout unit traffic wherever they wish. Each waypoint would insert a move order to go to the next point in any units that reach that waypoint. This allows easy reassignment of flows of traffic by changing which reference each point routs to next. Designations Designations are text labels attached to units, references, or any other object. They can be used to create conditional behavior and specify functions for objects. As a trivial application, a reference point might "grab" a nearby unit with the "picket" designation, and order it to stand at the point's position. If the unit was later destroyed, the point would grab another suitable unit without any player intervention. Designations could also be used to abstract out quite complex behavior. For example, a player can create a few dozen points out on the map, and designate them "nuke target." Then the player issues a global order to all units with designation "nuke silo." This order queue could have two orders, and might read as follows; "1) fire a nuke at any point with designation 'nuke target'; and 2) remove that point's 'nuke target' designation." The result is that every nuclear silo you designated as "nuke silo" fires a nuke at a point with the "nuke target" designation. This allows you to pre-plan where you want to fire a large salvo of missiles, and then with a single command order them all to fire simultaneously. Applications That was a lot of pretty heavy theory. I think perhaps you might have an idea of how flexible and powerful this kind of system might be. But I think some examples are in order. So, what does this kind of logic actually do? Suppose you have already defined what you want your army's pieces to be, what the pieces of the pieces are, and so on all the way down to the individual units. You've also got some definitions for what kind of Base you want to build. Applications: Bases A Base would be a complex group of stuff. An abstract group with a set of structures you want the base to have is a critical component- such as 4 land factories, 1 air factory, 5 air pads, 4 point defense, 4 anti-air, 1 anti-nuke, etc. However a Base object can also contain references, designations for objects not-yet-built, and abstract orders to be copied into units or structures once they are completed. As a result, it is entirely possible to create an entire Base entity to your specifications with one click. Quite a bit of work the first time you define what a Base is, but very easy to clone after that. Each base can have a region around itself where it attacks enemies that enter. It might have different regions for different responses, such as a large "scramble fighter squadron" zone, and a smaller "send tanks" zone. A base can include unit groups which act as its defenders in this capacity, and can even be defined to build its garrison automatically, and designate them to the garrison the instant their production starts. This base's production facilities can be grouped. So you order the Base to construct a Tank Regiment, or whatever else you named your custom battalions. It splits the production between its facilities automatically. You rally all base production to a single reference point within the base- call it Base Rally. All the reinforcements produced from this base can be directed by governing where this point sends those units. And it may be part of the Base object's behavior to treat a Move order as a reassignment of Base Rally's abstract orders. So wherever the Base is ordered to "move" is where it sends all the units it produces. Applications: Supporting Armies Each one of your large groups moves, fights, and otherwise acts according to the group's definition. Scouts might be far away from the force's center, with heavy tanks front and center, with more fragile artillery or anti-air in the back. You pass a point you want to keep an eye on. You create a point and call it "picket" and an enterprising scout unit from your force dutifully runs over to the new point, and will sit there until killed or ordered otherwise. You make contact with the enemy. Shots are fired, both sides suffer losses. You fall back and reform the army. Partial squads are merged to create as many full groups as possible, with the count (out of the defined maximum) being displayed. Your army compares its current units to its group definition. Turns out, some of them are missing, 'cuz they're dead. The army sends a message to the base requesting reinforcements. The base gets right to work building them, and will automatically send them to wherever the army is (mobile reference area attached to group). You want to call in an air strike. You box-select a group of enemy units and designate them "air strike" and your nearby base's bombers immediately lift off. Before long, the battle in the field goes in your favor. You advance towards the enemy base, and define a "bombard" region around the enemy base. Your artillery goes to work. For good measure, you also create a "no-go" region around the base, which your units are forbidden from entering. Your scouts and light tanks proceed to go nuts on anything outside that area, though. Your reinforcements arrive, finally. You decide you have enough to wipe the base out. You delete the do-not-enter zone and the bombard zone, and order everyone to attack. With the enemy base now destroyed, you decide it was a good location. You want a new base there yourself. Build-->Base. Click. Conclusion The idea is to have a more powerful set of command and control tools to define unit behavior. Despite the seeming "automation" of this approach, it isn't an AI "playing for you" since everything is according to the player's specification. All the computer is doing is recalling your precise instructions at later points in time. The player is allowed to save potentially huge sets of orders and logical relations, and duplicate them ingame.