Warzone's power system

[Per]

There has been some discussion about the future of Warzone's power system, and I thought it would be a good idea to hear what other people think about this.

First an introduction to what we have now.

In 2.3 and earlier versions, there is a two phase power system. When you build something, you first accrue power for production at some rate (first progress bar), and once power accrue is complete, you start the actual production at some other rate (second progress bar). This is as far as I know, a fairly unique system, in that I know no other game that has it.

In trunk, this system has been revamped, where the power accrue phase and production phase has been merged into a single phase (just one progress bar). This mimics more closely the power flow system used in Total Annihilation and Supreme Commander 1.

More recently, there is a new power system proposed that is based on a direct debit model. It works similar to games such as Starcraft and Supreme Commander 2, where expenses are immediately deducted from the available amount of power. The production progress bar (its phase two) is then the same as in 2.3 and earlier. To allow more production to be queued up than you have power reserves for, it introduces the concept of a power queue, which is a list of things to start spending power on.

Now, there is some argument as to which system is the best. Let those arguments be aired in this thread. You can also post other suggestions for changes to the power system, but please do not go too far off in that direction. And please keep arguments to the point, about them rules, and without any drama.

[KukY]

I like the current trunk one the best. It offers the best balance between liquidity and power sharing.

[JDW]

In 2.3 and earlier versions, there is a two phase power system. When you build something, you first accrue power for production at some rate (first progress bar), and once power accrue is complete, you start the actual production at some other rate (second progress bar). This is as far as I know, a fairly unique system, in that I know no other game that has it.

In trunk, this system has been revamped, where the power accrue phase and production phase has been merged into a single phase (just one progress bar). This mimics more closely the power flow system used in Total Annihilation and Supreme Commander 1.

As I understand it, the difference between 2.3 and trunk is only in how the accrue and production phases are managed. In the trunk version, it seems like the production phase is made to simultaneously occur as power is being accrued, thus effectively eliminating the production phase, am I correct? Or is it that the trunk's progress stage is just a merger of the two phases while exactly the same time is taken to produce something in trunk as is taken in 2.3?

If it's the first case, then I prefer the trunk version. And if it's the second case, then I prefer the 2.3 version's implementation.

More recently, there is a new power system proposed that is based on a direct debit model. It works similar to games such as Starcraft and Supreme Commander 2, where expenses are immediately deducted from the available amount of power. The production progress bar (its phase two) is then the same as in 2.3 and earlier. To allow more production to be queued up than you have power reserves for, it introduces the concept of a power queue, which is a list of things to start spending power on.

Here the power is not accrued by everyone, so you would see units at the top of the production queue being produced more sooner than expected, although in exactly the same time frame as in the present implementation.

However, I assume that the production of low-power and high-power units in the production queue will have the same priority. And it will it up to the player to manage the queue in case he needs something immediately over less important (or high-power) requirements that will take a lot of time in the queue, hence more micro-management for the player. I believe the current trunk and 2.3 methods requires almost no micro-management on the player's part.

Please correct me if I have misunderstood any concept.

Suggestion, why not mash the two methods, have the trunk (or 2.3) version as the default, and when the player requires something urgently, he can pause (withdraw) accrual of power by (from) other non-important productions and divert it towards that one thing he needs desperately. What do you think?

EDIT:
Why not have the trunk (or 2.3) version as the default, and when the player requires something urgently, he can optionally (in addition to pausing productions) also withdraw back power accrued by other non-important productions (currently productions can only be paused or cancelled) and divert it towards that one production he needs desperately. Thus leaving objects in the production queue as it is, without having to remove them from the queue to get back the accrued power.

However, this suggestion seems suitable only for the 2.3 implementation rather than the trunk version. But if somehow power can be withdrawn from the single progress phase of the trunk version (recycling?), then that would be a more convenient implementation from a player's point of view. And much lesser micro-management than the direct-debit method as it will be used only when required, imho.

[KukY]

As I understand it, the difference between 2.3 and trunk is only in how the accrue and production phases are managed. In the trunk version, it seems like the production phase is made to simultaneously occur as power is being accrued, thus effectively eliminating the production phase, am I correct? Or is it that the trunk's progress stage is just a merger of the two phases while exactly the same time is taken to produce something in trunk as is taken in 2.3?

In trunk, power is consumed as fast as the product is produced.

Suggestion, why not mash the two methods, have the trunk (or 2.3) version as the default, and when the player requires something urgent, he can pause (withdraw) accrual of power by (from) other non-important productions and divert it towards that one thing he needs desperately. What do you think?

We already can pause. Then power is automaticaly directed to others.

[JDW]

Suggestion, why not mash the two methods, have the trunk (or 2.3) version as the default, and when the player requires something urgent, he can pause (withdraw) accrual of power by (from) other non-important productions and divert it towards that one thing he needs desperately. What do you think?

We already can pause. Then power is automaticaly directed to others.

You're right. My mistake. Suggestion withdrawn.

[JDW]

We already can pause. Then power is automaticaly directed to others.

But is it withdrawn from other productions or just paused? i can't remember.

EDIT: Just tested it, it's only paused.

[KukY]

But is it withdrawn from other productions or just paused? i can't remember.

You can pause something. Then the power it drained is distributed among the others.
You can also cancel the production, and then the power already used is returned to power pool for further use by others.

[JDW]

Then the power it drained is distributed among the others.

Are you absolutely sure? Because if it is drained, why can I still see the production phase as it is?

You can also cancel the production, and then the power already used is returned to power pool for further use by others.

Yes, that i was aware of but that would mean removing things from the queue completely. I modified my earlier suggestion, by which the production unit would not be removed from the queue.

[TVR]

The flow rate model kind of contradicts Zarel's philosophy of not requiring calculus to play a game...

Whereas the second proposed system is much less flexible, as power queues would have to be remade every time one decides to build a new structure, or even worse, a new factory or research centre.

The current system offers offers a reasonable compromise between the benefits and disadvantages of each system, and requires the least amount of attention for flexibility given.

[Zarel]

I originally didn't want to influence the results, but it seems people are having trouble with Per's descriptions, so here, I will try to describe them in more detail impartially.

First, I will call the systems "direct debit with allocation" (2.3), "direct debit with power queue", and "power flow".

I will refer to the actions of manufacturing, researching, and building as "power actions". These are (currently) the only things that use power.

When you have more power than you need:

- The two direct debit systems work identically. When you do a power action that costs X, your power will immediately go down by X at the start.
(Some direct debit systems have an allocation phase, so the "immediately" above could be a few seconds, but this is easy to change and is purely cosmetic.)

- The power flow system will slowly decrease your power over the course of the power action, to a total of X.

There are several major differences here:

- With the direct debit systems, if you have more power than the cost of the power action, you are guaranteed to have enough power to do the power action at full speed. With the power flow system, that's not enough, since your other power actions might drain enough of your power that you no longer have enough midway through the power action.

- With the direct debit systems, your power rises constantly (and it always rises), so not only do you know how much power you have at any given point, but you also know how much power you'll have any any point in the future. With power flow, how fast your power rises/falls changes each time you start or finish a power action - hence TVR's comment about "requiring calculus".

- With the power flow system, power is drained gradually, so you could have enough power even if you currently have less than the power action's cost. However, as above, this does make it effectively impossible to estimate whether or not you have enough power to do something, since it depends on so many factors.

When you have less power than you need:

First, you might think, "Being at low power should be fairly rare". If you do, it's probably because you play on maps with way too much oil. For a skilled player, their power should always be low - having a lot of power means you've spent a lot less power, and since the strength of your army depends on how much power you've spent on it, that means your opponent has an advantage.

This is best done with a case study. Say you have 60 power, and you manufacture five units that cost 60 power each, and take 60 seconds to manufacture. You gain power at the rate of 1 per second.

- With direct debit and power queue, you get one unit after 1 minute, another 1 minute later, another 1 minute later, etc.

- With direct debit and allocation, the allocation is spread out over the five units, you don't get any units until 5 minutes in.

- With power flow, the power spending is spread out over the five units, you don't get any units until 4 minutes in.

In other words, unless you use power queue, you have to micromanage if you want a unit ASAP - wait until the first unit finishes before starting on the second.

The purpose of a power queue is to automate the micromanagement of power allocation. You can add a power queue to power flow, too, but it kind of cancels out a lot of the advantages of power flow, so you might as well, just use a direct debit power queue if you're going to do that.

Here's another case study. Say you have a bunch of power actions actions queued or in progress, and not enough power to go through it all full speed. You suddenly have an urgent power action you need to get done fast (i.e. at maximum speed).

- With direct debit and power queue, you start the urgent power action, then double-click on the the urgent power action to place it in the front of the queue.

- With direct debit and allocation, you have to hunt through all your in-progress power actions, and cancel all the ones that haven't fully allocated, start the urgent power action (you should have enough power from your canceled power actions for it to allocate completely, so you can start the next step immediately), then start the other power actions back up.

- With power flow, you have to pause/cancel all your in-progress power actions, start the urgent power action, leave the others cancelled and wait for the urgent power action to finish, then re-start all your other actions.

So as you can see, in low power, micromanaging is most difficult in power flow, and easiest in direct debit power queue. However, the consequences of not micromanaging are most severe in direct debit allocation, and least severe in direct debit power queue.

[Per]

Describing 2.3 as in any kind "direct debit" is just plain wrong. There is nothing direct about it. If you start too many production items at once, they will stall while they accrue power, just like in trunk. So their behaviour in out of power situations is identical.

As to whether this makes it "impossible to estimate whether or not you have enough power to do something" and "requiring calculus", the fact is that people who do not know calculus nevertheless play the game and manage to estimate their production and manage their economy just fine.

An effective player you should always be at low power. However, if you are overspending, you have already spent too much power building up too much production capacity, and you are not playing effectively. This goes for any power system. If you are playing your economy badly, then in power flow your production is stalling, in classic direct debit your production buildings are idle, and in power queue your production buildings have items on hold. Just different symptoms of the same problem, and the problem is not the power system, it is a sign that you are doing it wrong.

The power system can, however, be gentle or harsh on people who are doing it wrong. A direct debit system is inherently gentle in that way. The 2.3/trunk system is not. If we decide the power system should be gentle, then the power flow system can also be made gentle by giving absolute priority to items that are closer to the finishing line in out of power situations. That would resolve the complaint that in out of power situations, you get all production items later.

[Zarel]

Describing 2.3 as in any kind "direct debit" is just plain wrong. There is nothing direct about it. If you start too many production items at once, they will stall while they accrue power, just like in trunk. So their behaviour in out of power situations is identical.

If you have enough power for all of those production items (which was the section in which I described them as identical), then yes, they are identical. If you don't, they aren't, and I believe I describe them accurately.

As to whether this makes it "impossible to estimate whether or not you have enough power to do something" and "requiring calculus", the fact is that people who do not know calculus nevertheless play the game and manage to estimate their production and manage their economy just fine.

Case study: You gain power at 1/sec, you currently have power actions running that cost 50, 200, and 150. You currently have 120 power. Do you have enough for a 100 power power action?

Answer, you don't know, because you don't know how long each of those power actions will take, nor how far along you are, nor do you have a graphing calculator and ten minutes.

Who are the "people" you speak of? I am a math major who's gotten an upper percentile score on the Putnam. While playing trunk, I either stay well above what I need to, or I run out of power.

An effective player you should always be at low power. However, if you are overspending, you have already spent too much power building up too much production capacity, and you are not playing effectively.

Which is why it's important to be able to tell if you are overspending, which power flow denies you the ability to do.

This goes for any power system. If you are playing your economy badly, then in power flow your production is stalling, in classic direct debit your production buildings are idle, and in power queue your production buildings have items on hold. Just different symptoms of the same problem, and the problem is not the power system, it is a sign that you are doing it wrong.

It's hardly a problem in power queue. With power queue, you have items on hold, items you want to do immediately when you have enough power, which is what many players would be doing anyway.

Having a 0-negative-flow situation is only undesirable in your power flow system. In a sane system, such as direct debit, you often want to spend power right when you get enough (ask a ranked StarCraft player).

The power system can, however, be gentle or harsh on people who are doing it wrong. A direct debit system is inherently gentle in that way. The 2.3/trunk system is not. If we decide the power system should be gentle, then the power flow system can also be made gentle by giving absolute priority to items that are closer to the finishing line in out of power situations. That would resolve the complaint that in out of power situations, you get all production items later.

See my previous post:

"You can add a power queue to power flow, too, but it kind of cancels out a lot of the advantages of power flow, so you might as well just use a direct debit power queue if you're going to do that."

[PkK]

The current (2.3) system seems OK to me. I see no pressing reason to change it, just because wz2100 is the only one to use it.

This is unlike other aspects where wz2100 is different from other current games, where wz2100 is really worse (map not available when there's no command center).

Philipp

[Per]

No, Zarel, you got the difference between 2.3 and trunk exactly backwards. It is when you are out of power that 2.3 and trunk behave the same way. Try this: In 2.3, go to zero power, start lots of production items, watch power be distributed ("flow") in an (imperfectly) balanced manner between the various items you have started. However, when you have enough power, 2.3 works like direct debit with a slight production start delay.

It does not matter if you have a math degree or not when you play trunk, because the skills needed to balance your power have nothing to do with math, and even less to do with learning costs by rote. It is merely about forward planning and watching your income and expenses as they are visualized on the power bar. This is how you can tell that you are overspending - the power bar goes down too fast. You need is a little bit of buffer to see this, some power reserve rather than running broke all the time -- but this is a good idea in any case, no matter what power system you are using.

My most basic problem with power queue is that it is an extra queue in addition to the existing build queues, and it is not visualized in any coherent manner (and i have not seen any proposal to do so). I think having two queue systems for production is wrong. If you want to plan ahead a long series of production items, you use the build queue.

I like power flow because it allows you to balance production in an elegant manner. Even in situations with zero power reserve, I often prefer that power is distributed balanced rather than focused, as this allows me to produce expensive stuff while simultaneously churning out cheap items like walls and bunkers. The mechanics and GUI for it are simple to use and to understand, even though the underlying code is complex.

I think it would have been much better if we had started by discussing high level design issues, and after that discussion looked at if a new underlying design and code was necessary. If the big problem is that you cannot churn out high priority items fast when you are out of power, then there are many ways you could solve without a total rewrite of the entire power system. For example, double clicking on a production item could make it a high priority item (visualized with a red border or some other way), and then the power system could allocate all power to that one item until it is done. I have still not seen described any problems with the current trunk system that cannot be fixed in some way (if they are indeed problems -- I simply disagree that they are on most counts) without compromising on the basic power flow design.

[JDW]

As to whether this makes it "impossible to estimate whether or not you have enough power to do something" and "requiring calculus", the fact is that people who do not know calculus nevertheless play the game and manage to estimate their production and manage their economy just fine.

An effective player you should always be at low power. However, if you are overspending, you have already spent too much power building up too much production capacity, and you are not playing effectively. This goes for any power system. If you are playing your economy badly, then in power flow your production is stalling, in classic direct debit your production buildings are idle, and in power queue your production buildings have items on hold. Just different symptoms of the same problem, and the problem is not the power system, it is a sign that you are doing it wrong.

Since this game is essentially about micro-management, having the player to learn by himself to be economical in his use of power is maybe a good thing. IMHO, all the methods train the player to do this well, but the power-flow method seems to do this better than the others.

Plus, it's another factor to keep the game a little challenging, because he will have to juggle his well thought out orders between the front lines and his base more efficiently to succeed.