Command Beacons: Another way to help automate control

Discussion in 'Planetary Annihilation General Discussion' started by YourLocalMadSci, September 3, 2012.

  1. YourLocalMadSci

    YourLocalMadSci Well-Known Member

    Messages:
    766
    Likes Received:
    762
    Hi folks.

    A while ago, i was thinking of some idea's for a TA type RTS, when I came up with an idea that may be very applicable to PA.

    Command beacons are a concept that would offer a lot of ways to automate commands in PA, and set up complex paths and assaults that would help the player manage a large number of units. It shares some similarities with the area command feature in Zero-K.

    A command beacon is, quite simply, a free unit that the player can put down (or attach to another unit), and then be given an order (or order queue) just like a normal unit. However, rather than carrying out these orders, the command beacon will tell any nearby units to carry out these orders instead.. When placed, the command beacon would need an effective range set, but this can easily be accomplished by with a simple click-and-then-drag-a-radius mechanic.

    There are a lot of options as to how this could be used. For example, if you have a constant stream of units throwing themselves at an enemy base, you could use command beacons to easily move them on elsewhere afterwards, without having to re-task factory orders, or manage all the units in transit. It would work well with ferry units, as you could tell ANY units that get to a ferry point to immediately board for their trip. If you have a lot of units heading into battle in order to back up some big meaty tank, you could put a command beacon on the tank, and give it the order to guard that same tank. Now any unit which got near the tank would automatically help it. If they could be placed on enemy units as well, you could even stick one on the enemy commander (if you see him), and give it the order to attack that commander itself. Now, any unit which moved in range of that beacon would immediately start gunning for the enemy's top brass!

    Overall, I think command beacons could be easy to use (probably requiring only one extra ui icon), and could be a great help to the player in controlling colossal armies. Any thoughts, improvements or criticism?
  2. nlspeed911

    nlspeed911 Member

    Messages:
    482
    Likes Received:
    18
    That is a very good idea I think. I like it.
  3. jurgenvonjurgensen

    jurgenvonjurgensen Active Member

    Messages:
    573
    Likes Received:
    65
    There are better ways to accomplish this, which I think have already been suggested. The main flaw is that you don't usually want any unit within a certain radius doing a certain thing, only the ones that are good at it. You don't want a unit with a 'guard' beacon to happen to drive under your ASFs and drag them to its doomed assault on an enemy base full of flak. This idea sounds like it'd be full of people raging at units not doing what they were told because they accidentally strayed too close to a beacon. And it'd create extra micro. Players who notice one of their units has a beacon on it can order that unit to go somewhere in order to manipulate enemy behaviour (Got an attack beacon on your ACU? Walk out, draw a few enemy tanks and then walk back under your PD before they notice), which in turn creates extra micro in removing beacons from enemies which are moving strangely. And beaconing your own units doesn't help too much with commanding groups, since if the beacon unit dies, the formation forgets what it was doing, or would try and use some algorithm to decide which unit picks up the proverbial torch, which would inevitably end up doing stupid things far too often.

    More intelligent unit grouping (I believe Achron tried this, with mixed success, mainly due to crappy pathfinding) eliminates the need to have ad-hoc groupings based on proximity. I believe it has already been suggested that 'strong' hotkey groups be created that make grouped units respond to commands (which may or may not be area commands, since everyone agrees that area commands are the best UI improvement since strategic zoom) as one, possibly with automatic division of labour where relevant.
  4. coldboot

    coldboot Active Member

    Messages:
    447
    Likes Received:
    112
    We haven't hashed out all of the details yet, but Orders as First-Class Entities (OFCEs) will have exactly the features you want, without the game deciding who will follow those orders.

    With OFCEs you would explicitly select a group of units, hold Shift, and right-click on one of the waypoints of an OFCE queue, and they will carry out those orders.

    This way you can have permanent orders such as ferry routes, or patrol and movement commands that don't have to be reissued once you decide another group of units should do the same thing.
    Last edited: September 6, 2012
  5. jurgenvonjurgensen

    jurgenvonjurgensen Active Member

    Messages:
    573
    Likes Received:
    65
    Actually, this idea has more merit than I initially estimated, but not for anything suggested.

    Giving an "avoid" order to an enemy unit would tell all of your units to avoid that unit, and calculate pathfinding in a way that increased the pathing costs of any route that got within radar/weapons range of that unit. Obviously this would only work for identified and scouted units. Means less micro for dancing units around just out of range of things.
  6. YourLocalMadSci

    YourLocalMadSci Well-Known Member

    Messages:
    766
    Likes Received:
    762
    Just to clarify, you cannot see beacons that are placed by enemies, in the same way you cannot see your enemies' order queues in SC or TA. They are simply a persistent form of ordering. The only indication that your commander has a beacon on him would be the fact that nearby enemy units would automatically start attacking him. As seeing an enemy commander when you have units nearby is something that would prompt most players to attack the commander, i feel this a good example of what command beacons could be used for. It allows the emulation of some of the complexity of micromanagement, without the player needing to constantly update orders. The avoidance example you give later is another excellent use, and there are many more example that neither of us have discussed.

    That is pretty much exactly what I'm trying to suggest, although with an added area component (if created by the player). I simply suggested implementing it as the orders being linked to a free to place, invisible to enemies, attachable, indestructible unit, rather than the orders being entities in their own right. I thought this would be an intuitive and easily understood implementation, although there are other ways you could do it.

    If you wanted to add more complexity and control, you could even add a menu to each beacon that would tell it to only broadcast it's orders to units of a specific type/side/damage level/speed/etc.
  7. linecircle

    linecircle Member

    Messages:
    83
    Likes Received:
    0
    Adding more conditions to it could solve this (at the expense of more complexity).

    I thought this was too severe a disadvantage until I considered that the exploit is similar to kiting off a known enemy patrol group one by one. The possibility of command details being discovered could be considered a gameplay mechanic. In which case it would be up to the commander to issue smarter commands to begin with. For your example, units within this area attack this target, but only if your group meets this criteria, or for patrolling, attack things while patrolling, but don't stray too far/at all.

    I really like your 'avoid area' order attached to a unit.

    I would phrase it as "giving conditional orders ahead of time" aka planning. And please do discuss more examples :)

    To keep things organized, orders as first-class entities are only the first step; to then implement what you want, the additional features would be allowing order entities to be attachable to units or locations, orders able to assign orders, orders able to affect an area, and possibly conditionals in orders. The reason for this separation in organization is because many of those subfeatures alone or in other groupings can support other UI features that people are asking for, and it will be helpful to a UI designer if they can see how each implementation feature yields what user-level features.

    Also, I wasn't sure if the terminology was clear or not, but 'first-class entity' refers to them being independent objects in the programming sense. They exist in the UI, not in the game world. I hope that was clearer.
  8. michael773

    michael773 New Member

    Messages:
    34
    Likes Received:
    0
    I think the system would be more trouble than it's worth, there would always be units not doing what you actually want them to because of it.

Share This Page