We already discuss about orders as first class entity. But what about armies? Queuing units up in army intern menu, translates to these units been build where they need to be. Also fine for shared control, and hierarchical play. Most of this could be achieved with ui mod though.
As I proposed in another thread, the most simple solution is an option to assign AI to an army or base and give it a high-level directive. Maybe it's even possible to generalize it with first class orders by adding a planner that selects most optimal group AI to execute given order.
Are you sure you understand what the concept of orders being a "first class entity" is? For those that don't, in a game, an entity is an object that represents anything in the game that meets a certain set of parameters set by the programmers to "exist" ingame. These parameters may be items like an ingame location (x, y, z coordinates), velocity, heading, etc. These are the most basic properties that the developers dictate that an ingame object should have. Every subsequent object is derived from the base entity, like units, projectiles, planets, particles for particle effects, etc. These derivations add other properties that might be specific to their object types. Unit objects would have health and armor properties, while projectiles would have a damage property, and particles would have a decay time property. So the concept of making orders an entity means that instead of every unit having a property that is a list of orders, which would be interpreted as a set of commands that the unit would then interpret in its own time, the orders would exist as their own derivation of the entity base object, meaning they do not have an existence that relies on the units/buildings, but an independent existence, much like the units themselves. The units would not have some sort of order list, but instead, they would have some way of referencing their next order. The idea of it being "first class" is really not something that needs to be said for this specific implementation, since it is implied by the concept, but it essentially means that that it's implemented as a fully functional object, rather than partial instantiations. The implementation of an order as an entity rather than a property of another entity adds some challenge to the implementation of the system, namely a potential reworking of the inter-entity communication system. Depending on Uber's implementation, this can become fairly complex, which is perhaps why none of the devs have really confirmed this. In fact, the perceived benefits may be easier and more efficient to implement with a more traditional order system, with extra edge cases worked in. (And some good, old fashioned brute-force methods.) But orders are a basic, low-level component of the game, so implementing them as their own entities would be a logical development choice, especially if they see a lot of use. Armies, however, are NOT a low-level component of this game, and implementing them as an entity would not only be unnecessary, but would possibly be bad programming practice, since it's adding extra cruft to the engine that's very specific to a small part of the game, with a very small benefit received. So no, armies should not be a first-class entity in PA. Instead, one can implement the orders-as-entities system to achieve the same effect, except in a more straightforward and clean manner. (In fact, if the devs really want to get creative, they can build a complex message-passing system to handle the communication between entities. But here I am, turning an RTS into an OS. Talk about overkill.)
Could you explain that further? Maybe I have missed something I don't see this downsides, thought of it as more advanced persistent hotkey group.
What you are probably thinking of is an advanced grouping and ordering of units, which is more of a UI thing. As you said yourself, this can be implemented through a mod. And as such, you should be referring to it as a method for such grouping and ordering. (Also, it would be helpful to elaborate, as your initial post doesn't really go into details as to what the features and benefits of these army "units" would be. Perhaps give an example so that we have context.) However, by referring to it as a first class entity, you are suggesting that armies be implemented in the manner I specified in my previous post. For example, this new object, an "army," would have a position, heading, and other properties that a basic entity has. But this doesn't make sense because an army isn't an individual object, or at least, it doesn't make sense for the type of game PA is. It is instead a "container" object, and should be implemented as such. Perhaps I'm just irked at the fast and loose usage of the term "first class entity." It made sense when it was used in the context of orders, and was stated by someone familiar with object oriented game design to give Uber an idea of the specific implementation they had in mind. And for those that followed, including myself, it was an easy term to use when referencing the concept (whether Uber opts for that specific implementation or something simpler but equally effective). However, once people start throwing the term around, it becomes just as badly understood as the flow field concepts that were shown in the livestream.
SupCom2 had this feature where when you gave a bunch of units a order it would draw an extra circle which you could click to select all those units. Don't know whether it's a container or a entity but I liked how it was easy to think in more macro terms when the units are represented as a single object. Imagining what kinds of things I would get out of armies as single objects: Say I have 2 bases, Stronghold and Homebase. I have observed and deduced the enemy composition and decided that I want 20 tanks, 5 gunships and 3 planes to be built. Lets say that Stronghold has 3 land factories and 1 air factory and Homebase has 5 land factories and 2 air factories. I make a army object and spesify that it should contain 20 tanks, 5 gunships and 3 planes. Let's also say that bases are a kind of building army. Then I give Stronghold and Homebase (2 objects) order to build the new army near stronghold (3rd object). Now the "building armies" sort by themself without my interference that tanks should be built out of land factories and planes out of air factories and that no factory should be left idle and that the build queue should be balanced so that everything finishes near at the same time. Then trouble arrives and an enemy force is detected between Stronghold and Homebase. I don't want to trickle my units being produces right into them so I tell Homebase not to participate anymore to build the army (just 1 order involving 2 objects). Now I am not using Homebases factories and Stronghold propably needs to rebalance it's build queues and it takes longer for the army to be built (bonus points if I can see this from a Estimated Time of Production) but atleast I am not walking into trouble. Say that I am upset of this delay and want to boost Strongholds build power. I tell Stronghold to build a land factory for itself here, here and here (3 orders) or one order of building here a group of 3 factories. Now implicitly with no orders from me Stronghold utilises the new factories to reduce the build time for the new army filling them up with build orders. Say that I spot some enemy spy plane that I want to urgently shoot down. The new army is in the middle of building but the 3 planes are already built. Hunting down the spyplane would probably not be done in time for the plans I have for the army so I detach the planes from the army to have go an adventure hunt down the spyplane. Stronghold notices it needs to build 3 more planes in order to fill the army. If I would have estimated that the planes will be back before the army gets to move I would not have removed them from the army but just hunt the plane down. Or I reattach the planes once they are done adventuring to stop Stronghold from producing excess planes (althought in the mean time it might have produced some excess). Say I have a group of engineers and a wounded group of units. Engineer group repair wounded group (1 order 2 objects involved). Say that I have 3 entrances with 3 defence groups all of which are wounded. Engineer group repair group1 , group2, group3 (3 orders, 4 objects involved) or "Engineer group -repair Stronghold defence forces" (1 order, 2 objects involved)
I turned this off also, though when the game first launched I remember being teased that it was just a preliminary implementation of the system...I was sort of hoping it would turn into a sort of Picture in Picture circle so you could stay zoomed out but still micro your tanks to dodge by using the PiP. Too bad it never got any refinement (Due to game flopping? Due to CT's frequently promised by never delivered ahhhhhhh nevermind)...
