Distributed Management Mode for Units/Buildings

Legal/Disclaimer: Anyone hereby has the right to copy/redistribute/implement/etc the following in whatever they see fit with out my explicit permission in their game/product/etc.

I don't believe game mechanics have any legal basis for copyright but just in case I just wanted to get that garbage out of the way so nobody has to think about it, since I know of another game where something similar caused unfortold amounts of drama.

-

The posts describing the systems are fairly long. If you dont have the time keypoints are highlighted in Purple.

Before I start I would just want to point out that all the following systems I'm about to describe DO NOT force you to change the way you play at the moment. If you are in love with the way you build, control units and such then you would be able to continue to do what you do best, the systems I suggest merely provide an alternative control system that happily coexists with the current systems with out even requiring a toggle switch.

While I would love for the following to be in the game, if it would just be feasible to mod it in the game that would be awesome too. Currently, while I haven't looked too deep into it, I believe it's not possible to mod this level of control.

Okey, so I like game that have a powerful base building system in them but I feel the classic, click unit, click building, place building, doesn't really work too well after a certain point. I'm not saying it's unusable, I believe it's perfectly fine for games with relatively small bases, just that there are a LOT of small issues with it with large gameplay ramifications. I believe when playing the (very average) player should be able to play on a 30% split between the important activities of the game: 30% time spent building things and base management, 30% time managing units, 30% scouting, intel, strategy and tactics (and 10% left is for reacting to enemy moves). Right now I feel a lot of factors kind of force the game into a 70% time building stuff, 20% simultaneous managing unit management and tactics (ie. send balls of units in roughly the right direction), 10%, if not less, reaction time.

Things that slow building things:

• you have to manage rally points for all your buildings
• you have to micro manage workers to build things
• once you get factories in more then one area (ie. forward bases, side bases, etc) it becomes difficulty to manage those
• there's no way to rally unit types; ie. things like rally all workers from factories to one point
• you can only build multiple things via shift click with a set of workers
• if a worker dies you lose the entire shift chain of buildings
• you can't tweak a building chain once it's started
• you can't assign workers to build something if another worker was assigned a shift chain to that location
• if some large group of building dies you have to waste a lot of time rebuilding it
• you can only start to worry about rally points and unit production after the worker started building (ie. backtracking problems)
• due to the hectic nature of build things quick you dont have much time for sophisticated layouts

Units are a lot more manageable but you still suffer from similar issues, such as everything being a "ball" of some description: ball of bots, ball of bots with tanks, ball of artillery, ball of aircraft. This is largely because there's no current way to organize units in a "smart" way and there's no system to make it easy to do so. In addition another issue with units having no "deep purpose" to them is that the players incentive to "keep a group of units alive" is somewhat nonexistent; almost all groups that attack an enemy are sent on a "victory or death" mission, which is FINE, but makes for somewhat shallow gameplay mechanics and reduces the number of possibilities.

Tactics fortunately suffer from only positional issues, ie. it's not as easy as it could be to move units into the correct locations due to sphere mechanic of planets; coordinate attacks are also hard. Same for flanking. A big issue in my opinion is that if you have multiple dedicated groups, once you select them all they become one giant ball; which tactically is unsound since while a super ball does the job it also means the players forces easily get concentrated into one place, thereby the possibility of multipronged attacks is dramatically reduced due to balls of units being hard to split up (other then into balls of single units, ie. giant ball of only aircraft or giant ball of only tanks; which are really not much better if not strategically dumb).

Distributed Base Building

The idea is simple, instead of having a worker build things you just designate a "plan" and workers which are idle (as well as not on "hold position") will come and build it.

You are able to create a plan even if you don't have any builders and you can even plan buildings which you don't even have access yet such as advanced factories.

All your planned buildings would show up in a que. You will see progress as well as be able to move builds up or down the que, ie. change their priority. Via the que you can also set:

• worker que defaults: how many workers should be building a building by default (numeric slider, default: 1); which type of workers are allow (options: bots, vehicles, ships, aircraft, orbital, default: all)
• worker que item settings: how many X additional workers (ie. default + X) to assign to project, worker type overwrite, cancel option, skip option (ie. not canceled but will be ignored), ability to move item up or down obviously (preferably this would be select items / drag to allow for multiple at once)

The plan would also show building stream costs. Which is to say not the cost to build it but the cost to have it. So if say you have a land factory you would see -12 metal -675 energy in the que. This will help a lot in avoiding the constant "economy gone to ****" syndrome which currently can only be avoided either by memorizing very exact build plans, using very meticulous strategies when building (ie. know requirements and build just enough power and metal before building factory, repeat) or just plain going panic mode after it happens (from what I've seen usually always end up with panic mode one way or another).

Here is a simple concept:



Just to be clear in the concept above the maximum allocated workers refer to how many workers can work on something over the entire que. So basically if you set it to 10 and you have 20 buildings qued and you have 1 woker per building and 24 workers you will get 10 of those 24 workers go build 10 buildings at a time. That said, if you set extra workers on any building to say 15 then you will get 16 workers working on that building and nothing else being build since the logic would be: player initiative takes precedence, since max workers were assigned nothing else can be built.

In the build que the little wheel next to the name would indicate buildable status: white means it's qued, spinning white means its building, red means its unbuildable due to various factors (you would be able to hover to have it tell you that you either dont have any idle workers, don't have correct fabbers to do it, its not accessible to the fabbers you have, etc).

The edit icon at the end would open the building view (even if its not built or started yet) you set any options and they would be persistent. Even if the building is destroyed the schematic would remain and in planning mode you would be able to just select the building with a wrench to fix it (ie. add it to a que to be rebuild); obviously area commands would work fine if you have no economic worries about order in which things are rebuilt.

In the edit window you can also set special build options such as "only build with air fabbers" which completely overwrite defaults. This is useful for say forward base building and such. If the building's build options have been edited the edit button will show yellow, if the buildings unit production and rally points have been edited the edit button will be red and if both have been edited it will be orange.

You should be able to move buildings that have not started yet in planning mode. Just in case you made a small error in positioning.

Some more building templates for visualization:



From left to right forward teleport, production, siege, defense.

If you've just skipped to these images, no THIS THEAD is not about building templates. Images are just there to illustrate some concepts that are harder to put into words and proof of concept.

Distributed Rally Points (and Reinforce mechanic)

Very similar to distributed building in that it works with idle factories and does not interfere with current rally points or system.

The way distributed rally points work is that you place a distributed rally point and then you are able to select it as say a factory. You can then you can order a set number of units to that rally points. Factories that are idle will try to fulfill that order. So if you order 20 bots, 10 tanks, 3 artillery bots, 3 artillery tanks the workload will get distributed between all your factories. The more factories you have the more efficient it is. You do not have to actually know where the factories are or set any particular connection to the rally point. The rally point simply searches for factories that are idle and tries to put them to work.

Similar to building you can create templates to speed up the ordering process, in the case of units we'll refer to these templates as squads. Just like buildings you can customize them in the armory to be in a certain position and they will retain this position after their built. When you build a squad instead of ordering a unit batch you will get the squad as 1 unit, and on your map you will get the squad show up as a special Squad symbol with a name instead of the usual unit strategic icons. You are free at any point to dissolve the squad which will just give you back micro control over all the units in the squad.

There's one other benefit to squads other then specialized formations. Each squad is a distributed rally point, sort-of. Basically, lets say the little 20 bots, 10 tanks, 6 artillery squad we mentioned earlier is a specialized siege squad. And we take our little squad to the enemy base, but on the way sadly it gets ambushed by bombers and takes damage, everything but the 6 artillery survives. What we can do is use a "Reinforce" order. This will add a priority order that can overwrite normal rally point factory orders and will force idle factories to try to produce our 6 artillery as well as order the 6 artillery to go back to the battlefield. Assuming we had some forward base, our squad should be back in fighting form soon enough.

Reinforcing obviously doesn't really give any special advantage (since it's just using normal build power and mechanics), but it saves a lot of dumb-micro the player would have to do to get the same effect (map scrolling, factory selecting, precise unit building, rally point selecting, unit moving into position, etc etc). In my opinion under the same circumstances in the current game players would either merge the group into a ball and ram it, or simply never have such a specialized group to begin with.

Some basic squad concepts for visualization:



Area Commands

A small issue with distributed system is that with out some complex algorithms its possible for some cases of confusion or unintentional behavior, in particular if you have 2 players controlling the same army. To solve this, as well as many other benefits, we simply need to add area commands.

Essentially the planet map itself is one "area". Each planet is considered its own area. Orbit is simply ground area super imposed over (ie. not a different area then it's ground equivalent, just a different plane).

Distributed building will only have buildings search for workers in their area. Distributed rally points will only search for factories in their area, reinforcement mechanic will search every are (closest first).

Okey so roughly if you play solo, it makes no difference that we defined areas. Now onto custom areas.

You can define a custom area by select a custom area tool and dragging a circle on screen in a single stroke. Once you've ended your stroke you will get a box for name and the point where you started marking the will get a area entry point. An area entry point is merely a circle with 2 arrows in showing how things move to and from the area. Units produced via distributed systems will try to move though those areas.

You can define 2 types of areas: friendly and enemy. Entry points in friendly zones indicated where units should try to exit from, while enemy zone entry points indicate where units should try to attack into. You can move entry points and add more if you wish.

Here is a simple concept for using area tools to define an enemy area:



In a game with multiple players, players on opposite sides of a planet can simply create an area to make sure their distributed building ques are targeted to that area and use only bots from that area. In a 2 player shared army so long as at least 1 of the 2 players does this there should be no dumb behavior for example.

But wait theres more...

You have a list of all the areas, with some units selected you can simply select the following from a specialized area menu:

• area attack > [select enemy area] > any
• area attack > [select enemy area] > multiprong (splits up units equally and synchronized attack on all entry points)
• area attack > [select enemy area] > [select entry point]
• area harass > [select enemy area] > [select entry point] (essentially "go on a rampage, run away from enemies that attack you")
• area defend > [select area] (goes to defend against units entering an area, automatically reinforces units)

By having areas and entry points defined you save a lot and more dumb-micro since you avoid having to say move the map to select units, move the map to give the command, periodically check on map position on the other side of a planet for when units are near enemy base, try to synchronize attacks. Lets face it when some APM monster comes in they maybe might be able to do it efficiently all the time, but even then that's less then 1% of the player base. With area commands even average joe can enjoy depth in battlefield tactics.

-

That's all. Opinions?

you bring up very valid points.

I like your ideas. the base building template and queue common to factories in particular.
you'll find you're not the only one to think these things.

there, in my opinion should be this and many more macro tools

did you hear about the orders as first class entities idea?

the split queues idea?https://forums.uberent.com/threads/construction-streamlining.48712/

the future orders idea?https://forums.uberent.com/threads/future-queuing-reorganizing-orders.53140/page-4#post-827011

backwards order idea?https://forums.uberent.com/threads/the-ultimate-order-queue.46531/

https://forums.uberent.com/threads/factory-management.56929/
https://forums.uberent.com/threads/on-production-queues-advanced-factory-ui.36166/
https://forums.uberent.com/threads/suggestion-global-build-menu.35178/
https://forums.uberent.com/threads/multiple-rally-point-for-factories.54333/
https://forums.uberent.com/threads/suggestion-ratio-based-infinite-repeat-factory-assist.54348/
https://forums.uberent.com/threads/feasibility-of-major-interface-functionality-changes.56218/
https://forums.uberent.com/threads/expanding-on-base-templates-to-conserve-player-attention.56334/

https://forums.uberent.com/threads/unofficial-official-gui-discussion-thread.52055/

Forgot to mention. Building templates can be used to allow players to relatively easily create custom ai experiences. You simply need to have the ai understand +/- energy and semi-dynamically judge value of templates.

It would also make for nicer looking ai bases too of course, it's just a matter of how much effort is put into making the templates.

@tatsujb thanks for the links, I've actually searched but obviously not the correct terms. Since I'm not active on this forum I didnt really see those before. Glad other people shared similar ideas.

oh that doesn't matter, don't worry.

I don't care about you searching or not. Your thread, in this case, is better laid out then the previous and groups together a couple of those ideas.

for future reference though, If you want to search, know that the search function on this forum is broken and that the best way to get results is through google by typing : site:forums.uberent.com then your keywords.

Please have a read through the future orders thread an tell me what you think.

I have not read all of it, but I knwo what you are getting at and I agree. Way back in 2012 I made a thread on soemthing that touches on what you are addressing: https://forums.uberent.com/threads/global-construction-orders.37223/

It's in my links above already, ^^ goes to show how little you read.

No it's not? Or I'm blind. But I checked your links twice, once before I posted and once after your reply.

Added some more pictures. Intended to from the get go to have them, but making those "mocks" is pretty time consuming.

@tatsujb

I skimmed though the first part of the thread since there seemed to be more confusion then ideas. As for the actual post you linked to:

If I understand correctly (and this is just my interpretation of your description), in your system you would have say the commander que up metal, metal, power, power, bot factory then while the commander is busy building the resource buildings you would be able to select the yet to be even started bot factory and say que up 10 fabricators and there would be some new part of the interface that would show the qued up units as a list (as opposed to just portrait with numbers) which you would be able to click and issue orders such as building vehicle factory, and you would be able to continue this future ordering vehicle fabricators.

My main issue with the idea is that chain commands aren't really necessarily all their cracked up to be. In your system for example you would have to have shift as a toggle and have a system by which if a fabricator is destroyed the entire que of that fabricator remains in the world and the fist item in the remaining que is somehow maked for the player so that he can assign a fresh fabricator to that (assuming he notices/finds it). However not even something as sophisticated as that can account easily for say something like changing the que of the factory.

I actually have a more que heavy playstyle, as in where people would have one fabber build 10 power plants, another build 10 metal, another build 10 factories, I go for the more braincell heavy 1 fabber build: 2 metal, 2 power plants, 1 factory, because I don't want to have a playstyle where I overbuild. What I've found though semi-painful experience is that chains (which are not necessarily the same as que's in that they have 1 unit or a small group entirely responsible for them) are just a incredibly fragile and annoying concept to work with. Not only are the easy to break, but they're also difficulty to manage in general. The thing is, a lot of the times it's not just about building the things you want, but actually getting things up efficiently as possible and redicting resources can be just as important if not more important, and chains of commands are really horrible in that respect unless you've set the absolute perfect order chain for the game in question (highly unlikely) or have some really sophisticated "history editing" tools to manage them. I really don't like the idea of spamming things (like really really dont like it) so the way I've mitigated it in my own game is that I just have all fabbers gather in a specific location. I issue orders to build a small base (since my way of building naturally spread production out closer to metals due to building structurally) then issue order to have the unit come back to the rally point, then select another fabber or group of fabbers and issue orders for a another small building mission with return orders. A lot more reliable results, less to worry about, less things to check on the map, only very small neglectable chains can break which fortunately I can safely not worry about (ie. check map, check fabbers currently build, find fabber missing, remember entiere giant order chain, get new fabber, repeat entire giant order chain.... see what I mean by painful?).

With regard to the reclaim order debate, I just think fabbers should reclaim automatically, so it's not something I have an opinion on.

Okay, I finally read the whole of your two posts now. And I especially like the squad idea. In fact, I have thought about a squad mechanic in TA-esque games myself like 2 weeks ago. Having squads would really ease controlling your units. Imo squads should be possible to be formed on the fly though. By just selecting a number of units and pressing a key or button. I also lie the idea of defining areas with entry points and the different attack moves bound to the areas, though it my go a little far towards automation.

@thelambaster the way I think of it is that so long as the game is merely carrying out a command with minimal effort then its just an interpretation feature and not some "too helpful ai". If the ai was for example carrying out orders like magically find the most vulnerable place in the enemy base then it would be a "too smart" issue.

Distributed control and templates/squads are just doing a dumb thing in a smart way. It's all player initiative.

Btw, how would squad work with transports. That might cause issues. Would they be disbanded? Or will the be split across transports and the transports automatically drop the units in close proximity so the squad can back into formation?

@thelambaster

They wouldnt work too well with the current transport system; you can make it but I feel many of the ways to make it work are just too complicated/annoying (for the player) to be practical; I like solutions that keep things simple for the player. But I dont really see the current transport system as being the best iteration and it will probably be better implemented later. With a point to point ferry system for example they would work fine, they would just get farried on mass if you have enough.

I've got an idea:


Say members of the same squad get connected by a bright chain indicator that runs from one member of the squad to the other, to indicate that these units are together in a squad.


Say you have 24 units. 18 of which are form a squad. 6 are single units. Then you have 2 transports. Say each transport can carry 12 units.



You tell the 24 units al together to load up into these two transports. Say with an area command. The transports will then try to get as many units of a single squad loaded up into one single transport as possible. That gives you one transport with 12 units of the squad, and one with 6 and 6 independent units. because the two transports are now carrying units of the same squad they will themselves become a squad for as long as they each carry units that are members of the same squad. The transports will also be connected by the chain indicator and also act like a squad. So when you give an order to one of them the other one will get the order as well.



You also get an option to disband the transport-squad on the fly, which then splits the unit-squad onboard into squads that consist of members of the bigger squad on board of the same trasport.

How is that?

((the @ doesn't notify))
exactly! upon reading your post I knew you'd understand straight away! I guess I was getting high hopes when I though everyone on this forum would be smart at first but you're definitely raising the bar here!

as for where you kinda loose my trail:

that's what I was waiting for you to say.

In the other thread I mention how queue editing in FaF is feature-complete. there's really nothing you can't do :

changing order of structures to build___________changing order of units to build (both using click and drag)
adding a structure to anywhere in the queue____adding a unit anywhere in the queue
deleting a structure anywhere in the queue_____deleting a unit anywhere in the queue
editing placement of structure________________multiplying/decreasing amount of said unit to be built in x queue slot


It's only because all these things were possible in supcom in the first place (in easyly the most intuitive interface I've ever encountered) that I thought this was a valid idea.

All there is to do is improve on the queue system from supcom faf by adding in the possibility to select any white wireframe as if it were complete.

(this would be usefull if only for the selection part to be able to alter placement (which is cruelly lacking in PA right now) and cancel structures in the middle of a construction queue by alt-left clicking it).

Huh? You can't do that. Unfortunately...

more or less. do you have GAZ ui ? it's in stock faf.

in this case you'd have to delete the structures in the list at the end and stuff.
so yes it's more tedious but you can do it.

but back on track the point isn't what to do with supcom but what to do with PA.

and I see no reason to not have a click and drag list both in structure and unit queue in PA.

Yes, I do, but since when can you do that with GAZ UI? And also, how?


Edit: Deleting structures fom teh end of teh list also is possibel without GAZ UI and is not the same as adding structures somewhere else than at the end of the queue. So... ??

I assume the whole line between units is a visual thing not just an implementation detail. I think when you stop and look at it for a while it's not really the sexiest of ways to group. I mean it doesnt really convey any information to you in any other situation since it's hard to interpret ziggy zaggy lines (especially at high zoom levels). Also while it looks fine for 1 squad I can see it be really confusing if you have say a lot of squads potentially botched together. You would just see zigg zaggy lines everywhere.

The problem when you look at it as "load/unload" isn't that difficult, it's the whole well what happens if you split transports and unload in different places? (which can result in awkward behavior ingame—from the player perspective). In your suggestion I believe the solution you propose involves basically gluing the transports with squads together, but this is not necessarily favorable since often with transports you might want to split them up if they're under attack so at least half of them stand a chance of escaping; players might find it annoying if you force them into a mandatory ball of transports. There's also small implementation issues like, well say you disband the "squad of transports" does that disband every squad? err.

The whole transport loading problem can to some extent just be implemented with really smart behavior ie. I load a unit it shows up as a regular unit (maybe with some special border at most to show it's a squad unit) and when you unload the unit tries to find it's squad members and regroup. The units memory of it's squad members goes away after a few seconds of being completely alone. So if you load 1 squad in two transports and drop them in two separate areas the units form 2 incomplete versions of the original squad and become independent squads for the rest of the game. It's not perfect either but there should be fewer things the player has to think about; and fewer complicated corner cases.