Another thread requested the ability to assign factories to control groups, and thus automatically assign the units produced from those factories to that numbered control group. TA and several other RTS titles have this feature, and it makes sense. However, I think the paradigm of relying upon primitive control groups and manually controlling every factory's queue is shortsighted. It leads to a lot of micromanagement due to the enormous number of units and factories that PA supports. I propose a radically different solution to factory and unit command and control. New Group System Traditional control groups are inherently limited. There are only 10 keys for conventional control groups. And managing each control group is just mechanics, not a decision about how to organize or deploy your forces. I propose to radically rethink the conceptual organization of the player's base and forces. This new system is overlaid on top of the conventional RTS controls, which would still be available if you prefer. First, players can assign groups of units from selection. One hotkey to create a group, another to dissolve a group. These groups are not bound to a specific key, but if one unit in the group is selected, all the group's units are selected. They will always be selected and execute orders together. The most direct application of groups is to organize forces without control groups. Such as having an army that contains an assault group, an anti-air group, an artillery group, a fighter group, or whatever you like. This eliminates the need to ctrl-Z the same units over and over. The entire group behaves like one unit in terms of left-click selection and right-click orders. Factory Groups The same system is usable for other purposes than simplifying combat unit micromanagement. For example, the player can create a group of factories. When one factory is selected, all the factories in the group are selected. Effectively distributing a single build queue amongst all the factories in the group. Or a player could create a group of fabbers which will build together, automatically pooling their build power to assist the same task, and allowing easy reassignment of the entire group. The best part about this organizational system is changes in the group do not force any player input. A factory group can increase or decrease in size, resulting in a change in build power, but without requiring any player micromanagement. The player assigns the group a build queue, and the group of factories will follow that build queue regardless of the number of factories in the group, even if that number changes. Ghost Units Previously I suggested a rally point-based system of command and control for unit groups and factories. That system involved creating more in-game features and UI stuff than is necessary; this concept is simpler, using groups only. I propose that it should be possible for groups to "contain" members that do not exist. The meaning of such "ghost units" in a group is a request to have that unit added. For example, a combat force can have a ghost unit added to increase the group's desired size. This creates a state where the group "wants" to have an additional unit of that type. This functionality enables the player to pay attention to the battlefield, rather than micromanaging fabbers and building factories. A group of factories can have an additional "ghost factory" added to the group. This means the factory group now has a vacancy, and fabbers will build the factory. The same principle can be applied to energy generators, and even fabbers and combat units. A group of such units can have its size managed as if it were a build queue. This enables the player to control production with the camera away from the factories. Using this system players request units from the field, rather than manage the home base and send units away. Automatic Reinforcement & Rallying This system allows players to pay attention to forces in the field and still manage production. However, rather than manually controlling each individual factory on the production-side of the equation, the player will manage the desired size of each army. Previously, if the player wanted more of a particular type of unit, he or she must navigate to the production queue and enqueue some ratio of the desired unit. Each factory's queue is separate, complicating the management of a large number of factories. However under this new approach the player would add units of the desired type to the group. As a result the group will no longer be full, and thus the factories will work to fill those vacancies, automatically distributing requests. Furthermore, by default, suppose that when a member of a group is destroyed, the group will automatically create a ghost unit of the same type as the unit destroyed. A group with 10 members loses one, and now contains 9 actual units and 1 ghost unit. Integrating in with the existing system allowing the player to increase the desired size of a force in the field, when a force suffers casualties, replacements will be automatically produced and dispatched to meet up with that group. The AI will automatically maintain the player's desired size of the group if there are losses. And the player can increase the desired size of the group to send more units to it. User Interface The UI should display a breakdown of units selected, divided by group if multiple groups are selected. If a gaggle of ungrouped units is selected, display a buildpic for each type and associated quantity. If two or more groups are selected, display each unit type buildpic and quantity. Using this UI system, a group's desired size can be increased or decreased in the same manner as if it were a build queue. Click increases by one, right click decreases by one, with larger increments using shift/ctrl keys. Adding an additional unit of a type not currently present in the group is the most demanding task the player and UI might need to perform. This can be done using an additional icon, possibly a "+" sign, which opens up a method of selecting unit types. Most likely a list of factories with a sub-list for the units in the selected factory. Groups also open up the possibility of having a strategic icon for the group, rather than a sea of icons with one for each unit. Empty Groups & Standing Orders There has been a longstanding problem with abstract orders, such as the Ferry command in SupCom. What happens if the unit that is the source of the order is destroyed? Or in this case, what happens if the group is completely destroyed? The solution is to allow groups that don't actually contain any real units. You can add ghost units to an existing group. And, in the same fashion, you can have groups that only contain ghost units, and they can receive orders; voila, abstract orders. But the possibility of having nonexistent groups again raises the issue; how could the player modify or delete a group without a unit from the group to select? My solution is to have standing orders saved in the group. In addition to the conventional orders a player might give, such as a right-click move command to a selection, the player can indicate a particular order should be remembered by the group, possibly using ctrl. Ctrl+move would change the group's standing order to a move command to the target point. If the player issues a standing order 'move' command to the group, the group recalls its destination even if all the units in the group are destroyed. Individual member orders are automatically generated to produce compliance with the player's command for the entire group. This method solves multiple problems. The player can delete a group by deleting its standing orders. And the player can create a new group without binding existing units by creating an assignment from scratch. This also has the cool side effect of allowing the player to create assignments for units that do not yet exist. Such as plopping an "attack" order on an enemy base, and designating the group that will be associated with that order as consisting of 100 Dox. Those units will be produced to fill the ranks of the group, and off they go. Different orders will produce different behaviors. For example, a standing order for area patrol will automatically post the specified number of units on roaming patrol. If some are destroyed, they will be automatically replaced. Lastly, there are two reasonable ways to implement nil groups. Groups defined as containing zero units might be deleted, as an alternative method for the player to remove groups. Or, they might be used to create abstract orders which units can be assigned to. Such as shift-queueing a series of move commands, assigned to a group that contains no units. The player might manually assign a selection of units, or an existing group, and thus copy those orders to those units. Conclusion Because of PA's large scale, the player has a large amount of hardware to manage, and because of its exponential growth continuous economy, efficient stewardship is liable to be more important than battle strategy. The best solution is enhanced control through automating the implementation of player decisions. For rote tasks like copying factory build queues the AI will do it better and faster, with no loss of strategic depth. Using this system the player says "I want X of unit Y here, to do Z." Primitive orders to implement the player's command are automatically generated. Automation to implement player decisions using fewer actions is ideal, but on no account should the AI attempt to be "smart" and make decisions. TL;DR- Orders as First Class Entities, backwards; abstract orders fall out of groups of units, not the other way around.
+1 to this. I'd also like to suggest including a squadron manager pane, which I talked about a while ago in the linked post, that would allow tracking and and direct selection of the anonymous groups that ledarsi is suggesting.
If you TL;DR'd, I highly advise reconsidering. Some really worthwhile stuff in there which I sincerely hope Uber give some serious consideration (post-1.0, methinks).
Interesting ideas. I am not sure if PA has the scale required for them to be necessary because at a small scale automation just gets in the way. But something like this will be required for the management of (interesting) large scale games. Do you have a well specified idea of how the reinforcement system would work? This bit has the potential to take decisions away from the players and be the type of annoying automation that gets in the way. If lots of groups lose units there is presumably some priority for replacement that exists in the players mind, how is that communicated to the UI? Also automated logistics can have problems. It may be best to have to specify groups as supporting each other, a supporting group will repair and rebuild the units of a supported group. Given the stage in development (and the devs opinions about automation) I think you will have to delve into UI modding yourself. Or at least convince some people to do so for you.
As for details of implementation for reinforcements there are a few possible approaches. One good algorithm would be to generate a list for the player's open requests, and weigh all elements in the list equally. Each unit/structure acting to fulfill those requests would select one that it can fulfill, and will pick randomly. When that task is completed, it would select another one randomly at that time. First, a factory or fabber will only fulfill a request that it can actually do. If there are 10 requests for Dox and 10 requests for Vanguards, obviously basic bot factories cannot build Vanguards and will only fulfill Dox requests, and vice versa for advanced vehicle factories. Also, requests of a type that are more numerous should be more frequently fulfilled. If a player has a group that requests 100 Dox, and another unit that requests 10 Dox, then the first group has a 90% chance of getting the first Dox request from the first factory. However, after that point, the probability changes because there are now 99 Dox requests compared to 10 Dox requests. If the player has a bunch of factories continuously processing requests, the factories will favor the unit with a larger number of requests proportionally. But as those requests are filled the probability drops. Although the default behavior will be to randomly fill requests, the player should also be able to control this behavior, such as ordering a particular factory group to fill a particular group's requests. To do this, the player could assign the factory's rally point to the group. Such as by assigning the factory's rally point to the group's standing orders. For example, if the group has a standing order to move to a particular location, the player could put a factory or factory group's rally point on the standing order. The group's standing order could be moved and the factory's assignment would remain until it is reassigned. I intend to get into UI modding, but am still waiting for PA to get a bit further along.
