Global Construction Orders

Of course it would. An engineer would not leave his assigned area of operation to start building something outside that area. If no engineer is operating n the area you placed the building you need to manually assign it to some engineer. I also don't see why it would require ‘much logic’. You could do at as simple as this:


Place building orders (like those green 'not yet being built'-buildings in SupCom) on the map and THEN take some engineers and right click that green ‘not yet being built'-building. That's it. But of course it would be better to expand the system to what it could be capable of.

You quoted my post, but I am not sure what in particular you responded to .

Those two assertions. Primarily the latter.

I am still confused, the first one was in response to the Global Construction Orders discussed in the orignal post, while the second one was in regards to area commands. The first part of your follow up post seems to be concerned with the former. But then you say

which is something you do with area commands and not with Global Construction Orders. If you meant Global Construction Orders in both cases, I'd reply the following

That right there is already more logic than there would be originally present. Also, what if you don't want engineers to automatically build any queued orders, but want them to build them sequentially, like you would normally do?

This is something you would do with area commands and doesn't seem to have anything to do with the idea proposed in the original post.


// although now that I re-read the OP again, I am now confused about what he actually wants .

Well, I am the OP... you know?^^ And I can tell you it does have to do with what I wrote in the starting post. So either you are the only one confused, or if not I need to rephrase the whole thing... I hope not, because it's actually pretty simple, you are just making it complicated.

I already offered a solution t that. See last post on page 1.

lol, yes, I am horribly confused

I never said, that there are no solutions. I am also not saying, that these solutions on its own are bad. All I said was that you would need to have much more logic in it, in order to work properly and not screw things up. Evidenced by the things you already posted .

I made an illustration:

http://i.imgur.com/LRT66.jpg

I don't see any time savings over the system in TA/SupCom.

I liked the SupCom (FA?) select idle builders button by the way, I'd like to see that reappear.

I'd also like to see builders will automatically go into patrol mode when idle and conduct repairs/assist with nearby construction, but still show in the idle builder list (as they haven't been manually assigned with any tasks).

I would also like a feature from ZK. Nanoframes can be selected and given a 'build priority'. High priority means that engineers working on that project will consume as many available resources as their buildpower allows, with remaining resources distributed among normal priority projects, followed by any remaining excess being mopped up by low priority projects.

This is a great touch for the streaming economy as it allows resources to be easily maximally consumed (by working on expensive but low priority projects) whilst also allowing for targeted and fast construction (e.g. mark a frontline turret as high priority when you need it up and running immediately). I find this feature pretty much essential when playing ZK.

How can you not see how this is faster than it is in SupCom (again, don't know about TA)... I think I gave a pretty simple and convincing example in the startpost. It is superior in its power. You can do more with it whilst it is not less fast, also given the fact that the whole thing could be made - as I proposed - optional to the conventional system...

... I get the impression many an idea that is unconventional gets rejected by big portion of the people just out of conservatism.


Edit: I agree with you on the points you mentioned, but those already had their own discussions/ threads.

Edit2: You do realize that the priority thing from Zero-K is very similar to a sub-proposal of mine?

Edit3: Of course for single buildings this is not faster but rather costs you one extra click (click marker in menu, place marker on map, select engie, assign marker to engie (but this is only the one case where there are no idle engies in the area)). Hence I propose keeping the conventional system in addition.

Ah ok. I thought that you were proposing this as a replacement for the conventional system.

As an additional system, maybe. Although a screen full of menus, some of which are partly redundant or used only in quite specific situations, doesn't sound like a fun UI. If this system is implemented then the menu should be brought up by a hotkey or unobtrusive button on screen.

I must have missed your sub-proposal regarding build priorities, but in that case, it sounds like we concur. Might be worth trying ZK (http://www.zero-k.info) to see how it's implemented there. ZK also has intuitive area commands and various other most excellent UI features.

Again, I understand it and I am not saying that there are no solutions to particular problems. To reiterate: I stated that you would need a lot of logic built into the system to work properly, as shown in your illustration. It's just not as simple as "select a building and place it on the map, done".

Also I want to point out again, that I am not opposed to this in general at all. I like such concepts .

All right, cool... :mrgreen: but still I don't know exactly where there would need so much more AI power (I assume you are referring to AI power?)... Evenly spread the engies across the buildings with the same grade f priority in an designated area can't be that hard to achieve, can it? If it is not that what you were thinking of please explain.

I am all in favor of an user customizable UI. I hate static UIs. So yes, drop down menus or expandable windows would be great.

Yes, I linked to the zero-k thread in the start post.

While I like the intention, I have a problem with this still. It would need a lot of extra stuff (builder modes, priorities) while it can also work fine without. just make builders automatically build on close range when they are idle and make all the buildings far away manually, having to remember the setting of each builder is not a thing everyone wants to do.

Another solution would be area commands, builder will try to do everything in the area, no matter how large it is, while prioritizing closer tasks.

I mentioned area commands a dozen times already...

Also:

Explain that. I don't know what you are talking about.


Edit: Yes it can work fine without it - if fine for you means not as comfortable, efficient and powerful as it could be. But this is a suggestion to improve the existing model.

In the image you state thinks like assist mode, a "do not build yet" setting. order hierarchies (the trees), build priority.

These things are all things the devs will need to add. Except from the assist mode, which I think could be helpful, All these options require the player to select things, which is just as much micro, as just building the buildings manually, using a +shift command to chain the build orders.

In my opinion, as how I understand your idea, is not going to reduce the micro enough, to be worth the devs' time.

Jeez! This enhanced build model would be way more powerful. Thus doing the same things with this model and the conventional model would reduce the micro dramatically. Of course it pay of the more the more complex the stuff gets you build. Because it would be a little less efficient for very simple stuff like single buildings you proposed keeping the conventional system in addition. But I am just repealing myself...

On queueing up the orders: This is a damn simple mechanic really:

<building under construction>[<engies building it>]

A[n]
B[n]
C[n/2],D[n/2]
E[n/4],F[n/4],G[n/2]


Vertical axis is time; letters in one line are buildings being built at the same time. Each time you split the amount of engies from vertex a by the number of adjacent vertices -1. Simple, eh? Ideally you could manually change the factors for each edge.

The way I picture it is that the RTS genre every generation gets new user abilities like queuing up orders or setting patrol routes that were not in the previous generation. Since Uber intends for this game to age well it will need to include if not just the ability to include new UI controls.

Well yes, but that is just speculation.


I just had coming to my mind: You could also add a mechanism that splits the number of engies depending on the build times of the buildings corresponding to the nodes adjacent to the current node of the graph (excluding the node corresponding to the node immediately dominating the current node of course). To re-unite two sub graphs would also be great..

That paragraph could possibly be the most complicated jargon to someone who hasn't read the entire thread, ever.

yeah sorry... but I wanted to post my idea without writing a lot... so here is a picture:


grey boxes - buildings (nodes)

blue lines - progression steps (egdes)