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:Per wrote: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.
"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.
That "imperfectly" is another reason why I prefer power queue. No need to write a lot of code to better distribute where power goes.Per wrote: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.
Nothing is visualized on the power bar besides a mostly meaningless number.Per wrote: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.
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.
I suppose I can see that being a problem. How's about a list that appears when the power bar is clicked?Per wrote: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.
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.Per wrote: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 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.
Okay. Here's two.Per wrote: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.
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.
It's one thing to make a game challenging. It's another to make it frustrating with no benefit.j0shdrunk0nwar wrote: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.
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.
As I have hopefully demonstrated, it is impossible to be smart about your power use when you never know how much power you have.j0shdrunk0nwar wrote:I was only pointing out that I also agree with what Per stated, being smart about your power use,
Yes, this is an advantage of all direct debit systems over power flow.j0shdrunk0nwar wrote: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 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.j0shdrunk0nwar wrote: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.
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.j0shdrunk0nwar wrote:Are there any other advantages that I may have missed out? Or which you haven't mentioned? Any drawbacks of the direct-debit method?
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.
Supreme Commander does the same thing.Lancefighter wrote: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
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.
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.KenAlcock wrote: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.
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.