Warzone's power system

[Crymson]

I don't think it is possible to describe the changes accurately.
The best way would be to produce two builds, one with the current way, and the other one with the proposed new way.
Stick them in this thread and let people actually try them out.

Anything less, and it just isn't going to work.

[andron]

i dont think its a so important change that i would make the work and try that.
The only think i realy would like to ask the developers as player: PLEASE make a system where i do not must all the time look if i have so much built that my research and productions will not continue for a long time (that is why i would much prefer queued)

[Per]

The only think i realy would like to ask the developers as player: PLEASE make a system where i do not must all the time look if i have so much built that my research and productions will not continue for a long time (that is why i would much prefer queued)

All the systems are queued in that sense.

[JDW]

Looks like both methods have their own desirable advantages. Maybe using a toggle switch to switch between the two methods (only when running in low power conditions maybe?) would help get more feedback from the players on what they generally prefer to play with.

Heck, if you had a toggle switch, you would satisfy both camps.

[Safety0ff]

[...] using a toggle switch to switch between the two methods (only when running in low power conditions maybe?) would help get more feedback from the players on what they generally prefer to play with.

While providing multiple executables with different power implementations for testing is a possibility (provided you can find people that are willing to make code that will not likely be used.)

Heck, if you had a toggle switch, you would satisfy both camps.

Personally, I think that multiple power systems is a less desirable option than having a democratic/executive/dictator decision taken about which power system should be used.

[Zarel]

I'm with Safety0ff here.

Currently, in terms of power systems I'd prefer:

1. direct debit power queue
2. direct debit allocation
3. power flow allocation
...
8. power flow power queue
...
122453243231. toggle switch

[JDW]

122453243231. toggle switch

Wise Guy, eh?

Well then, in my personal honest opinion, power flow is here to stay.

[cybersphinx]

As a general comment: Every option splits the code paths people use, respectively the number of people using one code path, and so reduce the amount of testing each path gets. A high level example would be the split between campaign and skirmish/multiplayer - the campaign missions get less testing (and use more diverse scripting functions etc.) and so tend to break easier, and those problems tend to be found later.

As long as each setting for an option gets about equal users it's not that bad, but if a majority uses one setting, it might be better to make that the default and remove the option (obviously doesn't work that well for the campaign, though there were thoughts to split the game into a version for multiplayer and one for campaign).

[JDW]

Personally, I think that multiple power systems is a less desirable option than having a democratic/executive/dictator decision taken about which power system should be used.

So what you're saying is that it's better if all time is devoted to perfecting the best solution, than having to work on two solutions to the same problem. I see your point, and I think you're right. I guess deciding on what is the best solution before implementing it is better planning.

Every option splits the code paths people use, respectively the number of people using one code path, and so reduce the amount of testing each path gets.

As long as each setting for an option gets about equal users it's not that bad, but if a majority uses one setting, it might be better to make that the default and remove the option

I see how that would be bad for testing. A single power system would get more efficient testing.

[Zarel]

Not only that, but for multiplayer, people would have to either learn both systems, or learn only one system and only have half as many people they can play against as before.

[Lancefighter]

If i might ask, why did you switch to the flow system for trunk?
It seems that none of the dev staff is actually for the flow method.. so uh, what prompted the change?

[Safety0ff]

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.

[JDW]

Not only that, but for multiplayer, people would have to either learn both systems, or learn only one system and only have half as many people they can play against as before.

I agree with you Zarel. But I think I need to clarify my proposed idea. What I actually proposed was, now that I have pondered over it it more, just a simple queue system as an add-on to the power flow. And I'm quite certain it has already come up in this thread before. I believe it was Per who proposed this.

Anyway, what I proposed was why not have the power-flow system where all power actions are accruing simultaneously (as the default), but include a toggle switch whereby a power queue could be enabled/disabled in the middle of the game. So when the player is in a low-power situation under default simultaneous accruing, he can enable the power queue if required (with possible abilities to manage the queue, like pushing urgently required power actions to the top. Again, already mentioned in this thread).

As I understand it, this proposal has nothing to do with the direct-debit method. And I'm quite sure that no one is going to toggle between the two options, they'll probably stick to one setting throughout the entire game, which wouldn't serve the true purpose of the toggle switch in the first place. However, it would make pausing actions much quicker and simpler because it would become a single click.

[Zarel]

If i might ask, why did you switch to the flow system for trunk?
It seems that none of the dev staff is actually for the flow method.. so uh, what prompted the change?

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.

[Zarel]

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.