Warzone's power system

[JDW]

Gerard originally coded the flow method. I later talked him out of it, but since then Per and Safety0ff have taken a liking to it.

I'm sure Per and SafetyOff they have their reasons. As evident from their posts on this thread.

[JDW]

Honestly, at this point I'd say we're too divided; it'd be simplest just to revert to the 2.3 method and leave it there.

What's wrong with the trunk's implementation?

[Zarel]

I'm sure Per and SafetyOff they have their reasons. As evident from their posts on this thread.

I know. It's not like I haven't read them.

What's wrong with the trunk's implementation?

Have you read any of my (or Rman's, or TVR's, or several other people's) posts in this thread?

[JDW]

What's wrong with the trunk's implementation?

Have you read any of my (or Rman's, or TVR's, or several other people's) posts in this thread?

Alright, alright, i'm going through the entire thread all over again, quite a lot of arguments/counter-arguments.

[Lancefighter]

It seems that none of the dev staff is actually for the flow method..

I don't know where you're taking this from. I'm not against flow, other than Zarel, I don't know of who else is "against" it.

perhaps i really do suck at reading comprehension, but it seems that..

per doesnt like it because it would require additional UI to display, and he doesnt want to change the UI at all.
zarel does granted appear to argue against it, but also seems to be able to see the merits of either side
as for the other devs (no offense), but you werent very loud on the matter (the majority of posts here are by zarel..)

Otherwise, it seems the largest issue is 'who gets the power when', which is what all the UI problems stem from - you cant design a complex system in many cases without a complex interface, and you guys want to avoid making the wz UI changed at all.
Perhaps tahts where im getting all of the negative feelings from - It just seems that people are resistant to change. Both ways can, and have been argued back and forth.. so well, not much else to say. Id like to say weve passed from the argument of power systems to the metaargument of why

[Zarel]

per doesnt like it because it would require additional UI to display, and he doesnt want to change the UI at all.

Well, Per is willing to cede additional UI now that he sees he's the only person who wants the trunk power system to stay, no changes.

zarel does granted appear to argue against it, but also seems to be able to see the merits of either side

I see the merits of either side, and having weighed them, I still prefer to stick with direct debit.

Now that I can see why other people would want power flow, but having played trunk (and SupCom and similar games) I will say in no uncertain terms that I hate it and while I'd try not to leave the project I'd probably play a lot less.

[JDW]

What's wrong with the trunk's implementation?

Have you read any of my (or Rman's, or TVR's, or several other people's) posts in this thread?

Ok, I think I have the answer sorted out now, but it appears that nobody's opinion has changed since the beginning of this thread. Just as Crymson mentioned.

Honestly, at this point I'd say we're too divided; it'd be simplest just to revert to the 2.3 method and leave it there.

No. Please no! I hate it when power actions feel like they are going nowhere at times of low power. I end up having to pause/cancel less important power actions so that I don't need to wait for something I really need right away. This is so horribly annoying, and one of the biggest ones (along with some like pathfinding and formations). I honestly don't know if the direct-debit method or the trunk's method or if any other method could be the solution, but I just hate this one aspect about 2.3's implementation the most, and I wish it was fixed (or at least made less annoying) somehow, anyhow.

[TVR]

... I honestly don't know if the direct-debit method or the trunk's method or if any other method could be the solution, but I just hate this one aspect about 2.3's implementation the most ...

Better the devil you know, than the devil you don't.

The Warzone 2100 resource system incorporates both the proportional distribution of power flow, which allows one to construct basic walls during power stalls, but does not require calculus, nor does allocate all the power during a stall into a single point of failure, with this failure being structures or trucks being destroyed during construction, a common occurrence in a volatile environment.

This resource system is possibly the most practical element of Warzone 2100, as it a compromise that, while not guaranteeing fastest time to first unit, offers simplicity, easy visualization, and still results in the same average amount of production.

[JDW]

I do agree that the current implementation's (kind of) point-of-failure prevention measure may be an advantage at times.

But with all due respect TVR, nothing of what you said changed my opinion about low-power stalls being an annoyance, especially when not all power actions are related to construction tasks. Some people may say that I am overspending, that may be so, but I'm quite certain that any average gamer like me would be doing the same and would end up having to pause/cancel power actions quite often. Maybe this level of micromanagement can't be helped, but it would certainly be less frustrating on the gamer if it were to be handled in a more elegant manner, ideally requiring much fewer clicks.

In power queue, instead of spreading out the power equally, it will put it all towards whatever you started first. Basically, the game automatically does exactly what a skilled player would micromanage in 2.3. Which is why those of you who say "don't change the power system" might find this appealing - the power system doesn't change at all, the power queue simply helps you use it more efficiently.

I agree that this is a good feature, the frustration born out of micromanaging these non-battle related tasks would be brought down to a more tolerable level.

That the power bar goes down too fast doesn't necessarily mean you are overspending. You could just be doing a lot of power actions with a high speed-to-price ratio (for instance, you could be building a structure with 15 trucks at once). As long as those power actions aren't expensive, you aren't necessarily overspending. Again, that's the problem with power flow. You never know.

This is exactly what direct debit power queue is. 2.3, plus the ability to assign priority without having to micromanage by hunting down and pausing 10 different things.

I am not saying that a complete revamp of the current power system implementation is the solution, nor am I saying that Zarel's proposal is the best bet to create a more fun experience for the gamer. But he did address the disagreement that I have with the current implementation.

[andron]

well i have the last nightly build.
i think the power flow is good that way basically, but i would suggest to add two thinks:

it shows now how much money you have now, so you should add a second counter how much money you would have when all projeckts are finished. i think it would be very interesting how much money is allready planned for building.

and yes an interface where you can manually change the priority or direcktly the build speed, so that low priority projeckts are only build at 1/8 speed and consume less energy over longer time so you dont have to manually pause and resume them when energy is low.

[milo christiansen]

Wouldn't it be simpler to split two or three power branches to test the various systems?

It would save a lot of arguing.

[R Hannay]

Gentlemen, if I may, I would like to resurrect this discussion with regard to the recent testing builds so that it may continue. It seems that the community did not reach a consensus and that is why I am suggesting that the discussion continue. Currently, the 20101030 testing build uses a strict form of power flow, and I doubt the entire community is in agreement with this system. So the point is of merit. Much obliged.

[JDW]

With direct debit, won't we see more quicker and more chunky deductions from power level and won't that be a bit more confusing? We may see drops in our power levels as 1000-> 900-> 800-> 700... (when two factory is producing a unit that costs 50 power in an infinite loop). But with power flow, you'll see a slow steady decrease in power 1000-> 994->...... something like that? So isn't power flow system more easier to understand as to how we are doing economically?

And I also feel that the debit system requires more micromanagement when we are really low on power, as we will have to make more rapid decisions on what to stop researching/producing/constructing so that we have more power to spend wisely. I say rapid decisions because debit of power will be instantaneous, and we'll need to be quicker on those cancellations.

[Nick Morro]

With direct debit, won't we see more quicker and more chunky deductions from power level and won't that be a bit more confusing? We may see drops in our power levels as 1000-> 900-> 800-> 700... (when two factory is producing a unit that costs 50 power in an infinite loop). But with power flow, you'll see a slow steady decrease in power 1000-> 994->...... something like that? So isn't power flow system more easier to understand as to how we are doing economically?

.
That is true, but it is important to keep in mind that in power flow, the decrease is not steady at all, since you are constantly starting and stopping doing things that require power. In the end, it is about as difficult to predict our economic status in either system.
.

And I also feel that the debit system requires more micromanagement when we are really low on power, as we will have to make more rapid decisions on what to stop researching/producing/constructing so that we have more power to spend wisely. I say rapid decisions because debit of power will be instantaneous, and we'll need to be quicker on those cancellations.

.
A common mistake is to compare playing the debit system optimally with playing the flow system suboptimally.
.
While playing optimally, the power flow system requires far more micromanagement, as you would also have to make rapid decisions on what to stop researching/producing/constructing, and in addition, you would need to rapidly decide what to pause/unpause as your power rises and falls. You would need to keep your power at exactly 0 or 1, or you will have wasted power that could have been used earlier, and your production will be delayed by some small amount of time.
.
While playing the debit system optimally, you can wait for your power to rise from 0 to the price of the thing you want to spend it on (or even earlier, by queueing it), and you can spend it anytime in this range without delaying your production at all, which in practice works out to having a lot more time to make your decisions.
.
Perfectly optimal play is inconsequential unless we are a "pro" player, of course. For amateur players, the equation changes slightly.
.
An amateur is content to keep their power in the vicinity of zero. In a debit system, this is done by spending power before the amount you possess rises too high. You may spend power before you have enough, in which case it will be done exactly when you have enough (perfectly optimal), or you may spend power after you have enough, in which case it will be started immediately (slightly suboptimal). Neither is a large problem. In addition, if you don't want to watch your spending for a while, you can simply queue a lot of actions and then not pay attention for a while.
.
In a flow system, the goals are the same - spend power to keep the amount you possess near zero. As your power hovers around zero, you could make it hover around some value above zero (slightly suboptimal), the smaller the more optimal, but if it gets too small, you might hit zero, at which case everything slows down (severely suboptimal). In addition, you must constantly watch your spending lest your power level veers up to a large value (moderately suboptimal) or down to zero (severely suboptimal).
.
Regards,
Nick
.

[JDW]

... but it is important to keep in mind that in power flow, the decrease is not steady at all, since you are constantly starting and stopping doing things that require power.

Agreed. We can have as many as 15 trucks accruing power for construction, 15 factories (tank/cyborg/VTOL) producing units, and 5 research labs working at the same time (should be possible on medium power maps I believe), and that's certainly a lot of power demanding actions.

I can agree with the notion that neither system works out best to predict how a gamer is doing economically for the next couple of minutes. Anyhow, in your opinion, which of the two systems would appear to work out best for wz2100? Or maybe there is another system altogether that works very well to inform the gamer of how well he is doing on his resources? And I believe we are all on the same page when I say that a gamer could manage his resources better (play the game better) if he knows how he is doing economically and it's just a matter of which system does this well, correct?