I would like to suggest an extension to the possibly of ferrying and its ilk. I always really appreciated the macro strategy options available in SupCom and would like to request their extension / inclusion in PA as a more modular strategic command layer. By this I mean a series of standing orders that we can create and leave on the map (untied to any particular unit) that we can direct units to and have them follow out those actions. Lets imagine three of these, starting with an improvement to one SupCom players will recognise: Drag select a selection of building and set as a prefab. Now this can be used to bulk build that layout. However we go one step further and placing them in this way also creates a strategic command layer, this would record the buildings you wanted there and provide a handle that could be used. We could for example set the rally point of a factory building engineers to it and they would assist it's construction and repair/rebuild any lost buildings in that prefab. Combat units routed to that handle might defend those structures or patrol around them. Ferrying. We can place a ferry strategic command layer and all transports routed to it carry any ground units routed to it. Fighters routed would patrol the path. Now comes the "modular" bit. So I have a prefab of a forward line and I place it some point distant from my base. I don't need a builder or engineer, I can just place it. Perhaps players are limited to five strategic commands (for server sanity). Now I place a ferry strategic command from my factories to just behind my newly placed prefab. I bind the out of the ferry to the in of the prefab strategic layer. Now when I route my factories output to the start of the ferry, they are transported to the front where they build/defend and maintain the prefab. WHY?! The purpose is to allow the player to do more macro with less micro. Given that shields are not coming this means you can leave maintenance of your defenses to your builders and get on with making interesting decisions on where and what to do with your forces. Imagine another strategic command layer, an attack move. It comes with a number; a number of units to accumulate before that group attack moves to it's destination. So now I can place a forward base, bind a ferry to it from my base, bind an attack move from the forward base and route everything I send there. Where they wait until there are 40 combat units (a number I picked when I placed the strategic command) and then those 40 units attack move to destination. New factories at the front line initially rally to the out of the front base strategic command (but I could just move on the factory that if I wanted). Just a thought. Obviously there are other options for strategic layers: area defend, patrol path, move path. And if they are plug and play modular we can take out some of the micro required to play the game, leaving players time to make better decisions. p.s. Even if this doesn't go in can someone please take a look at making rally points more intelligent? Rally on a unit = assist/guard etc?
+1, some very good suggestions and I'm sure the devs have some of this in mind already (the aim is to make PA the ultimate 'macro' game after all)
So in summary you want "smart orders", that when clicked on will cause the selected units to do appropriate things to that "order"? That sounds like a really hellish if/else tree to me, or a lot of parsing. Still, +1, there is nothing bad about this idea.
@tofutank, I totally agree with the general idea. That said, it looks you have a few different ideas here. Ill do my best to separate them, tell me if I am right. The first that I see is templates. I miss templates SO MUCH you have no idea. I could go an entire supcom game without building any standalone buildings- everything was a template. I'm pretty sure that some type of template system could be implemented using the current modding tools, actually, though no one has done it. Next I see what is often called 'orders as first-order entities' or something along those lines. The idea is more or less what you said it was- I can create a move order, a patrol order, whatever, and then assign units to it. Ferrying and maintaining a template sort of fall out of those two ideas. If I place a template, then ask builders to assist it, then they should not only build that template, but keep it built. Assigning transport units to a transport order should make them automatically ferry other units that get assigned to that transport order. The last thing you mention is something else entirely- implementing a rudimentary form of logic or conditionals into these commands. I could see these being lots of things, like 'x amount of units present' or 'x amount of nearby enemy units'. Stuff like that is... different. I had a similar idea a while back, called AI Nodes that also allowed this sort of pseudo AI. Apparently, it wasn't very popular. You don't happen to be a programmer/software engineer, do you?
The reason I group them together is that they are conceptually and most likely (in implementation) graphically similar. Ultimately how well they work is going to depend dramatically on how intuitive their interface is. my logic runs along these lines: Players are used to seeing an overlay of orders (using the shift modifier) and having another modifier (or the same depending on clutter, alt perhaps, just don't bind f4 or tab) that displays another type of standing order would probably be intuitive to the current player base. Secondly, players are used to orders having different outcomes depending on context. We are used to an assist acting as a build/repair/guard and right click acting as move/assist/attack/follow. So long as we keep these outcomes consistent we can greatly reduce the complexity of this (which is important to keep it intuitive and uncluttered). While I can see that you could separate them, the intention of combining them is to let them solve a larger set of use cases. I think the trick with all of this is trying to see if it is actually useful and adds something to the game. It could well be that any form of conditional isn't intuitive, but lets consider a concept of implementation: I see these implemented as a visual set of layers shown and manipulated when a key modifier is held down. With this modifier pressed you can visually place commands that imitate and replace the ones you normally have (move/assist/attack). Once placed they remain visible as graphics overlaying the game and selectable as entities (as long as the modifier remains pressed). If you select a previously placed command you can set it's rally point (as you would when using a structure), if you place it's rally point on another placed command, units completing the source command will route onwards to the rally point command. Generally when you have something selected in game you have a set of options available to you centre bottom of the game UI (in a factory you can produce units, on the commander/engineers you can build structures). If you wanted to put in conditionals that's where it would go. It would be interesting to see if that started to feel cluttered or even useful. Conceptually I see all of them as orders and felt that keeping them together helped keep them intuitive. Also yes.
Agreed, but you wouldn't have needed to write that all that. It's an old idea: http://planetaryannihilation.wikia.com/wiki/Orders_as_First-Class_Entities_(OFCEs)
That's a pretty dismissive response. I see no reference to a mechanism to treat prefabs as a continuing order that can be maintained repaired built or defended. No mention of how these could be treated as base entities bound to conditional outputs. No mention of conditionals or how they might be implemented. Not to mention that the core idea I outlined above is a suggestion of how to integrate all of these disparate concepts under one singular control scheme so they can be used intuitively together. The page you linked doesn't describe an actual implementation. It contains questions like " [how to delete them?] [how to copy and paste?]" which are explained and resolved above (when a modifier is depressed you can select and manipulate them directly). While I have now learned that this concept is called "orders as a first class entity" within this community and is pretty prevalent, I disagree that there is nothing contributed above. If nothing else, in the programming concept that you draw from a first class object can also be the resultant of an operation or the parameters of one. That is a polar opposite to the system outlined above where each is a completely discrete modular component which will always act in the same way for inputs (units in this case) and cannot be a resultant or a parameter. The intention here is not to create emergent mechanics but to instead provide tools that allow the player more time playing and less time micromanaging (which I accept may have been your interpretation of orders as first order objects in the first place).
I think that we might be talking from the same side of the coin here. When I said 'seperate these out', I meant that for just the discussion's sake. If they are implemented, then I think they should be completely integrated into the same system, even more that you do, I think. I see what you are saying about having a 'strategic layer', but honestly, do you think that's really necessary? Instead, just make the graphical end points of the commands contain all of the information. A command is represented by a colored line connecting with one or two 'endpoints', one at the start, and one at the end. An endpoint can exist without a command line attached to it (templates). When the two endpoints of a command meet, the command ends. Assist and patrol orders only have one endpoint. Endpoints can either be assigned to units or to locations. Clicking a unit onto an existing endpoint 'gives it' that order. With those rules, everything else that vanilla commands do, plus what we want to add, falls out. (except conditionals) No extra layers, no extra lines, and we already have graphical endpoints, they just don't do anything.
+1 for me on this. Even if this was just for troop transport i'd take it! Moving troops to planets is a nightmare. If I could set "pickup point" and "deploy point" and assign 100 carriers to it I would be happy. I could just sent my units to that point and the carriers will pick them up and ship them to the other planet/location. This isn't just easy mode either. Automation comes at a cost: neglecting the opponent. Not paying attention could easily result in destroyed carriers.
The reasoning behind a separate "layer" was simply trying to find a way to make it easily usable by the player. In this context I mean layer in the same way that pressing shift shows currently issued commands. Generally speaking, orders are only displayed in any RTS when a modifier is depressed. I suspect that making them permanently shown would not be visually appealing. If we just reused the shift key then the only way to route units to it is with shift depressed (you couldn't issue a new order, just add another one to that units list). I suspect that you would probably want the layer shown when the shift key was depressed, but having a separate key for manipulating and showing/hiding them seemed the best option I could come up with (open to suggestions of course). I also suspect that it would be intuitive to the current player base.
