Loading...
  OR  Zero-K Name:    Password:   

Should everything be 6% cheaper?

51 posts, 2008 views
Post comment
Filter:    Player:  
Page of 3 (51 records)
sort


9 years ago
There is a bit of a problem with the economy that has been known for quite some time. It is to do with a disconnect between tooltips and what actually happens in the game. In effect the tooltips say that everything is 6% cheaper than it actually is. To fix the discrepancy everything would either become cheaper or have ugly numbers.

In the early days of the Spring engine someone must have loved powers of 2 while someone else thought that games should run at 30 frames per second. The result is that economy updates occur every 16 frames while the simulation runs at 30 frames per second. Economy things do half of their stated action every update. For example Solars produce 1 energy every 16 frames.

This affects everything. Mexes and power plants have a bit less income than you think they do. Constructors drain a bit less. These things have 93.75% of their stated value.

The difference is irrelevant when trying to balance your economy, the UI numbers are still useful for that. Everything has less income and drains less so perfect balance is still perfect balance. The difference does not even matter for metal and energy cost. I have tested, if you perfectly balance your economy and then make a Guess it costs 400 metal. The distinction is that it will take 85 seconds to complete with 5 BP, not 80.

The distinction between tooltip and the real behaviour cancels out until you consider how long it takes to build something. But time is the fundamental resource so it seems fairly important. So making the game match the tooltips would make the entire economy run faster.

The fix would involve increasing the income and BP of all economy structures and constructors and then displaying the current value on the UI. This would also have to be taken into account in guide generation. Alternately the multiplier in the engine could be changed but that would affect all games. I am not sure whether they would accept that.

Fixing this is probably worthwhile. We should snatch up opportunities to reduce economy confusion where possible. Currently people could doubt the simplicity of the economy if they look closely at ETA or stockpile times and notice the discrepancy.

I worry a bit about the effects. ZK would become faster.
+4 / -0
Starcraft time runs at, what, 20% faster than real time?

We basically have something similar, economy time runs 6% faster than real time.

If there is a simple way to fix it (say, increasing game speed by 6%?) without ugly numbers or changing balance, sure. Otherwise, it's probably one of those little quirks.

As long as ETA is correct, that's fine, most people will only realise if they run the numbers.
+1 / -0


9 years ago
IMO this is something that should be fixed engine side. So if we can obtain 99, this becomes an option.
+2 / -0
9 years ago
This is amusing I: thought that Spring engine is straightforward with its numbers!
Now it just happens that there is as much inconsistency as Starcraft's 2 faster reality does! But at least ZK in itself has so much randomness just in how the projectiles tend to miss things that it matters much less than faster time in SC 2. Therefore I also don't think this is much of an issue but I would still like to see it being corrected (altrough this might bork the whole balance of ZK as well).
+0 / -0
So basically the problem here is that if you sit with a watch and check the real time it takes to build an object, you get a small difference compared to the expected (based on tooltips) time.

I dont see anything there that can be fixed without breaking too many other things. The choice is to either have ugly real-time numbers, or to have ugly numbers in the code.

It might be a good idea to fix the ETA widget so that it displays the adjusted real time, but i highly doubt it would matter - in a real game the ETA timer is always very unstable and the small error created by this engine problem is absolutely irrelevant.
I bet if someone ninja-changed it to work that way, no one would even notice it for years, possibly ever.
+1 / -0


9 years ago
Ugly numbers in the code are undesirable but I would not say it breaks anything. If we had some fixed amount of uglyness to dish out I would put it in numbers in code rather than numbers on UI.
+2 / -0

9 years ago
so, you say you can play more in the same time? thats an improvement i recommend!
+2 / -0
9 years ago
quote:
Ugly numbers in the code are undesirable but I would not say it breaks anything. If we had some fixed amount of uglyness to dish out I would put it in numbers in code rather than numbers on UI.

So basically you'd have to change the income, BP and costs in the code, and then update every single UI element to display an adjusted value.

If you think it's worth it, then sure, go for it. You can even ninja it and nobody will be any wiser unless they check the code. But personally, i believe there are plenty of other things which are significantly more important.
+2 / -0

9 years ago
quote:

In the early days of the Spring engine someone must have loved powers of 2


A story as old as programming. Someone learns about x >> 1 or misunderstands memory alignment, then decides everything must be 2^n for performance reasons.

To get back on-topic: I'm in favor of anything that makes the gameplay faster (even imperceptibly).
+0 / -0

9 years ago
I think 6% is a small enough change to be acceptable. I doubt balance or gameflow will be affected significantly.

* It's kind of depressing though that it would probably be easier to hack the change in zk code than navigate the politics of the engine and spring community.

I heartily agree with the attitude that it is important to have truthful numbers and transparent mechanics. Treat players as smart people.
+2 / -0
9 years ago
This could subtly change gameplay. Building units and buildings will be faster in comparison to unit movement. For instance: when you see incoming raiders, your emergency llt will finish faster. When someone is porcpushing, new defenders will pop up 6% faster with respect to the firing rate of your hammers.
In the case of an airstart, building AA will be 6% faster with respect to raven flight time.
TL;DR: this affects so many things in a subtly way, it is a buff of building speed with respect to unit and projectile movement.
+3 / -0
The numbers you see on the UI help build the intuition about how long things take and what is an appropriately fast response to what's happening on the map.
Taking cost, metal income and BP into account, and responding to things, should yield the outcome expected when you look at the numbers.

What's the correct fix?
Would changing economy to happen in 15 frames, without changing anything else, fix it?
+0 / -0
Changing engine is not the right fix. Better to have tick rate independent code.
+0 / -0

9 years ago
We could reduce the impact by reducing all income by 6% as well, making it effectively just a 6% BP buff, a smaller change.
+0 / -1
quote:
rts/Sim/Misc/GlobalConstants.h

/**
  • @brief game speed
*
  • Defines the game-/sim-frames per second.
*/
const int GAME_SPEED = 30;


Fix seems simple :D
+0 / -0
Much to my surprise frame%32==0 check produces 10 times less amount of assembly instructions than frame%30==0.

I think it wouldn't hurt to fix 32/30 thing in ZK to increase the accuracy of ETA. On the side note, Aspis and Aegis are already somehow affected with 32/30 singularity. For example according to ZK unitdef files, recharging Aegis should consume 1.5 (permanent power consumption) + 9 (regen power consumption)

10.5 Energy units per ...hmm 32 frames(?), but the factual consumption as reported by UI and Lua functions is 11.1

1.5 + 9*32/30.

USrank[I]burp, actually fix is probably in the different lines of the same file:

quote:

const int UNIT_SLOWUPDATE_RATE = 16; //make 15
const int TEAM_SLOWUPDATE_RATE = 32; //make 30
+0 / -0

9 years ago
Have you ever met anyone who told you that he noticed the discrepancy between build ETA and real time? And that he had investigated it to the point where he could rule out anything but a code fault?

I highly doubt it. Hence, I doubt this has really created any confusion so far.

What exactly is the issue with leaving things as is?
+1 / -0
quote:
What exactly is the issue with leaving things as is?

Actually, it did come up at one point when I was adjusting the resource and metal spot UIs. I wanted to put '/s' in there, and found out about this weirdness.

Seeing as Zero-K has generally sought to streamline the economy system and make it as straightforward and predictable as possible, it would follow from that principle to ensure that the timings of construction can also be easily predicted.

I'm honestly surprised people are using StarCraft's time rate weirdness as a point in favour of keeping the status quo. StarCraft's displayed time rate not matching the game speed is a mistake, which really should have been solved by adjusting build times for the speed setting in the tooltips while keeping the clock second equal to a real second. People expect time in minutes and seconds, not some arbitrary multiple thereof. They can get used to something different, but why force that, especially when we try so hard to keep everything (or at least the first principles for everything) as clear and obvious as possible? StarCraft gets a pass because it is StarCraft and everyone knows it (and seems to think it is the be-all and end-all of RTS). We aren't StarCraft, we don't get a pass, we need to be approachable.
+3 / -0


9 years ago
quote:
We could reduce the impact by reducing all income by 6% as well, making it effectively just a 6% BP buff, a smaller change.
NoNoNoNo. This would cause a difference of 6% between the meaning of net income and net expense. You could not even balance your economy. No numbers would be useful.

The comparison to Starcraft is incorrect. Everything in Starcraft is faster including the ingame clock. In Spring the clock does not agree with what you get if you divide Build Time by Build Power. In Starcraft you are fine as long as you time things and plan around the ingame clock.

I don't think the Starcraft clock implementation is a mistake. The ingame clock should be scaled by the speed of the game mechanics to keep things consistent between matches. You should be able to figure out when some tech or rush will hit at any game speed and have that result carry over to other games. This mistake is perhaps that the game is not 1x speed by default.

Consensus seems to be mildy in favour of making everything 6% cheaper. Now someone has to do it.
+0 / -0
Skasi
9 years ago
Why not give simframes 32 fps? Power of 2 everywhere! \o/
+0 / -0
Page of 3 (51 records)