Easy Parallelisation: Killing lots of micro with one stone.

I didn't see it in the Orders as First Class Entities wiki entry, or the carpet bombing thread, where I'd expect it to come up.

Suggestion:

Add a modifier key (let's say crtl) to change an order queue from sequential to parallel. Hold this key down and issue a number of orders (n) to a group of m units, and then release the key. All the units selected will split themselves into n sub-groups (as long as m > n, if this is not true, they will go off on their own, and any unit that finds itself idle will be assigned one of the outstanding tasks) and perform one of the orders. The pathfinding loop will automatically assign units to orders on a closest-first basis, but also attempt to ensure equal force composition if possible (give two attack orders to 10 tanks and 5 arty, and it will split them into a group of 5 tanks and 3 arty and a group of 5 tanks and 2 arty).

If there are any units selected for which the order doesn't make sense (units without weapons given an attack order, units without nanolathes given a build/repair/reclaim order, units ordered to attack something they can't hit), they are split up evenly between each sub-group and treat the order as a "Guard" order with that sub-group as a target (meaning it's trivial to take units along for protection) for the duration of the order.

Since these orders, from the PoV of the units assigned them, are no different from normal orders, they can even be queued, with a sequence of clicks of the form: <shift><ctrl>first batch of orders</ctrl><ctrl>second batch of orders</ctrl><shift>, which may be useful if you want to, say, annihilate a selection of high priority targets with bombers, and have any survivors go after some low priority targets. Or split your forces into three and have them follow three winding paths.

This mainly reduces the number of clicks it takes to multitask similar tasks, and links well with area commands (since sometimes one would want area commands to be done in sequence, and sometimes in parallel).

Finally, one could even give orders with no units selected at all, which would be the game's cue to assign the nearest available unit to the task (or perhaps all available units, if you signified priority somehow, perhaps by double-clicking the order instead of single-clicking it, or even a priority-priority (triple click? Some other modifier key?) which will actually pull units of previously assigned orders)). Useful when you don't really care which engineer you get to reclaim that wreck, you just want someone to do it sooner rather than later. Or if you spy a stratbomber lining up to snipe your commander, and you just want everything you've got to shoot at it no matter what else they were doing before.

Re: Easy Parallelisation: Killing lots of micro with one sto

I think there are a lot of posts on this forum where players are asking for a very, very abstract and powerful command system, of a kind which we don't quite know how to articulate.

I've spent quite some time thinking about this, and I think the best approach is to bite the bullet on the complexity front, and create a full-featured, powerful control system that has never been seen before. Something that allows creating logic structures on the map that give units orders as per the player's instructions. Structures that can be copied easily, and modified to quickly change behaviors for each of their instances.

I don't mean physical structures in game terms, I mean UI objects that can be manipulated by the player. These structures assign and control the behaviors of a lot of units routinely, and the player only needs to intervene to modify their behavior, presumably to adapt in response to changing battlefield conditions.

What about a big shift in the way RTS players interact with their forces, where instead of assigning orders to units, the player is manager of the system that gives them those orders? If you want to assign a single unit orders, that should be available, such as for special assignments. But without a higher-level system you will be giving lots of "special" assignments that are rather similar, from production orders to rallying to basic attacks or target selection for raids.

It would be great if the player could give truly high-level commands like "these two bases will reinforce that army" or "build a base on that island" or "strike bombers target fusion plants, then engineers, then mexes" and have them pick their own targets until otherwise instructed. I'm still working on how best to do this simply.

Re: Easy Parallelisation: Killing lots of micro with one sto

That sounds a lot more like SpaceChem: The RTS, which is a game I've wanted to see for a long time, but things like logic gates and if-then clauses start to make the game into some kind of real-time programming contest.

I suspect a lot of people did not sign on for a lesson in computer science, as much as I'd like to see a game with a Turing complete order system, this probably isn't that game. If it is implemented, the game really needs an AI Speed Programming mode: Enforced five minute latency on all commands. Better be good with those if statements.

Re: Easy Parallelisation: Killing lots of micro with one sto

That is the tough bit. Making it simple and fast, and not a computer programming contest.

While that does impose some limitations on the kinds of things you might automate, I think a powerful system can be created with minimal complexity.

Unit groups are a fairly straightforward idea. Having things like points and regions exist independently of units' assigned orders is pretty simple also. I was also thinking about being able to assign designations to units, or types of units, which would allow handling automation. For example, designate all enemy fusions as "high value target" and tell all artillery or bombers or whatever to prefer to attack things with that designation.

Things like conditional unit behavior for all situations, there is just no way to do that simply. Complete build programming, or other high detail decision scripting, is just not going to work in a simple system.

Re: Easy Parallelisation: Killing lots of micro with one sto

This is basically a more general version of "Split Targeting" that was mentioned in the Zero-K Features thread. Great idea!

I've copied your post verbatim the Group Order Parallelization page so we can clean it up and add any important considerations such as how this behaviour should behave in potentially conflicting edge-cases.

For those of you on the sidelines, he's referring to Orders as First-Class Entities which is on the wiki.

EDIT: Links updated to ShoutWiki, because Wikia blows...

Re: Easy Parallelisation: Killing lots of micro with one sto

This is a really nice idea. It would work particularly well with high power area commands. Select group of engineers -> area reclaim. Or area build mexes.

Re: Easy Parallelisation: Killing lots of micro with one sto

some aspects of conditional behavior could be realised without going into a complete scripting system (even if I wouldn't mind such a system )
one could define a simple set of conditionals with a simple inheritance of some rules.

e.g. some kind of worker type unit could have conditionals like:
- if building finished
- if resource area empty
- if attacked
- if low health
and orders like:
- go next know resource area
- retreat
- find healing
- stay til the end
Just a simple subset of possible options defined for a class of unit. Changing it would be as simple as two consecutive drop down fields. Combined with some inheritance of orders (general orders defined at the build place for that unit for all its instances and changeable on unit level for specific purposes) you can have a simple system to influence the passive behavior.
Coupled with some more advanced system for giving active orders this would enhance the micromanagement without to much effort on the player side.
Besides the rules will probably have to designed anyhow, it's just a matter of exposing them to the player.

PS: this would also solve some issues raised in the auto repair thread, where people complained that in some games units would run of to get healed/repaired without being able to prevent or regulate that.
PPS: I wouldn't mind setting some of the rules before the game starts or for all games in general. Some rules are player specific not game specific since they reflect the preferred strategy of the player

Re: Easy Parallelisation: Killing lots of micro with one sto

I cant think of a situation where this would be helpful.
The case where I want to split my army into n equally sized parts to atk something or very rare.

Re: Easy Parallelisation: Killing lots of micro with one sto

execute Wing Attack Plan R

Re: Easy Parallelisation: Killing lots of micro with one sto

So you just thought of a rare situation where it would be helpful. Powerful user interfaces always have features for use in rare situations.

Re: Easy Parallelisation: Killing lots of micro with one sto

No they don't because you end up not using them for the most parts.
And features that are very rarely used are a waste of time for the developers + complicate the whole interface for nothing. Having over 9000 features of which are only a few dozens are regularly used is bad.

Re: Easy Parallelisation: Killing lots of micro with one sto

The great thing about programming for the general case is that you wouldn't expend resources writing a "splitting your army into equal parts to attack something" command, since it would be using the same interface and commands that you implemented for area reclaim, or dividing build queues up between multiple factories.

Re: Easy Parallelisation: Killing lots of micro with one sto

Thinking of the right way to abstract stuff enough to really reuse code like that is work, too.

Also I am not talking about the backend, I am trying to point out that a good gui should not be overloaded with lots of rarely used features. Rarely used features often end up being forgotten and therefore even less used. Like the coordinated attack feature in SupCom:FA.
Who uses that? xD

Re: Easy Parallelisation: Killing lots of micro with one sto

Thanks for reminding us about this promised feature! I think it was more of a case of the functionality not working at all to begin with. There were various threads over at GPG regarding this issue. So, I think it is fair to guess that there are people who care enough about it.

I love this thread so far, and the "Orders as First-Class Entities" just smacks me as something straight out of a programming class (all those functional languages, wee!) How am I not surprised this game attracts so many programmers and computer buffs. However, allowing people to actually type pseudocode to program the commands might be excluding many other players who rely more on their intuition and hands-eye coordination. Instead, a curated set of basic control elements as building blocks for chains of commands will be the best option.

I think the command vocabulary from Supcom is well advanced enough for most situations:
> Hold Position (A)
> Move (A,B) [ may support formation ]
> Attack (A, B)
> Patrol (A, B)
> Assist (A)
> Ferry (A, B)

Allow these to be created as first class entities, chainable, and allow for meta-command manipulations:
> Copy/Cut (commands)
> Paste (commands, location)
> Save (Commands) [like the Templates for building stuff in Supcom:FA]

And, finally, if we fancy, extra packaged stuff like Coordinated Attacks.

Re: Easy Parallelisation: Killing lots of micro with one sto

I personally feel that unless dozens, hundreds, thousands of people are microing some facet of the game continuously, and getting frustrated over it, thats when you need to step in with a better interface. Not for extreme edge cases where you maybe kinda sorta can think of how it might possibly work.

Likewise, I don't want to see logic added too much to unit AI; the logic would be the players actions. If I want to split up a group to surround the enemy, I can already do that; rubberband this blob here and send it there, do the same for this blob... instant two-pronged attack. I wouldn't enjoy it at all if I pressed ctrl-shift-I (hold) doubletap-Q and watched my units perform some complex balet, nor would I enjoy writing a computer program for the AI to perform at a later date. This seems like replacing micromanagement with pre-management.

Going back to the original post... suppose I want some units to patrol around my base, other units to scout forward to find hidden assets, while being protected by another group on the flank. I wouldn't want to select 100 tanks of the same kind and say "do these 3 things, splitting up into 3 groups on your own", when I could just select 3 groups and issue the order to each. What happens when the situation changes, and I need to issue new orders to only one of those groups? Do I have to undo or reissue the orders for the other two?

I guess the short of it is... this doesn't seem to solve any problems or micro. It seems like a solution looking for a problem.

Re: Easy Parallelisation: Killing lots of micro with one sto

To be honest, even being a programmer myself, programming aspects of the game or "reusing code" doesn't sound spectacularly fun.

It's really nice while you are planning it, but when you run it more than a couple of times, it gets boring really fast. It isn't you who is playing the game anymore, it is the bot, the AI.

The game may help you, make your life easier, but in the end it's you who should issue the orders.

About parallelizing orders, I'd rather have the game "give me 3 groups(or just give me 20 units) from this selection, assign that/those groups some contextual/local hotkeys, and let me control them with these".

Re: Easy Parallelisation: Killing lots of micro with one sto

So you've got your mixed group of 51 tanks, 21 arty, 24 flak and 12 shield gens. Are you really sure you could just rubberband three groups which happen to have 17 tanks, 7 arty, 8 flak and 4 shield gens in each in no time at all? But people keep talking about ground armies when it's not actually about them. Being able to split up ground armies is an incidental bonus. Engineers are where the real benefit is, since you often have the need to lay out lots of construction orders at once, and have a lot of engineers, and it's inefficient both in terms of APM and workers for each of them to have their own queue when all you really care about is that somebody does the work at some point.

Bombers (and to a lesser extent artillery) are another case where it's a major advantage, since bombers tend to have very front-loaded DPS making it inefficient to focus fire, and giving 10 bombers 10 different targets is 20 clicks, but giving one group of 10 bombers 10 targets to divide up amongst themselves is 11 clicks. And this has the advantage that if some of the bombers don't make it to their targets, but other survive their first pass, you don't even need to tell them to go and get the targets that were missed on the first pass.

One the orders go onto the queue, they're indistinguishable from regular orders, so you can give new orders in exactly the same way as if you'd given the orders separately at the beginning.

Re: Easy Parallelisation: Killing lots of micro with one sto

Nope. I'm saying that I can rubberband 3 groups. Wanting 3 groups of exacting size down to a specific unit count, in a game where you're throwing hundreds of units at the enemy, is more than slightly OCD.

Not that theres anything wrong with OCD gameplay; I use it in single-player all the time. But its not a good option in multiplayer. I feel the existing controls can split things up "well enough" that there is no need for more micro reduction. Especially when it strays away from micromanagement reduction, and into tactical control (which is my job as a player).

Re: Easy Parallelisation: Killing lots of micro with one sto

I have played probably thousands of ladder games ton 50 to top 20 level and never wanted to split my army like that. xD

Yes that is something I wanted to do sometimes. Mostly for torpedo-bombers against multiple cruisers. It is a hassle, yes. But I dont think an automatic would be able to pick out exactly those targets that I do by hand.

Re: Easy Parallelisation: Killing lots of micro with one sto

What about doing the two-pronged attack by using some offline-time or downtime to set up an order queue (plan) that, given a group and a target, splits the group in half, turns one leftward and the other rightward, and has them join back together at the target? Then when it comes time to use it, it might be a single "Attack(two-pronged)" button on the ui, or something equally low-apmish. This lets you use this attack again and again without having to do the complicated set up over and over. Yes, this is pre-management replacing micromanagement, but it doesn't have to be as unintuitive as "ctrl-shift-I (hold) doubletap-Q".

---

From my experiences, the general summary of the forum threads regarding unit control reduces to this:
1. Someone or something has to make the high-level decisions(the 'strategy').
2. Someone or something has to translate the high-level decisions into low-level commands(figure out the commands to implement the strategy) in order to issue them(queue them up) to the units.
3. Someone or something has to execute(perform when the time comes) the low-level commands.

let P=player and C=computer,

For a micro-heavy rts, you have something like (1P,2P,3P).
For an rts with some ai-assist on the micro, such as TA, you have something like (1P,2P,3P&C).

For PA, the consensus so far seems to be 1P; divided between 2P and 2P&C; and divided between 3P, 3C, and 3P&C.

There is no true right or wrong here. The greater goal of PA is to allow meaningful huge-scale gameplay. Even though taking this development-input opportunity to also add in high-level strategy is an ideal that some of us hold, it is, strictly speaking, not required for PA to function as a huge-scale RTS. Historically, micromanagement seems to prevent meaningful large-scale gameplay -- so, it seems mandatory micromanagement has to go. Optional micromanagement will always stay, and I recognize the gameplay and competitive value of challenging yourself with high-apm execution. Does this really change the game's design? No, not really, there is enough customization (eg. map variety) within the game that people who like micro can play micro-PA and people who like macro can play macro-PA.

That still leaves us with the question of "How do we put larger-scale gameplay into RTSes?": add a powerful UI that gives you more effective command over larger armies without increasing apm, or add a powerful AI that removes some of the need to command your large armies, or some combination? That is, in a nutshell, the entire debate going on.