Warzone's power system

[Zarel]

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.

I guess it was unclear since I used the pronoun "they" and didn't specify which two, but I meant that it is when you have plenty of power that direct debit allocation (2.3) and direct debit power queue are identical. You say the same thing here:

"However, when you have enough power, 2.3 works like direct debit with a slight production start delay."

In fact: Even if you're out of power, as long as you only have one thing allocating at a time, direct debit allocation and direct debit power queue are the same.

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.

That "imperfectly" is another reason why I prefer power queue. No need to write a lot of code to better distribute where power goes.

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.

Nothing is visualized on the power bar besides a mostly meaningless number.

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.

I also note that, in the other systems, you don't need any buffer at all to know how much you are overspending.

Needing a "buffer" is, again, a completely spurious requirement and not at all a prerequisite to skilled gameplay. Ask a ranked StarCraft player if he keeps a "buffer", or if he makes workers right when he has 50 minerals.

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 suppose I can see that being a problem. How's about a list that appears when the power bar is clicked?

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.

The mechanics and GUI are simple at the cost of not being able to play the game properly. Don't get me wrong, I'm all for simple GUI, but a power system stops deserving a simple GUI when the result is that it is impossible to know whether or not you have enough power to do any given thing, and impossible to predict how much power you will have in a few minutes since your rate of power gain/loss changes so often.

I recognize that it often feels better to distribute power rather than concentrate it, especially since it helps automatically assign priority by pushing less expensive things out faster. However, this comes at the cost at slowing everything down, which is a severe disadvantage in multiplayer. In skilled play, you usually have a bunch of researches that you need to go at full speed. Even without that, the amount of slowdown is far worse than the advantage you get by spreading everything out.

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.

Okay. Here's two.

Code complexity. You cannot write power flow simply. Direct debit is, by nature, simple. You can tell by the fact that my direct-debit-power-queue patch has already fixed a few bugs that have been present in trunk for years.

The ability to know how much power you'll have in two minutes, before those two minutes are up. You can add as much visualization as you like (which you refuse to do, so it's moot anyway), but people cannot quickly do the calculus of "okay, my power flow is -6 until 30 seconds in, then it rises to +2 until 45 seconds in, then it rises to +5..." when they're in the middle of playing a game.

And the problems you can solve are simply hacks that direct debit power queue solves far more elegantly. I hope you realize this.

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.

It's one thing to make a game challenging. It's another to make it frustrating with no benefit.

Making some things impossible to know is not the good kind of "challenging". For instance, imagine if we removed all the HP bars from your units, so you never knew how close your units were to dying until they died. That would make the game more challenging, yes, but it would not make the game more fun.

Also, I believe 6 people have already told you that this game is not about power micromanagement at all, so I don't need to do so again.

Anyway, micromanaging groups of units (NOT individual units) can be a good thing. Nearly all other micromanagement is bad. More time micromanaging is less time having fun, and less time playing the game, neither of which are desirable. Like Rman said. In the heat of battle, you don't have time to stop and write a letter to your mom, and balance your budget. Power queues mean you can plan what you want to do ahead of time. In any other system, if you try to plan anything that far ahead, it'll be ridiculously inefficient.

I was only pointing out that I also agree with what Per stated, being smart about your power use,

As I have hopefully demonstrated, it is impossible to be smart about your power use when you never know how much power you have.

A question to Zarel:

The advantages of direct-debit, as far as I understood (please correct me if I'm wrong), are

1) The gamer is able to make wiser decisions when creating power actions. By that I mean giving the gamer the intuition to prevent power actions from coming to a screeching grind in times of low power levels.

Yes, this is an advantage of all direct debit systems over power flow.

2) Power accrual queue allows for actions to be assigned a priority, which would means a shorter ETA for the power actions that are higher up in the queue.

Yes, this is an advantage of a power queue. As Per mentions, it is possible to graft such functionality into other power systems, but I believe those are rather crude hacks compared to the elegance of a power queue.

Are there any other advantages that I may have missed out? Or which you haven't mentioned? Any drawbacks of the direct-debit method?

I've spent plenty of time discussing why power flow is inadequate. For now, I wish to expound on comparing direct debit power queue with direct debit allocation.

Now, the two direct debit systems are identical until you are out of power, and have more than one thing waiting for power.

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.

Again, refer to my earlier case study. You have low power and you want to make 5 units. Without a power queue, you won't get any units until 5 minutes later, at which point you get all of them. With a power queue, you still get all your units 5 minutes later, but now you get some of them much earlier. A skilled micromanager could have gotten them earlier, too, but that's time that's better spent commanding your army and deciding what to research.

I had a time where I was an avid gamer in Spring RTS - for those who do not know, its an rts engine based off Total Annihilation. TA was based on a two resource system, energy and metal. Both of these were flow based, in that building a structure would require 100 metal, but it depends on the number of builders how fast that metal is deducted from your stores.
Now, it seems that this might be difficult, but TA also gives you something very simple - it told you how much was being used per second.

Every single unit had a +metal/energy and a -metal/energy number. For most units, these were negligible(and very few cost metal upkeep) However, for construction units, they have a -metal number when they are building something. If a constructor uses 1 metal/s to build the above 100 metal structure, it will take him 100 seconds. This is made simple by that the game tells you how much metal you are gaining, and how much you are losing.

If it could be done that near the oil bar, it told you +oil/s and -oil/s then i see no reason why calculus would be needed: you could easily tell that I am gaining 5 oil/s, and that tank I want to build will cost me an 5 oil/s for 20 seconds to build

Supreme Commander does the same thing.

Such complex visualizations have two flaws:
1. They complicate the interface by a ton.
2. They STILL don't change the fact that you can't predict how fast you'll gain power in a few seconds.

Besides Per, no one has ever done power flow without those visualizations, since then you really have no idea how much power you have, or what's using your power. I hope this is enough of a demonstration of how flawed power flow is.

However, there is one idea I've read in this thread that I would like to see implemented. I believe that this idea would be agreeable to most, if not all, Warzone players. That is being able to prioritize "one thing" so as to allocate all incoming power to only that one thing above all other things.

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.

And yes, in direct debit power queue, you can rearrange priority. Double-clicking on something will move it to the front of the queue, where it will receive power first.

[Per]

Nothing is visualized on the power bar besides a mostly meaningless number.

The power bar is a visualization. The number is mostly for decoration. Notice how there are almost no other numbers to compare it with, anywhere? The Pumpkin guys had a thing for lean interfaces, and showing instead of telling. I like that, and I think we should not clutter it up.

The mechanics and GUI are simple at the cost of not being able to play the game properly. Don't get me wrong, I'm all for simple GUI, but a power system stops deserving a simple GUI when the result is that it is impossible to know whether or not you have enough power to do any given thing, and impossible to predict how much power you will have in a few minutes since your rate of power gain/loss changes so often.
...
The ability to know how much power you'll have in two minutes, before those two minutes are up. You can add as much visualization as you like (which you refuse to do, so it's moot anyway), but people cannot quickly do the calculus of "okay, my power flow is -6 until 30 seconds in, then it rises to +2 until 45 seconds in, then it rises to +5..." when they're in the middle of playing a game.

And that's exactly it. This is not the kind of thing I want people thinking about while they play the game. The power system should be out of the way, not be a numbers game. You complain that you cannot easily do calculus on the current power system, but I like it because it takes the calculus out of the power system.

Code complexity. You cannot write power flow simply. Direct debit is, by nature, simple.

The latest power queue patch adds 801 lines of code and removes 624. I have not looked very closely at the code itself, but by line count alone, that assertion does not hold up.

[JDW]

It's one thing to make a game challenging. It's another to make it frustrating with no benefit.

Making some things impossible to know is not the good kind of "challenging". For instance, imagine if we removed all the HP bars from your units, so you never knew how close your units were to dying until they died. That would make the game more challenging, yes, but it would not make the game more fun.

Point taken.

Also, I believe 6 people have already told you that this game is not about power micromanagement at all, so I don't need to do so again.

So they have.

Anyway, micromanaging groups of units (NOT individual units) can be a good thing. Nearly all other micromanagement is bad. More time micromanaging is less time having fun, and less time playing the game, neither of which are desirable. Like Rman said. In the heat of battle, you don't have time to stop and write a letter to your mom, and balance your budget. Power queues mean you can plan what you want to do ahead of time. In any other system, if you try to plan anything that far ahead, it'll be ridiculously inefficient.

Yes, I see now how Rman was correct. Almost all gamers who have chosen or will choose to play Warzone2100 are really only interested in fighting the enemy by commandeering units. This is no Sim City.

I was only pointing out that I also agree with what Per stated, being smart about your power use,

As I have hopefully demonstrated, it is impossible to be smart about your power use when you never know how much power you have.

You make a very good point there.

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. The only time the gamer would need to micro-manage anything is when they would need a certain urgent power action to be completed sooner than the rest, which, I assume, wouldn't be a very often occurrence. Even if it does happen very often, double-clicking a power action to push it up to the top of the queue should be a very easy task to perform. This would enable the gamer to feel more focussed on the battlefield, which is the segment of the game that the player actually enjoys playing.

Another question about the direct-debit power queue method, based on a scenario,
Suppose I have the direct-debit power queue method running. And I perform simultaneous power actions in five cyborg factories to produce nine units of a certain type in each factory.

So I have ordered 9 cyborg engineers in one factory, then I go the next factory and order 9 cyborg mechanics, and so on for 9 grenadiers, 9 heavy gunners, and 9 machine gunners in the remaining three factories.

Would the power queue fill up with the first 9 engineers, and only after their completion would the 9 mechanics be produced, and so on for the rest? (because those 9 engineers were the first 9 power actions ordered before anything else)

Or would the power queue be re-organised regularly to accommodate power actions from other factories/research facilities that were ordered a little later?

[Zarel]

The power bar is a visualization. The number is mostly for decoration. Notice how there are almost no other numbers to compare it with, anywhere? The Pumpkin guys had a thing for lean interfaces, and showing instead of telling. I like that, and I think we should not clutter it up.

The power bar has a constantly shifting maximum, so it's really not that good for visualization purposes.

Plus, lack of clutter isn't an argument for power flow. We don't need the numbers for direct debit, either. Even just having the bars would make it better. Is any of the bar red? You don't have enough money. Otherwise, you do. If you have enough money, your power bar will go down by the part marked in green. You don't even have those affordances in power flow, hence what I said - "the power bar is essentially meaningless in power flow."

And that's exactly it. This is not the kind of thing I want people thinking about while they play the game. The power system should be out of the way, not be a numbers game. You complain that you cannot easily do calculus on the current power system, but I like it because it takes the calculus out of the power system.

The point of direct debit is that there is no calculus. You compare your power with the price of what you want to do. If your power is higher, you can do it. If it isn't, you can't. That's not even arithmetic. It's comparing two numbers and seeing which one's higher.

There's a lot of good in having lean interfaces, but money is one of those things you simply can't take the numbers out of. You end up with situations in which you never know whether or not you have enough money to do something.

The latest power queue patch adds 801 lines of code and removes 624. I have not looked very closely at the code itself, but by line count alone, that assertion does not hold up.

Most of the code is in the implementation of the queue itself. Practically everywhere else, more lines are being removed than added, so at the very least the code is more readable.

Another question about the direct-debit power queue method, based on a scenario,
Suppose I have the direct-debit power queue method running. And I perform simultaneous power actions in five cyborg factories to produce nine units of a certain type in each factory.

So I have ordered 9 cyborg engineers in one factory, then I go the next factory and order 9 cyborg mechanics, and so on for 9 grenadiers, 9 heavy gunners, and 9 machine gunners in the remaining three factories.

Would the power queue fill up with the first 9 engineers, and only after their completion would the 9 mechanics be produced, and so on for the rest? (because those 9 engineers were the first 9 power actions ordered before anything else)

Or would the power queue be re-organised regularly to accommodate power actions from other factories/research facilities that were ordered a little later?

The way it is currently implemented is that only the currently active item in the factory enters the power queue. That way, you don't have to wait until all your factories are done manufacturing before you can continue research, just because you decided to set up your factory queue before your research queue.

[JDW]

The way it is currently implemented is that only the currently active item in the factory enters the power queue. That way, you don't have to wait until all your factories are done manufacturing before you can continue research, just because you decided to set up your factory queue before your research queue.

Oh ok, I get it now. Thanks for clarifying that.

[Lancefighter]

Supreme Commander does the same thing.

Such complex visualizations have two flaws:
1. They complicate the interface by a ton.
2. They STILL don't change the fact that you can't predict how fast you'll gain power in a few seconds.

Besides Per, no one has ever done power flow without those visualizations, since then you really have no idea how much power you have, or what's using your power. I hope this is enough of a demonstration of how flawed power flow is.

Yeah, supcom was pretty much TA anyway.. >.>
sorry, complex? All i want is to know how fast a unit uses oil per second, and print that to the interface. in Spring, i can see that my factory costs 7 metal/s to run. Thus, because I am gaining 10 metal/s at my current flow, i can set that factory to auto-repeat indefinitely. (hint: this is a major part of most of the games on spring)

From there, its just a matter of ordering around units until i have another 7 metal/s net gain in my metal, at that point i build another factory and start the loop all over again. Because of this, I can largely ignore the total number, because, well, it doesnt matter. if I have +10 or +20 metal, i need to spend it faster, so more factories. Because I only have 120 metal in my reserves doesnt mean anything to the flow, and like it or not, warzone is BASED on flow mechanics (you gain resources in a flow-system.. (examples of nonflow - homeworld, the C&C games ive played)
i see no reason to gain resources in a flow and lose them in a direct debit system.

While I agree spring/TA/supcom is very simple comparatively in game mechanics (a peewee is always a peewee, and no matter what else happens, two peewees shooting each other pretty much always kills them both) i think that the metal flow system, given that it too is a flow based game, is a ton simpler.

[Crymson]

I don't see anyone changing their opinion in this thread.
It is just how many people want to turn warzone into a startcraft and supreme commander hybrid.

About the only thing I have read and liked is showing the actual cost of a item, instead of getting the bar.

[Safety0ff]

This is how I would describe the power systems:
2.3: "fully buffered" you accrue the power, then build. You stop paying before you start building.
trunk: pay as you build (like the original Red Alert). You stop paying when you've finished building.
power queue: allocate all the power needed for jobs (in the order you submit them) until there is not enough power for the next job, then for that job, pay as you build until there is enough power to complete the job.

Trunk power system:
Pros

• Natural to most people that have played RTS games.

Cons

• You have to keep track of what you've "allocated."

Power queue:
Pros

• Keeps track of allocated power.

• Prevents power being spread out between many jobs when low on power.

Cons

• Prevents power being spread out between jobs when low on power.

• Complicates the UI.

• Steeper learning curve for newcomers.

I was going to put my opinion here but then I got tired of thinking about it.

[JDW]

I was going to put my opinion here but then I got tired thinking about it.

If you aren't too tired, I'm curious to know your opinion on the level of hassle-free micromanagement required by each method.

We already know Zarel's opinion.

[iMac]

I'm going to vote for Zarels idea of the power system.

& the quote "If it ain't broke don't fix it" then why are we not still using models T's to drive everywhere... If I have to manage power less & focus on the battles more then I become better at battles...

Commanders are a way to micro manage less... You end up micro managing fewer individual units...

[Zarel]

Yeah, supcom was pretty much TA anyway.. >.>
sorry, complex? All i want is to know how fast a unit uses oil per second, and print that to the interface.

I agree, if you are going to use a power flow system, you should do that. However, Per doesn't want to.

And again, this doesn't solve the classic problem of the power flow system which I have repeated for many posts now.

in Spring, i can see that my factory costs 7 metal/s to run. Thus, because I am gaining 10 metal/s at my current flow, i can set that factory to auto-repeat indefinitely. (hint: this is a major part of most of the games on spring)

That's fine if you want to waste your other 3 metal/s, but like I said, in skilled play, wasting power puts you at a significant disadvantage.

From there, its just a matter of ordering around units until i have another 7 metal/s net gain in my metal, at that point i build another factory and start the loop all over again. Because of this, I can largely ignore the total number, because, well, it doesnt matter. if I have +10 or +20 metal, i need to spend it faster, so more factories. Because I only have 120 metal in my reserves doesnt mean anything to the flow, and like it or not, warzone is BASED on flow mechanics (you gain resources in a flow-system.. (examples of nonflow - homeworld, the C&C games ive played)
i see no reason to gain resources in a flow and lose them in a direct debit system.

It makes perfect sense to gain in a flow and lose in direct debit. It means that the flow of your power never changes (unless you gain/lose a derrick/generator/upgrade), which makes strategic planning a lot more possible.

While I agree spring/TA/supcom is very simple comparatively in game mechanics (a peewee is always a peewee, and no matter what else happens, two peewees shooting each other pretty much always kills them both) i think that the metal flow system, given that it too is a flow based game, is a ton simpler.

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.

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.

pay as you build (like the original Red Alert). You stop paying when you've finished building.

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.

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

[Power flow is] natural to most people that have played RTS games.

Actually, of the last few RTSes I've played, in no particular order:

StarCraft II - direct debit
StarCraft - direct debit
Age of Empires II - direct debit
Red Alert 3 - direct debit
C&C 3 - direct debit
Supreme Commander II - direct debit
Supreme Commander - power flow + complex interfaces Per refuses to add
Warzone 2100 retail - direct debit allocation

So a grand total of zero games so far actually use the power flow system Per advocates, which kind of contradicts "more natural to RTS gamers".

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.

[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.

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 - and a most of the time, it doesn't even make anything that would be slow in power queue go faster. That's why most skilled players, if they have time to micromanage, will micromanage things exactly the way the power queue does automatically.

[Direct debit power queue] complicates the UI.

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.

[Direct debit power queue has a] steeper learning curve for newcomers.

"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."

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.

In addition, the first two are also true of 2.3, and the third rule is actually simpler than 2.3 or power flow "If you click on several things you don't have power for, the game will split up the power by dividing it into equal parts, and allocate each part to each thing, and when something's allocated power reaches its price, it will [start (2.3) or finish (power flow)]."

[cybersphinx]

sorry, complex? All i want is to know how fast a unit uses oil per second, and print that to the interface.

I agree, if you are going to use a power flow system, you should do that.

Why has a power flow interface to be complex? I'd say you need only one indicator more, for the power flow, like a second bar below the current absolute power, that shows incoming - outgoing, and changes accordingly when you hover over something. With that, you can roughly judge how much more power you can use, and ideally keep both indicators at 0.

[Lancefighter]

I agree, if you are going to use a power flow system, you should do that. However, Per doesn't want to.

And again, this doesn't solve the classic problem of the power flow system which I have repeated for many posts now.

suppose not, but as far as I can tell, the 'power flow problem' simply revolves around what gets energy and how fast as far as I can figure, the best I can figure the answer is to just let the thing asking for the most power have proportionately more power.. A build unit has 10 buildpower, it gets 10 'tickets' of power - if it was all that was building, it would get 10/10 of the power, 100% of available power. if a factory (of buildpower 10) and 3 trucks (of buildpower 8 each) were building, the factory would get 10/34 units of power (per power gained), where the three trucks (making AA) get 24/34 units of power (per power etc)

that, as far as I can see it, is a rather simple solution (if im reading the problem right)...

That's fine if you want to waste your other 3 metal/s, but like I said, in skilled play, wasting power puts you at a significant disadvantage.

fortunately for me, the other 3/s can be used by constructors to build turrets, more metal extractors, radars, be saved up for the next factory, be donated to the ally that is getting hammered on the other side of the map (would take too long for the same amount of metal in tanks to arrive, whereas metal xfer is instant, and in spring its entirely possible to do a flow transfer (any metal above a number you set is transfered to allies).) The metal isnt /wasted/, as you see, its just a minor example.

It makes perfect sense to gain in a flow and lose in direct debit. It means that the flow of your power never changes (unless you gain/lose a derrick/generator/upgrade), which makes strategic planning a lot more possible.

While I can agree that the system currently /works/, I disagree in that its the best possible way. For instance, just before I noticed this thread, I was about to to ask about modding in a flow system for my own personal use.

While yes, your flow of power never really changes in a direct debit system (all else equal), the perception does. I found that while playing trunk, I was far easier to tell that my power was going down then when I was using direct debt in 2.3.1a, specifically BECAUSE in direct debit the flow never changes.

Perhaps its a personal quirk of mine, but the rate of change is more important to me than the actual numbers. Perhaps that is because of my calculus background

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.

While I specifically do not mean to diminish you as a supcom player, I simply wish to point out that with practice, your ideal of not spending more than you gain would change. spring/ta/supcom are all pretty much the same, and one important feature of spring was that I could press 'w' to tell a building to 'wait' - that is, to stop using resources. Because of this, during a stall I could refocus my materials to important bits, if it was required. Usually, this is rare (i try not to overspend too much unless it is necessary), but now and again i need to stop a building to rush some AA or something.

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.

Perhaps we differ here - I would say that because rate of change is more important than the actual number, we are actually simplifying things

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.

this, again, is something I agree with - however, taking less time to watch my power to see if i am netting positive or negative is a good thing in this reguard, in my opinion.
as well..
(i clarify the following statement by saying that I have rarely played against 'real people', its on the to-do list however)
while I can agree that I am not the greatest WZ player, but when i play against AIs, I dont particularly spend much time deciding what to research, nor designing, nor setting up artillery(gogo hotkeys!. Srsly). I would agree that the tactics ive used would probably not stand against real people for very long, but when I play in spring i certainly do have a minutes worth of stuff to do each minute (and often far more!) and thats often just with managing units and constructors, yet certainly a good deal of my time is NOT spent managing metal consumption

[Per]

About extra visualization or cost information:

I agree, if you are going to use a power flow system, you should do that. However, Per doesn't want to.

Note that my position is that I see no reason to, as I think it works fine without it, not that I am going to dig in my heels and object to it being added, as long as it does clutter up the interface too much. That is a distinction with a difference, although one that I may not always be very good at making clear.

[Zarel]

suppose not, but as far as I can tell, the 'power flow problem' simply revolves around what gets energy and how fast as far as I can figure, the best I can figure the answer is to just let the thing asking for the most power have proportionately more power.. A build unit has 10 buildpower, it gets 10 'tickets' of power - if it was all that was building, it would get 10/10 of the power, 100% of available power. if a factory (of buildpower 10) and 3 trucks (of buildpower 8 each) were building, the factory would get 10/34 units of power (per power gained), where the three trucks (making AA) get 24/34 units of power (per power etc)

Refer to what I said earlier:

• 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.
  
  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 - and a most of the time, it doesn't even make anything that would be slow in power queue go faster. That's why most skilled players, if they have time to micromanage, will micromanage things exactly the way the power queue does automatically.

fortunately for me, the other 3/s can be used by constructors to build turrets, more metal extractors, radars, be saved up for the next factory, be donated to the ally that is getting hammered on the other side of the map (would take too long for the same amount of metal in tanks to arrive, whereas metal xfer is instant, and in spring its entirely possible to do a flow transfer (any metal above a number you set is transfered to allies).) The metal isnt /wasted/, as you see, its just a minor example.

Makes sense.

While I can agree that the system currently /works/, I disagree in that its the best possible way. For instance, just before I noticed this thread, I was about to to ask about modding in a flow system for my own personal use.

While yes, your flow of power never really changes in a direct debit system (all else equal), the perception does. I found that while playing trunk, I was far easier to tell that my power was going down then when I was using direct debt in 2.3.1a, specifically BECAUSE in direct debit the flow never changes.

Perhaps its a personal quirk of mine, but the rate of change is more important to me than the actual numbers. Perhaps that is because of my calculus background

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

While I specifically do not mean to diminish you as a supcom player,

Oh, no need to be that polite; I know I suck at SupCom.

I simply wish to point out that with practice, your ideal of not spending more than you gain would change. spring/ta/supcom are all pretty much the same, and one important feature of spring was that I could press 'w' to tell a building to 'wait' - that is, to stop using resources. Because of this, during a stall I could refocus my materials to important bits, if it was required. Usually, this is rare (i try not to overspend too much unless it is necessary), but now and again i need to stop a building to rush some AA or something.

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

Perhaps we differ here - I would say that because rate of change is more important than the actual number, we are actually simplifying things

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.

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.