Distributed Management Mode for Units/Buildings

Even if it was proven to be usable the question is still if it's usable in a real game by a average gamer. I mean you can have the most complicated system possible and force it to work, but what's the point if nobody's going waste the time required to make it work while in a real game. It's like if you have a dumb option and a "smart" but really time consuming option almost all players will (if not immediately, eventually) go towards the dumb option; player mentality.

I own the games but I'm not familiar with the system you mention. Was it heavily used by people? I got them really late so haven't played much.

No, if you do that you have no way of seeing which transports carry units of the same squad. You need a visual indicator to tell you that. Obviously the blue links were just the first idea and maily served to make the point. But you need some visual indicator.

Apart from that squads should not get tangled up. They shoudl keep cohesion and seperate themselves from other units a little.

? What I said was:


A Trasnport-Squad consists of all trasnports that carry units of the same squad. When the transports get seperated by unlinking them the squads on board also get split. But the local connections stay. So splitting these two transports will give you 2 squads. The yellow one, and two red ones, which formerly were 1 single big red squad.

as I said here:

it's far from complex, in Supcom there are a couple keys to memorize and as @thelambaster pointed out it's not as feature complete as it could be but here's a possible take :

instead of having to alt-right click on a wireframe to remove a structure from queue, right click alone would be sufficient (this of course implies deselecting units beforehand and that all future queues are visible when shift is held). (I personally prefer the use of modifier keys to allow you less mouse clicks and to be able to multitask better but hey)

to develop further, I suggested in my other thread that the lines going from queue order to queue order play an important role. What I mean is, not only could you click and drag a unit from the build bar the queue bar but you could do the same to a structure: this would instantly bring up the structure's wire frame to place down (you already have the when, all you're missing is the where).


Now let's try this backwards : you click and drag a structure from your build menu, but instead of dragging it to the queue bar you drag it up onto the map. this brings up the Wireframe but also the selected engineer's build path(s).

Now before clicking it down you should drag it around to find your desired when by finding the two structures that should be the one built before it, and the one after it and making your mouse pointer cross the line going between the two, at which point the wireframe snaps onto the build queue path and you can now choose where and then click it down. for the snapping part there's a variety of UI choices available, I think a user input will be useful for certain to avoid it re-snapping all the time. one could imagine not even physically having to find the when and simply using mouse scroll to scroll through build steps (changes being visible through the queue bar).

so now we have a pattern : want to add a unit? left click it. structure? left click it. want to remove a unit? right click it. structure? right click it.

not a single modifier key.

How is this not interfacing 101? it's a rookie's dream interface come true.

And whap happens when you want to give a move command with RMB where the wireframe of a future building is loacted? I think a two key combination is safer.

Is that really that important though? It's almost impossible to load a squad from two different locations since it's one cohesive unit.

Ya, don't get me wrong I get it, but this is what I mean by making things too complicated for real games. Even if it's playable you don't want to feel like you're doing rocket science while playing. Any sophisticated system should at least have a gamey-feel to it. Like for example when you manage your equips in rpg or items take different space you have a sense of playing mini-tetris game in your inventory, you dont' go into a spread sheet of items for example. I think keeping everything in the game aimed at some semi-fun activity is important to keeping the game cohesive and "a game" =P

Honestly after thinking about it the best game-friendly implementation is probably:

• a squad can only get into a transport and maintain squad status if it can all fit into one single transport; if it cant fit, tough luck, design smaller squads >=P
• you have the ability to select a group of units and forming squads by banding them togheter (basic build menu when you have multiple units selected)
• if you want to transport an arbitrary number of units just disband, load it up and reassemble your units into squads on the other side; it's virtually instant formation into squads since there's no actual building involved
• current transports are changed so they can link togheter to form a single unit

Good ol' Keep It Simple Stupid

The activity of forming squads should be generally rewarding. And squad remixing should also have a nice feel when you get good things to happen. It also gives players a better sense of what they have and what it's for at all times, ie. 3 siege squads, or 2 assault squads, since it obfuscates the unit counts.

-

This has a lot more potential for other uses too. Say you had a bunch of siege squads that consisted of tanks, antiair and siege units. In an unfavorable engagement you could just disband and reform into some assualt squads (ie. only tanks + anti air) to be able to buy time for your artillery units to get away.

I really don’t see what is complicated about squads spread across multiple transports? Imo disbanding squads just to transport them and then having to tediously manually reform squads out of the conglomerate of units at the drop zone sounds pretty much like the opposite of fun and simple. Also it is impossible to reform squads while doing an assault drop, because you need to start microing right away and have no time to prepare.

You can have the option to reform on drop while they're in the transport. It would just be: open squad list, click or shift click the squads you want. I find it unlikely you'll have that many units even with giant armies that you'll have much issue reforming squads. It's technically no more complicated then ordering the building of X tanks or Y bots.

Ah so you mean with a button that automattically reforms the former squads? Ok that sounds good.

so do I but I did provide a parry for this :

@thelambaster

No I merely expanded on the "you can just form squads from a selection of units" to cover dropships.

What I meant was that you could select a group of dropships while they're on route and the selection will take into account units inside the dropships. So if you give orders to form squads while the units are in the dropships (ie. you have dropships selected) the drop will result in units automatically trying to form the squads you asked for after the drop happens (and this will work even if you say lose dropships; while linking units togheter in dropships may cause you to have a bunch of incomplete squads even though as a whole you have enough units for full squads). Implementation wise, essentially the command is buffered to the selection even after you deselect the units and the whole "moving in the dropshio" is a higher priority order that the units in the dropship actually have while the dropship has control over them. I hope you understand my explanation since going into further detail will just end up in a tangent towards orders as first class entities, as there's a lot more you can do with buffering then just form squads.

If getting the former squads is really important you could have some very simple ability to save the selection. This honestly feels like a separate mod feature though (even if squads themselves were to be implemented as a mod), just because of how different people might want that handled in a variety of different ways and some might just not care for it at all (ie. prefer less clutter that might be caused by it). I don't like the idea of the game having an implementation of a system that's very hard for a average player to grasp, since that takes away player control and initiative and I think saving templates of squad groups is going a little too far for a base squad implementation (be it ingame or mod).

Personally I feel that if you're in a situation where everything is so hectic you cant remix squads into something else or even from them from a small group (even though it might be as simple as SquadBuildHotkey > Desired Squad Hotkey you've set) then forming squads out of those units in that situation probably does nothing to help you so just work with non-squad based blob until you get some room to breath.

The way I described squads at least doesn't replace normal behavior, so you're not forced to use them if it's not more convenient to do so. I mean you don't get stat bonuses or anything outside of meta positional bonuses. Just like templates I like to think of it as a quality of life thing.

Personally I would prefer a caret or something similar that I can just place somewhere in a visualization of the que, just because it's a more obvious call to action where as the ability to move it backwards might not be obvious with out some tutorializing. I mean sure people who used this supcom thing (which I never noticed) might know it, but everyone else might not (ie. me in this case).

I'm also not too clear where exactly in the ui this would be. Since this is not standard ui what it does is only as strong as how easy it easy for someone with out any prior knowledge of it to figure out (a) it's there (b) why they want to use it (c) what they need to do.

Having ques and such may seem nice but if you say look up games Nexus: The Jupiter Incident (you can find it on gog; it may seem easier looking at screenshots or people who know what to do) which was a 3d space battle strategy game you'll find the control it has when you apply a ton of your modern gaming knowhow takes a very long time to grasp (for most people) even with the tutorials they have. And that is if you dont just out right give up on it because it's asking too many different things and not giving you any rewards along the way. And this is a problem, since people's patience (especially these days) is a finite resource. I'm trying to imagine the system you describe tutorialized and I'm kind of seeing it as tacking too many steps and having no obvious "reward" at the end for the player going though it, nor any clear incentive to the player of "why they WANT to know this," again very similar to how I feel about the Nexus interface: once you know everything it's at best fine, steep climb to get there though.

Basically what I'm saying is you probably need more layers to it (ie. a really easy basic version; with more depth underneath, so people can be welcomed in with "here you can just learn this easy way" and opt into more complexity themselves), or some other way to ease people into it. As well as better defined use cases; right now a lot of use cases, from what I read anyway, are not very precise so it's dependent on the person reading to decide if its giving an "advantage." To me for example it kind of leans towards "does that not take more time due to complications it causes?" as I mentioned earlier.

There is a fundamental difference between a game that is hard to control and complex controls that allwo you to better control the game.

Yes but complex controls easily lean towards hard to use controls if not kept in check or get "over-engineered" as it were. The user has to be part of the equation at all levels, they can't just be "complex controls."

While complex controls don't necessarily make for a hard to control game, isn't it true that hard to control games generally have complex controls? Just like a picture it has to look good even if you flip it, so you can't just excuse complexity by tacking only one point of view into it (ie. some ideal end result).

Well, I'd say, as log as peopel do not have to use the complex controls, because they don't want to bother understandning how they work, and can get the job done (more or less) by microing like a madman...

@thelambaster

That's the thing. At least in this iteration, because I actually like @tatsujb's idea, the solution might actually involve more micro and/or more time consuming micro (ie. slower micro) then actually just doing it one step at a time or with fewer steps.

Really I see it as a much more straightforward then a lot of other mechanics.

In anycase PA is a serious-style RTS with massive numbers of units to handle. You need someone with a big attention span to play these sorts of games. I'd say due to the quickness of starcraft II you don't even need such a long attention span, unless you're engaged in a longer match.

I did play nexus the jupiter incident, and as you very well described, that was my experience with it, and yet supcom with all it's nifty keyboard tricks and such did not fatigue me.
What really killed me was that the game was sold as a "space-RTS" and in it you could only control one unit.

whatever the case is, this is only your "step up" kind of material. In no way are you cut of from using PA if you don't know/use this mechanic at all.

Heck, people right now play it without even ever using shift or PIP.

and considering my idea is contained entirely within the "shift level" noone need use it if they don't want to.

I don't see what the harm is in it being there.

Like I said, it's not that I dont' like the idea, I just feel it could reach a wider audience and be easier to use if there was something more in the middle ground between what it does and the player. It's like if you have some very complex settings in a game or any application and you just take a few of the important parts of those and bring them to the general "easy stuff" toolbar—for lack of better analogy. Of course if it just stays a high level feature that's fine too, I just feel by it's nature staying high level is giving it a very niche scope.

It's hard for me to actually try and give something like a more on point suggestion on it since like I said I'm kind of biased towards long chain of commands being iffy due to having bad experience with them and can't really imagine it's uses past the first 10min; which is not to say I don't think it has uses mind you. I'll keep it in mind while playing, if something comes up I'll just come back with more targeted feedback on it, since I personally don't really like things being too abstract in a discussion (too much explaining and going in circles).

The notification to replies comes up so long as have the quote tag with your name, yes?

Yeah... I get it.

But my idea does have something progressive about it:

you start using shift because you want to queue up 3 structures, not just one.

later on you start dragging the wireframes from time to time.

then you learn you can also cancel in the middle of the queue through shift as well.

then you figure out you can also change the order.

ect ect.d

Hm. Ya that makes sense when you put it like that. I was thinking too hard towards the ordering fabber units qued in factory.

knew you'd come 'round.