Warzone's power system

[Lancefighter]

That's why most skilled players, if they have time to micromanage, will micromanage things exactly the way the power queue does automatically.

Most skilled players given free time will micromanage /everything/ they possible can... but other than that, i cannot really say much about what a skilled wz player spends his time doing

...I'm not sure what you're trying to say here.

that was me reinforcing my position with an anecdote citing experience playing trunk vs playing 2.3.1a, used in a way that supports the idea of the flow model. Mostly something that fills space and supports one opinion over another. I write forum posts very much like i write papers for english sometimes >.>

That is, however, the kind of micromanagement I've been arguing against this whole thread.

refer to my comment above - A player will expand the time used to micromange to fill all available space.

The rate of change is the derivative of the number itself, so the two are intricately related. It's difficult to say which is more important, since they're important in different ways.

oh the flashbacks to calc 1

For the purpose of deciding whether or not you have enough money to do something, though, the actual number is a sight more important than the derivative thereof.

but on a serious note, I am of the opinion that either way, I would like to see how much oil+ i am getting per second anyway, regardless of the system of expenses. the total number is less useful in a flow based system, in my opinion, because it is flow based. When you lose resources at a rate instead of an instant, the rate of resource gain to me seems more useful than a number of resources.

Perhaps what we actually need is this giant power graph that fills a corner of the screen. It would show current oil amounts on the y axis, and time on the x. Thus, we have both current amount and current rate of gain in a single icon, and no numbers required!
(mostly kidding).

[Tenoh]

I see the point but i also have an idea,how about a demo beta game with all the options for player to try out then we can vote or something.Just a thought.

[BulletMagnet]

I saw this thread and got all excited, so I've skipped the last two pages once I saw Zarel say the code is complex.

It. Is. Not.

I've already written (albeit in Lua) 75% of an n-resource type rate resource economy, and a bunch of code to set up arbitrary extra networks (ala. having a player divide his economy into two independent ones). I have the algorithm/maths written down too.

Obviously, I'm deafly in favour of going for a flux economy.



Anyway, the issue with a flux economy is that you really don't give a flying toot about how much you have in storage. It's all about rate-in and rate-out - so much so that it's better to forget about the total cost of an object (ala. 1000 oil) and think of it in terms of rate and time (10 oil/s for 100 seconds). The UI most definitely should reflect this. Hell, I'd love it if the current WZ gave me those numbers as average/effective values.

Also, I saw an incredibly flawed argument on one of the earlier pages about producing tanks and not having any until four minutes or some-such. If you have five factories all constructing tanks when you don't have enough resources- sorry, from now on I'm going to defer to the SupCom wording for that situation: stalling - that is you have five factories stalling; you are naturally not going to see any tanks until four minutes later.

The exact same goes for a deposit-withdrawal system... so long as we assume that all five factories wait for four minutes so they start production at the same time. Having one factory start before the others is unfair. Because, with the flux economy, what is to stop me from pausing four factories and having one factory build all five tanks? It would then output a tank every minute... equal to that of the deposit economy mode.

A more fair comparison is one flux factory and one deposit factory, zero resources stored, both receiving +1 resource/second.

The flux factory starts instantly - because it can - and goes as fast as resources allow.

The deposit factory waits for the entire cost of the tank to build up. When that happens, the flux factory finishes, and it's rolls out the tank.

Oh yes, I can make biased examples too.


On another note: Supreme Commander one is famous for it's flux economy, Supreme Commander 2 is famous for ditching the flux economy. One problem (and it's a mindblowingly HUGE catastrophic problem) is infinite/repeat queues.

Supreme Commander 2 lacks a single, unified, queue for where resources are spent: if you can't afford it now, you can't build it. Now, a simple thought; an infinite queue of tanks should cost... an infinite amount. Well, it's impossible to have an infinite amount of resources in the bank, so an infinite queue of tanks requires a bit of a hack, or will be impossible.

The developers chose to create a bit of a hack. If you tell factories to forever build, say, "two tanks, then an engineer", the cost of that will be deducted from storage, and again each time that lot of units is produced. The problem is that if you can't afford those three things again when the factory next wants to build them, the factory will pause.

Not so bad? Well, it pauses... forever, until you manually unpause it. A lack of a unified queue means that individual consumers compete against each other for resources, and have no way of organising resource distribution... an economic race condition in programming terms.

Now, Warzone.

Warzone would suffer from this worse than Supreme Commander 2 would. Why? Because Warzone's research costs resources too. Say you do put in a giant queue, where everything will eventually get it's resources. What happens if I really really really want to rush a quick something to counter impending disaster? Well, you could remove things from the queue, but that would require more UI changes. The you'll have to consider will that UI be intuitive enough, and will that be adding too much micromanagement?


[TL, DR:] rate-based economy rocks, deposit based economy sucks.

[BulletMagnet]

I would have editted my above post, but it seems that sometime between now and my last post my ABP+ plugin has gone and eaten the forum's edit button, and I can't seem to find the option to turn off extensions in the recent update to Chrome. FFFF-

I've only played SupCom, so I can't speak for the others, but my problem with it was precisely that it isn't simple. I was nearly always at max resources since I was afraid to use more resources than what flowed in, which meant I wasted a lot. A power flow system discourages skilled gameplay in that regard. And the few times I ran out of power, I had to run around disabling buildings so that the things I needed to run at full power could run. That's precisely the kind of micromanagement I don't want in Warzone.

Well here's the problem; you're just a sucky SupCom player. I'm not meaning to offend, but that's what it really looks like. SupCom's economy is only slightly more complicated than Warzone's. Energy SupCom is largely superfluous as mass was the be-all-and-end-all. It was, has been, and always will be perfectly fine to run with a mass stall. Since Warzone uses no oil for upkeep, you won't lose use of shields or radar or turrets... having those turn off in SupCom was the only reason why you'd never want to run out of energy. SupCom penalised you a lot more for stalling the economy than a flux economy Warzone ever could.

A gamer only has so much attention. For every minute of game time, a gamer can only play for a minute. Adding additional complexity to a game means the gamer will have to do more, in the same amount of time, which leads to twitchy "whoever can click the fastest wins" type gameplay, which we try to avoid.

Honestly, maybe the power flow system does work for TA/Spring/SupCom. But that's because their other gameplay elements are simpler, so they have more time to spend micromanaging their power. Our players spend that time doing things like designing, and planning/managing research, and reacting to attacks, and setting up artillery installations, and the like. Our game has already been designed so gamers have a minute of stuff to do every minute - adding more than a minute of stuff that needs to be done in a minute will just make the game more overwhelming and less fun.

SupCom is no simpler or complex than Warzone. I follow very much the same process in both games; set up a factory to build forever. What resource overhead I do have, I throw around building and researching until I can't spend fast enough (basically, my limit to micro and attention) then I set another factory to queue. I'm perfectly happy stalling research, construction, and production because I know I never set any short term projects won't sort themselves out in a few seconds.

[ASIDE:] I think it would be prudent for me to point out that I play solely on low-oil maps. I do have to budget things.

I find it interesting that more than one RTS has switched from pay-as-you-build to direct debit. I think that might have something to do with the advantages of direct debit.

So I've been thinking about this for a while, and all the discussions concerning Supreme Commander 2's economy came back to light.

1. Every RTS game uses the flux economy.
2. Every RTS game uses the flux economy, including Starcraft. Oh yes.
3. The only difference between them all is resource granularity.

The more granular the economy, the more lumpy it is. And of course we can have different granularities between income and outlay. It's already been established that in steady-state results (ala. the net-result over a very large period of time) are the same between flux and deposit. What is differing here is; what happens in the short-term.

Both the long- and short-term matter.

The irony of the situation is that there is no ideal solution. The flux economy will tells you the long-term affordability, but fails to tell you the instantaneous affordability. The deposit economy is the reciprocal: it tells you the instantaneous affordability, but can't tell you the forecast.

Complex UIs and behind the scenes managers can solve the problems in both, but that is still undesirable as they're what they are... complex UIs and behind the scenes managers.


Now, for some rebuttal;

Oh, how I wish I got get some pro game designer to back me up here.

Chris Taylor; he's a pro game designer. Ask him how things like this turn out.

Also, you might want to fact-check CNC3 economy.

[Direct debit power queue] prevents power being spread out between jobs when low on power.

This is a true objection. Power is not evenly spread out, which is bad in situations where you want power to be evenly spread out.

However, I feel the need to once again reiterate: Most of the time, when you think you want power to be evenly spread out, you really don't.

No, I do. I want power spread out as I see fit. When I want it concentrated; I want it concentrated. When I want it spread; I want it spread.

I only ever concentrate when playing reactively. I try to never play reactively, as it means I'm not setting the stage, and if I'm not setting the stage; I'm on the backfoot.

That's because all of the time, when you evenly spread out power, it makes things that would be fast in power queue go slower more than it makes things that would be slow in power queue go faster [...]

I'd like to see some evidence of that.

This is Supreme Commander, an implementation of power flow:
http://img263.imageshack.us/img263/4969/supcom3yq4.jpg

You'll notice it displays resources using ten different numbers (plus another two for each building, but that's hard to see from that zoomlevel).

This, is a red herring.

Your argument is Bad and Wrong. Supreme Commander limits how much you can have in storage, that is the cause for the extra numbers there. And it's actually six numbers, not ten. Please don't double-count something being shown to you twice as two separate things. Make the same argument when you want your power queue to have finite oil storage.

"If you click on something that costs X, your power will go down by X."
"If you click on something that costs X and you don't have X power, the game will wait until you have X power, then start doing it."
"If you click on several things you don't have power for, the game will do them in the order you clicked on them."

Two which I respond;

• If you click on something that costs X power per second, and you don't have X power per second available, the something will work at power per second you have.
• If you click on several things you don't have power for, you should re-evaluate if that was a wise decision.
• If you want to build an expensive something like, say, the las-sat with a single truck and not worry about losing production elsewhere, you don't have to worry as a flux economy works great for that.

[Per]

Interesting posts. Since people apparently love numbers, we could replace some of the costs in absolute numbers with amounts per second in number of seconds, which the player could compare with a similar number for income. So if a tank costs 5 oil/sec for 20 seconds, and you have an income surplus of 6 oil/sec, producing it will be no problem. Instead of displaying a cost of "100", a tank might cost "5/20", or some other notation that might make sense. Note that this will show you not only price info, but also time info, so while it is more complex notation-wise, it gives you more information to work with.

[Crymson]

Interesting posts. Since people apparently love numbers, we could replace some of the costs in absolute numbers with amounts per second in number of seconds, which the player could compare with a similar number for income. So if a tank costs 5 oil/sec for 20 seconds, and you have an income surplus of 6 oil/sec, producing it will be no problem. Instead of displaying a cost of "100", a tank might cost "5/20", or some other notation that might make sense. Note that this will show you not only price info, but also time info, so while it is more complex notation-wise, it gives you more information to work with.

Do you mean like how Supreme Commander does it, when you queue up building things, it shows when the job will be finished?

Having a notation of "5/20" would be too confusing, and overly complex for everyone but diehards.
Having a finished time would be slightly better, at least then, you can plan when to attack, but the time info should be seen like how Supreme Commander does it for building queues.

[Zarel]

I saw this thread and got all excited, so I've skipped the last two pages once I saw Zarel say the code is complex.

It. Is. Not.

I've already written (albeit in Lua) 75% of an n-resource type rate resource economy, and a bunch of code to set up arbitrary extra networks (ala. having a player divide his economy into two independent ones). I have the algorithm/maths written down too.

The fact that you've done it doesn't mean it's easy.

And the fact that you've done it doesn't mean you've done it deterministically, which can compromise sync.

Anyway, the issue with a flux economy is that you really don't give a flying toot about how much you have in storage. It's all about rate-in and rate-out - so much so that it's better to forget about the total cost of an object (ala. 1000 oil) and think of it in terms of rate and time (10 oil/s for 100 seconds). The UI most definitely should reflect this. Hell, I'd love it if the current WZ gave me those numbers as average/effective values.

See, literally not caring about how much you have in storage means one of two things:

1. You're wasting power.
2. You're stalling.

And that brings me the another point I've already brought up: UI complexity. "1000" is a bit simpler than "10/s for 100s"

Also, I saw an incredibly flawed argument on one of the earlier pages about producing tanks and not having any until four minutes or some-such. If you have five factories all constructing tanks when you don't have enough resources- sorry, from now on I'm going to defer to the SupCom wording for that situation: stalling - that is you have five factories stalling; you are naturally not going to see any tanks until four minutes later.

That's why power queue is the best solution. You don't stall, you simply queue.

The exact same goes for a deposit-withdrawal system... so long as we assume that all five factories wait for four minutes so they start production at the same time. Having one factory start before the others is unfair.

...unfair? Are the other factories going to have their feelings hurt?

Because, with the flux economy, what is to stop me from pausing four factories and having one factory build all five tanks? It would then output a tank every minute... equal to that of the deposit economy mode.

Yes, that's what I call micromanagement. In a situation where your build speed does not evenly divide your flow, you'd have to be frequently pausing and unpausing factories and research facilities.

Now, the purpose of a computer is to do math more quickly than humans (the calculations required to know exactly when to pause and unpause your factories) as well as boring repetitive things (like pausing and unpausing factories on a regular basis). So why can't you just let the computer do that (i.e. power queue) so you can spend your time actually playing the game?

A more fair comparison is one flux factory and one deposit factory, zero resources stored, both receiving +1 resource/second. The flux factory starts instantly - because it can - and goes as fast as resources allow.

The deposit factory waits for the entire cost of the tank to build up. When that happens, the flux factory finishes, and it's rolls out the tank.

That's no fair comparison (that's a space station!). Power flow, by nature, postpones when power is spent, so for a fair comparison, you'd have to start it off with less power.

Having a power system give you something faster isn't a good thing (it just means more work for the balancer, i.e. me, to slow the build speed back down to the one I balanced it to be). The only things that can be an advantage of a power system are things like 1. how little micromanagement you have to do to get as close as possible to stalling without stalling (protip: effectively impossible for power flow unless you can integrate several partial functions in the fractions of seconds required for decision making, and will happen no matter what in power queue because stalling doesn't exist), and 2. how simple it is (you cannot argue that "10/s for 10s" is simpler than "100")

Oh yes, I can make biased examples too.

Well, then, you probably shouldn't've called them "fair comparison" as you do two paragraphs ago.

My example serves to demonstrate that power queues work without micromanagement in conditions where power flow systems would have stalled.

Your example serves to demonstrate that I'll have a lot to rebalance if we switch power systems.

On another note: Supreme Commander one is famous for it's flux economy, Supreme Commander 2 is famous for ditching the flux economy. One problem (and it's a mindblowingly HUGE catastrophic problem) is infinite/repeat queues.

Simple solution, really. Only put things on the front of the build queue into the power queue.

Honestly, I know, this solution has its flaws. Per doesn't like me adding yet another queue to Warzone, but it's either that or stalling the economy, and I'd rather have another queue than a stalled economy.

Supreme Commander 2 lacks a single, unified, queue for where resources are spent: if you can't afford it now, you can't build it. Now, a simple thought; an infinite queue of tanks should cost... an infinite amount. Well, it's impossible to have an infinite amount of resources in the bank, so an infinite queue of tanks requires a bit of a hack, or will be impossible.

The developers chose to create a bit of a hack. If you tell factories to forever build, say, "two tanks, then an engineer", the cost of that will be deducted from storage, and again each time that lot of units is produced. The problem is that if you can't afford those three things again when the factory next wants to build them, the factory will pause.

Not so bad? Well, it pauses... forever, until you manually unpause it. A lack of a unified queue means that individual consumers compete against each other for resources, and have no way of organising resource distribution... an economic race condition in programming terms.

Really? It doesn't start on the first when there's enough power for the first? Man, that's a bug, not a flaw with the theoretical system.

I admit my system lacks a unified queue as well, but, as above, I believe power flow has worse flaws.

Now, Warzone.

Warzone would suffer from this worse than Supreme Commander 2 would. Why? Because Warzone's research costs resources too. Say you do put in a giant queue, where everything will eventually get it's resources. What happens if I really really really want to rush a quick something to counter impending disaster? Well, you could remove things from the queue, but that would require more UI changes. The you'll have to consider will that UI be intuitive enough, and will that be adding too much micromanagement?

If you want to rush a quick something to counter impending disaster in power queue, double-click it. I agree, UI complexity, but you advocate power flow, you shouldn't be talking to me about UI complexity.

If you want to rush a quick something to counter impending disaster in power flow, well, have fun micromanaging which orders to pause.

[TL, DR:] rate-based economy rocks, deposit based economy sucks.

[TL,DR:] You have failed to establish that, due partly to the fact that you didn't read earlier parts of the thread in which I answered most of your concerns.

Nonetheless, you did bring up points that haven't been brought up before, and thus I thank you for opening my eyes to some other advantages of power flow that I never thought about.

But I still think direct debit power queues are better.

Have fun arguing with Per over how complex you want to make the interface, btw. He had enough objections to me adding prices to things.

Well here's the problem; you're just a sucky SupCom player. I'm not meaning to offend, but that's what it really looks like.

See, you made the mistake of not finishing reading the thread in your previous post. Did you really need to go and make the same mistake again?

Someone already told me that (in nicer terms, btw ), and I've already agreed with him.

SupCom's economy is only slightly more complicated than Warzone's. Energy SupCom is largely superfluous as mass was the be-all-and-end-all. It was, has been, and always will be perfectly fine to run with a mass stall. Since Warzone uses no oil for upkeep, you won't lose use of shields or radar or turrets... having those turn off in SupCom was the only reason why you'd never want to run out of energy. SupCom penalised you a lot more for stalling the economy than a flux economy Warzone ever could.

Agreed, but Warzone still penalizes you unnecessarily for a stalled economy (cf. this entire thread).

SupCom is no simpler or complex than Warzone. I follow very much the same process in both games; set up a factory to build forever. What resource overhead I do have, I throw around building and researching until I can't spend fast enough (basically, my limit to micro and attention) then I set another factory to queue. I'm perfectly happy stalling research, construction, and production because I know I never set any short term projects won't sort themselves out in a few seconds.

Well here's the problem; you're just a sucky Warzone player. I'm not meaning to offend, but that's what it really looks like.

If Dylan Hsu were here, he'd be lolling at you for stalling your research. Or your factory production. In Warzone, one of the most important things to keep in mind: SLDA at full speed, or you'll have a late-game disadvantage.

[ASIDE:] I think it would be prudent for me to point out that I play solely on low-oil maps. I do have to budget things.

I can tell by how you stall things. I'm proud of you.

So I've been thinking about this for a while, and all the discussions concerning Supreme Commander 2's economy came back to light.

1. Every RTS game uses the flux economy.
2. Every RTS game uses the flux economy, including Starcraft. Oh yes.
3. The only difference between them all is resource granularity.

The more granular the economy, the more lumpy it is. And of course we can have different granularities between income and outlay. It's already been established that in steady-state results (ala. the net-result over a very large period of time) are the same between flux and deposit. What is differing here is; what happens in the short-term.

Both the long- and short-term matter.

Well, I mean... granularity is a pretty big difference.

Say you have $10, and you want two pizzas that cost $10 each. Are you going to think...

a. "I only have $5 for each pizza, so I can't get anything yet."
b. "I'll get one pizza now, and wait until I have enough money for the second pizza."

No one in their right mind would choose a (assuming pizzas never got cold, etc).

The irony of the situation is that there is no ideal solution. The flux economy will tells you the long-term affordability, but fails to tell you the instantaneous affordability. The deposit economy is the reciprocal: it tells you the instantaneous affordability, but can't tell you the forecast.

I don't think that's right. The flux economy can't tell you the long-term affordability, since it's all in terms of flows. You have to do calculus to convert the flows into long-term affordability, and basically what you'd be calculating is "How much money you'd have if this were a direct debit economy", since that number will increase at a constant rate and you can use it to easily predict what that number would be at any time. And it still doesn't help that much, since it varies how negative that number can go before your economy starts stalling.

It does quite well to tell you instantaneous affordability, though. If you have more than 0 of a resource, you can afford it.

Direct debit, on the other hand, tells you both instantaneous (which number is greater) and long-term (your number goes up at the same rate no matter what).

Complex UIs and behind the scenes managers can solve the problems in both, but that is still undesirable as they're what they are... complex UIs and behind the scenes managers.

Well, honestly, "double-click to move to front of queue" and "click on power bar to list power queue" may fall into the category of complex UIs for direct debit...

But that's not nearly as complex as "10/s for 100s, 1000 total" instead of "1000", +/- power displays for each structure that uses or produces power in addition to unified +/- power displays, and a literal line graph of your power over time and how each additional production will change it. And it still doesn't solve the micromanagement problem of power flow.

Chris Taylor; he's a pro game designer. Ask him how things like this turn out.

You ask him. I'd say there's a fair chance he'd agree with me. Power flow is more suited to SupCom than Warzone.

Also, you might want to fact-check CNC3 economy.

Sorry, it's been a while since I played it. I'll take your word that it's not direct debit.

No, I do. I want power spread out as I see fit. When I want it concentrated; I want it concentrated. When I want it spread; I want it spread.

You never want it spread. Again, back to my pizza analogy. You're going to have both pizzas once you have $20, no matter what. The only difference is whether or not you get one of them earlier.

I only ever concentrate when playing reactively. I try
to never play reactively, as it means I'm not setting the stage, and if I'm not setting the stage; I'm on the backfoot.

There are legitimate reasons to concentrate power. It is extremely unlikely that everything you do is of the exact same priority.

When your base is being attacked by VTOLs, do you want your power spread, or do you want to concentrate it on AA?

When your base is being attacked by VTOLs, do you want to spend your time micromanaging power distribution by pausing things, or do you want to spend your time building AA?

Sure, if you're skilled, most of the time, you won't be playing reactively. But if you never play reactively, then you're playing opponents far below your skill level.

I'd like to see some evidence of that.

Is my pizza analogy enough?

In power flow, it's possible to construct situations in which spreading power is superior to concentrating power. In direct debit, there isn't, which makes deciding whether or not to concentrate power incredibly easy: You always want to concentrate power. Personally, I think this is an advantage of direct debit, but I understand if you don't agree.

This, is a red herring.

It's huge. @_@

Your argument is Bad and Wrong. Supreme Commander limits how much you can have in storage, that is the cause for the extra numbers there. And it's actually six numbers, not ten. Please don't double-count something being shown to you twice as two separate things. Make the same argument when you want your power queue to have finite oil storage.

No, it's ten numbers. Two each of +flow, -flow, percentage, current power, max power. You're right, though, that's a problem specific to SupCom. Taking out the numbers relating to the power maximum, and the numbers relating to having 2 resources, you still have:

+flow, -flow, current power. In addition to +/-flow for each individual building. Still more complex than the single-number direct debit. Still doesn't solve the problem that you can't predict whether or not adding something will bring you under.

If you click on something that costs X power per second, and you don't have X power per second available, the something will work at power per second you have.

That only works if you only do exactly one thing at a time.

If you click on several things you don't have power for, you should re-evaluate if that was a wise decision.

By clicking on several things I don't have power for, I am planning ahead.

In direct debit power queue, planning ahead is encouraged, and the game automatically does things once you have enough power for them.

In power flow, you can't plan ahead, because that will stall your economy.

If you want to build an expensive something like, say, the las-sat with a single truck and not worry about losing production elsewhere, you don't have to worry as a flux economy works great for that.

Yes, that's an advantage of spreading power - you can be lazy about it and you'll be able to get cheap stuff slightly faster than in power queue with no micromanagement. But it comes at the cost of stalling your economy and slowing down everything, which I really don't think is worth it. In power queue, you can double-click on the stuff you want to get done faster than the lassat, and they'll go full speed.

Interesting posts. Since people apparently love numbers, we could replace some of the costs in absolute numbers with amounts per second in number of seconds, which the player could compare with a similar number for income. So if a tank costs 5 oil/sec for 20 seconds, and you have an income surplus of 6 oil/sec, producing it will be no problem. Instead of displaying a cost of "100", a tank might cost "5/20", or some other notation that might make sense. Note that this will show you not only price info, but also time info, so while it is more complex notation-wise, it gives you more information to work with.

That notation is unclear. "5/sec for 20sec" is probably the best you'll be able to do without confusing players.

[Safety0ff]

Let me start by saying, that I've tried the patch, and I have to say that I'd be surprised to see it going in the game. Also, I was surprised that Zarel responded in that manner to such a simple post.

To be fair, most of these games don't use direct debit power queue, either - they usually just don't let you start something unless you have enough power to finish it.

Like BulletMagnet said, RA3 and C&C3 work just like trunk. Since those games don't use a queue, that argument is severely flawed.

[Direct debit power queue] prevents power being spread out between jobs when low on power.

This is a true objection. Power is not evenly spread out, which is bad in situations where you want power to be evenly spread out.

I put this as both a pro and a con, BulletMagnet's reply re-enforces this in my opinion.

This is Supreme Commander, an implementation of power flow:
http://img263.imageshack.us/img263/4969/supcom3yq4.jpg

You'll notice it displays resources using ten different numbers (plus another two for each building, but that's hard to see from that zoomlevel).

Warzone + power queue displays resources using one number. Two, at most, if you want to display queued power, which isn't even necessary if you're aiming for simplicity.

The power queue will need a GUI to visualize and manage it, it cannot simply be a grand mystical thing that goes on behind the scenes, that is too confusing especially if the user doesn't know it is there. When I was playing, had I not known there was a queue behind the scenes, I would have been very confused with the power system.

The current power UI in trunk has flaws as it could show more information, but what it does show is not insufficient, unlike your plans for the power allocation queue's UI. I have seen the UI in-game, and I don't have any reason to believe that you will be adding to it.
My justification for that last statement is that every time I inquire about plans for the UI, it it falls on deaf ears. And so, showing screenshots of typical power flow systems (especially in the context of this thread, where most people don't know what the power allocation queue will end up looking like) is pointless until we have the whole picture of the final power allocation queue to compare against.

Those are very discoverable rules, and all of them are common sense (but to be fair, so is power flow). You don't even have to use the word "allocate" to explain how it works.

Without knowing the game uses a queue and without a UI this isn't very discoverable.
==============
Now for what I consider the primary flaw of the power allocation queue.

Using a power allocation queue suggests that the primary opportunity cost to doing a power action is only/mostly the power spent.

In warzone, this doesn't pan out since time is a scarce commodity.
In warzone, the time a power action takes to complete depends on, built points production rate of the producer.
Also, when comparing power actions to each other, the power cost per built point can vary as well.

These characteristics will make a power allocation queue under-perform in the majority circumstances.
Consider these scenarios:
* Power has/is been/being allocated to "slow" producers while "fast" producers wait idle.
* The player has low power, a slow producer is at the front of the queue and the user is generating a surplus with respect to the rate of production of the producer at the front of the queue.

In both these cases the power the user has would be better spent keeping the other producers "busy". Any power that isn't being used while there are idle factories and power actions that aren't in progress is wasting opportunity.

The worst part about the power queue is that it makes this difficult to work around (this is much worse without a GUI.)

A solution that would work much better is a power flow queue a.k.a. priority queue on top of the trunk system.
Though they would both require a UI, I'm sure a power flow queue would outperform a power allocation queue and be less hassle to the player.

I think a power allocation queue would more hassle for most players.
I think a power flow queue would benefit less-skilled players more than more-skilled players.
==============
Regardless of which system is "better,"
I'm not sure we need to switch to a system that incorporates strategies of competitive players. As long as we have a consistent & straight forward power system, recreational players will play to their enjoyment and competitive players will find strategies to give themselves an edge. I think switching to a system that does could potentially disfavour Warzone from both these types of players.

[Safety0ff]

I'm putting this additional description of power flow queue here instead of editing the other post:

What I describe as a power flow queue is a queue where the first power action in the queue only takes as many power units as the producer can use that tick, then the second does the same, and so on.

[Zarel]

Let me start by saying, that I've tried the patch, and I have to say that I'd be surprised to see it going in the game. Also, I was surprised that Zarel responded in that manner to such a simple post.

I thought some of your statements were incorrect, so I corrected them. I feel strongly about the power system, so forgive me if I did so more directly than necessary.

Like BulletMagnet said, RA3 and C&C3 work just like trunk. Since those games don't use a queue, that argument is severely flawed.

Hmm. And I thought I've played RA3 enough to know how it works. I think it animates the decrease, but doesn't let you do things if it costs more power than you have.

I don't have RA3 with me, so okay, I'll give that point to you.

I put [spreading out power] as both a pro and a con, BulletMagnet's reply re-enforces this in my opinion.

I guess there are advantages to spreading out power (though I still think they are outweighed by its disadvantages). I guess I can agree with that characterization, though.

The power queue will need a GUI to visualize and manage it, it cannot simply be a grand mystical thing that goes on behind the scenes, that is too confusing especially if the user doesn't know it is there. When I was playing, had I not known there was a queue behind the scenes, I would have been very confused with the power system.

You would've been confused to see things being allocated power in the order you clicked on them? I guess if you really didn't pay attention to that, the order could seem kind of random, but if you were that much of a beginner, you'd probably try to avoid falling that far in debt in the first place.

The current power UI in trunk has flaws as it could show more information, but what it does show is not insufficient, unlike your plans for the power allocation queue's UI. I have seen the UI in-game, and I don't have any reason to believe that you will be adding to it.
My justification for that last statement is that every time I inquire about plans for the UI, it it falls on deaf ears. And so, showing screenshots of typical power flow systems (especially in the context of this thread, where most people don't know what the power allocation queue will end up looking like) is pointless until we have the whole picture of the final power allocation queue to compare against.

This is a valid objection - I haven't really explained my plans for the UI, partially because I haven't completely decided.

The UI as it exists now in the patch ticket, however, I believe is already superior to trunk and 2.3 (and I believe will continue to be superior to trunk with lots of UI grafted onto the latter), so for the moment I will stand by it.

I think there are still some stability problems with the patch, but those are tangential and will be fixed before I commit it.

Without knowing the game uses a queue and without a UI this isn't very discoverable.

You click on an item while you have no power. You notice it becomes selected, but doesn't start yet. It's a very direct assumption that that means it has been put on a to-do list for when you do have enough power, and really the only logical conclusion.

Now for what I consider the primary flaw of the power allocation queue.

Using a power allocation queue suggests that the primary opportunity cost to doing a power action is only/mostly the power spent.

In warzone, this doesn't pan out since time is a scarce commodity.
In warzone, the time a power action takes to complete depends on, built points production rate of the producer.
Also, when comparing power actions to each other, the power cost per built point can vary as well.

These characteristics will make a power allocation queue under-perform in the majority circumstances.

These characteristics will make a power flow system under-perform in the majority of circumstances:

Time is a scarce commodity, so users should be able to queue up things to do (so they don't need to be interrupted while in the middle of commanding an army) without stalling the economy.

Time is a scarce commodity, so users should be able to manage it efficiently. Having a power flow system where it sometimes makes sense to spread power/time and sometimes makes sense to concentrate power/time complicates the system. Having a direct debit system where concentrating power/time is always the right decision makes dealing with the commodity of time a lot simpler and easier.

When comparing power actions to each other, power cost per time can vary, so a system in which you have a bunch of structures draining power at different rates, arbitrarily starting and stopping, complicates matters immensely.

When comparing power actions to each other, power cost per time can vary, so a system in which you get the bill up-front means it doesn't matter how fast they go; you know how much power you'll have regardless.

Consider these scenarios:
* Power has/is been/being allocated to "slow" producers while "fast" producers wait idle.

This is, as I've mentioned many times, a valid criticism of power queue - you need to micromanage a bit (just double-clicking) if you want fast producers to start before slow producers can start.

My personal solution would be just to play the game like StarCraft - collect a bit of a positive balance before producing something expensive. I admit that this does eliminate some of the advantages of the queue, but I still find it preferable to stalling an economy, since as long as your positive balance doesn't exceed the cost of the expensive item, your economy is still going at max speed.

* The player has low power, a slow producer is at the front of the queue and the user is generating a surplus with respect to the rate of production of the producer at the front of the queue.

That said, the surplus is identical in either system. The only difference is that it occurs before the slow producer starts working rather than during.

In both these cases the power the user has would be better spent keeping the other producers "busy". Any power that isn't being used while there are idle factories and power actions that aren't in progress is wasting opportunity.

Expensive things should have costs. I consider this to be a balance problem more than a powersystem problem, and since 2.3 is already (kinda) balanced, changing the balance by switching to power flow is not necessarily desirable.

A solution that would work much better is a power flow queue a.k.a. priority queue on top of the trunk system.
Though they would both require a UI, I'm sure a power flow queue would outperform a power allocation queue and be less hassle to the player.

Define "outperform".

I guess a priority queue for power flow would improve it, but it further complicates an already overcomplicated system. I'm beginning to see that both systems have their merits, but so far it still seems like direct debit power queue is the best, with 2.3's direct debit spread-allocation as second-best.

I think a power allocation queue would more hassle for most players.
I think a power flow queue would benefit less-skilled players more than more-skilled players.

I think that a direct debit queue will benefit both unskilled and skilled players more than a power flow queue.

Without reasoning, I can't really contest your statement on its merits. :/

Regardless of which system is "better,"
I'm not sure we need to switch to a system that incorporates strategies of competitive players. As long as we have a consistent & straight forward power system, recreational players will play to their enjoyment and competitive players will find strategies to give themselves an edge. I think switching to a system that does could potentially disfavour Warzone from both these types of players.

Another advantage of direct debit power queue is that as long as you have no more than 1 thing collecting power, it works identically to 2.3. And a casual player is unlikely to go that far into debt, so the system will remain familiar to the casual player.

Honestly, I'd be mostly fine with sticking with 2.3, but reverting all of gerard's power code is a lot harder than just applying my patch.

[Zarel]

At this point, it appears we have rejected the dearth of interface in the powersystem of trunk, and that if we're going to use power flow, we should at least add more numbers and visualizations.

Our current competing systems are:

- Direct debit, spread allocation (2.3)
- Direct debit, queued allocation (Zarel's proposal)
- Power flow, spread allocation (BulletMagnet's proposal)
- Power flow, queued allocation (Safety0ff's proposal)

I'm not as sure my proposal is the best out of these than I am that it was the best out of the original three, so I'm going to take a while to analyze the merits of these proposals in depth before continuing.

As I do so, I thank BulletMagnet and Safety0ff for opening my eyes to some of the advantages of power flow. The rest of you have just been repeating advantages and disadvantages I've already thought about. (Though, for those of you on my side, that's understandable. )

[Safety0ff]

Hmm. And I thought I've played RA3 enough to know how it works. I think it animates the decrease, but doesn't let you do things if it costs more power than you have.

I don't have RA3 with me, so okay, I'll give that point to you.

I don't have it nor have I played it, but I did watch videos on youtube and I have played nearly every C&C/RA before the 3 series and it looked like it worked the same way (click an item, and power decreases as you build it with a clockwise animation.) Though which system those two games uses doesn't really matter.

EDITED
I also looked at some Sup.Com. 2 videos, and it was NOT like RA, it was direct debit (in my words: you pay the whole price upfront/before building.)

[Zarel]

I also looked at some Sup.Com. videos, and it was like RA, it was direct debit (in my words: you pay the whole price upfront/before building.)

Are you sure those weren't SupCom2 videos?

And by "RA", do you mean RA1 or RA3? I seem to recall you saying both were power flow systems.

[Safety0ff]

Are you sure those weren't SupCom2 videos?

Yes they were, I was typing quickly.

And by "RA", do you mean RA1 or RA3? I seem to recall you saying both were power flow systems.

Whoops, there was supposed to be a "NOT" in there, and it would have RA1 or RA less than 3.

[andron]

hello, im not going to read all the thread i did read in the bugtracker should be enough...

Zarel i did agree with you, it is really annoying to have production slowed down because of too few power.
Also i think it should be shown how far you are in the negative.
But there is one thing: When you start 3 Productions at one time in different factories. They all take 2 minutes.
You have too few power for all three when beginning but you would have enough power after 2 minutes.
So as far i did understand the Power flow system would now begin all three Productions at the same time and produce as long energy is there and in this way would simply finish it within 2 minutes.
On the same time the debit system would just begin the first production and finish it in two minutes, it would begin the second when enough energy is there lets say maybe after a minute and would end it after 3 minutes and the last one might begin after 2 minutes and end after 4 minutes because it needs full filled power again and this is after two minutes.

i would suggest that the power is directly deductet from your power when you put something on but flows into the production. So you would allways know how much Power is allready spend.
I would also suggest to make a priorized production so the first in the queue gets flow with the aim to produce on full speed, the second as well and so on. As soon there is no more enough energy flow inside the production is slowed or paused