Common steady-stream resource flow

Harimau · January 2011

<div class="IPBDescription">opposed to discrete resource towers producing resources every interval</div><u>Summary:</u>
Basically, my argument is for a "common" resource flow (based on <b>quality</b> and <b>quantity</b> of towers) with fractional resource flow at a constant tick rate, e.g.

for one basic operating tower: 1/12 resource every 1 second; <b>rather than</b> <u>discrete</u> resource towers which each produce resources separately: 1 resource every 12 seconds (which is what it is now).
for two basic operating towers built 2 seconds apart, 2/12 resource every second; <b>rather than</b> 1 resource now, then 1 resource 2 seconds later, then 1 resource 10 seconds later, then 1 resource 2 seconds later, etc...

<u>Background:</u>
(Discrete resource towers)
<div class='quotetop'>QUOTE (Harimau @ Jan 28 2011, 06:34 PM) <a href="index.php?act=findpost&pid=1828070"><{POST_SNAPBACK}></a></div><div class='quotemain'>Also, <b>the way extractors/harvesters work in the game is</b>:
4 seconds after THIS tower has finished construction, you get 1 resource from THIS tower; then 12 seconds later, you get 1 resource from THIS tower; etc.
THIS tower's resource timing is unrelated to THAT tower's timing.

So what this means is, if you built 3 towers with a space apart of 0.1 seconds, you'd get 1,2,3 resources quickly, then wait about another 11.7 seconds for the next 1,2,3 resources.

This is, imo, a problem, as it is completely unintuitive and clumsy. I imagine it's also more processor-intensive than it really should be, as each RT operates completely separately.</div>

<u>Implementation:</u>
('common' steady-stream resource flow)
<div class='quotetop'>QUOTE (Harimau @ Jan 28 2011, 06:34 PM) <a href="index.php?act=findpost&pid=1828070"><{POST_SNAPBACK}></a></div><div class='quotemain'>The time instead should be unified; and you should have a <b>constant</b> resource tick rate, based on how many towers you have <b>operating</b> (you could still have that 4 second delay, just have towers in two states: operating and not operating).

However, you could keep the values as is, and also have fractional res instead (displayed as decimals).
So for example, if the server updates resources every second:
Res per second = Number of operating towers * 1/12
New res = Current res + Res per second = e.g. 5/12 + 1/12</div>

<u>Implementation:</u>
(multi-state array)
<div class='quotetop'>QUOTE (Harimau @ Jan 28 2011, 11:30 PM) <a href="index.php?act=findpost&pid=1828120"><{POST_SNAPBACK}></a></div><div class='quotemain'>That's just a matter of setting it in different states.

For example, if you had a <b>vector full of variables</b>:
<i>"Number of towers" (in each 'state')</i>
[Currently constructing, Not operating, Operating, Upgraded(1), Upgraded(2), Upgraded(3), ...]

Then you could have another <b>vector full of constants</b>:
<i>"Resource per tower" (for each 'state')</i>
[0, 0, ResPerSecond normal, ResPerSecond upgraded(1), ResPerSecond upgraded(2), ResPerSecond upgraded(3), ...]

Take the <b>dot product</b> of the two vectors*, that gives your total res per second.

*Total res per second = (0 * Currently constructing) + (0 * Not Operating) + (ResPerSecond normal * Operating) + (ResPerSecond upgraded(1) * Upgraded(1)) + ...

e.g.
Total res per second = 0*1 + 0*0 + (1/12)*5 + (2/12)*1 + ...</div>

<u>Discussion:</u>
<div class='quotetop'>QUOTE (Harimau @ Jan 29 2011, 01:07 AM) <a href="index.php?act=findpost&pid=1828141"><{POST_SNAPBACK}></a></div><div class='quotemain'><div class='quotetop'>QUOTE (Feha @ Jan 28 2011, 11:43 PM) <a href="index.php?act=findpost&pid=1828125"><{POST_SNAPBACK}></a></div><div class='quotemain'>Still would not work at individuall speed upgrades</div>
Why would you want individual speed upgrades?
<div class='quotetop'>QUOTE (Feha @ Jan 28 2011, 11:43 PM) <a href="index.php?act=findpost&pid=1828125"><{POST_SNAPBACK}></a></div><div class='quotemain'>as all that using dot like that can do is calculate how much res you would have gotten in one second with the new speed, and not actually give res in the new speed.</div>
Uh...? Obviously it's just, once every second, do this:
New res = Previous res + Total res per second

Double res room is just another state you could add.
</div>
(differentiating team and personal resource flow)
<div class='quotetop'>QUOTE (Harimau @ Jan 29 2011, 11:21 AM) <a href="index.php?act=findpost&pid=1828319"><{POST_SNAPBACK}></a></div><div class='quotemain'><div class='quotetop'>QUOTE (culprit @ Jan 29 2011, 05:18 AM) <a href="index.php?act=findpost&pid=1828199"><{POST_SNAPBACK}></a></div><div class='quotemain'>I'm pretty sure that the RTs all have individual tick rates because they can be upgraded.</div>
I've accounted for that with the vectors. (I suggested vectors because you can then use the dot product function which I imagine would be very quick and simple to use.) But individual tick rates on the other hand are messy, non-standard and un-intuitive, given the 'capped point' implementation.

Given that you have two resources, Personal and Team; and in the current implementation Personal can be upgraded and Team can't, it's just a matter of creating two constant state-vectors.

Number of towers in each state:
[Currently constructing, Not operating, Operating, Upgraded(1), Upgraded(2), Upgraded(3), ...]

Team:
[0, 0, 1/12, 1/12, 1/12, 1/12, ...]

Personal:
[0, 0, 1/12*1.00, 1/12*1.33, 1/12*1.67, 1/12*2.00, ...]

In the code, plasma and carbon are added separately anyway (though this is rather obvious), so nothing has changed in that sense; it's simply a matter of finding the dot product of the variable vector with each constant vector, and then adding the number to each resource appropriately.
</div>

Loey · January 2011

whats the reason you want to change resource models? sounds like a good plan

Hugh · January 2011

I think this is logical, well thought out, and useful Harimau. Well done.

schkorpio · January 2011

makes sense to me harimau

isn't this how it was in ns1?

Soylent_green · January 2011

Can you clarify why you feel that an even rate of resource flow is better?

---

Having a shared state-vector introduces unecessary dependencies, exactly the thing to avoid if you don't want to introduce bugs, between the res nodes and has no benefit whatsoever unless you intend to have <a href="http://www.youtube.com/watch?v=zPLmNwT5L88" target="_blank">a million res nodes</a>, in which case you have much bigger problems elsewhere. Timer calls are expensive, but they should only occur once per server simulation tick and the result reused by every object that needs it; most likely you are only saving a single floating point subtract or add and floating point compare per RT.

RTs still need to exist as independent objects; they're still visible, they still cause collisions, they still have animations and make noises. So you're just adding complexity by introducing your state vector. Without a state vector, when an RT is destroyed that instance of the RT class is deleted and it can no longer add res to the team; when and RT is created it is always created in the correct(unbuilt) state. With a state vector, when and RT is destroyed you must back out the correct number of res per second from the state vector, accounting for the current state of the RT, whether building, built or varying levels of upgrading; if you don't account properly for all possible circumstances you can get phantom res income from an RT that being upgraded but was destroyed before finishing or phantom res drain from an RT that was destroyed after being built but before starting to produce res.

If you really want res to be awarded every second, or every server tick for that matter, it is much easier to do it on an RT by RT basis. Optimizing things which do not need to be optimized at a cost of potentially introducing subtle gameplay bugs is an evil.

Harimau · January 2011

<i>Edit: moved this to the top of my post to address the question at the top of your post.</i>
This proposed resource system returns clarity and predictability to the resource rate, and is, imo, worth the effort.
Players will be able to tell very easily about how long until they can afford something, it's very intuitive. Not only that, it's standard: for RTS games that use capture points (dawn of war, supreme commander) and not resource gatherers, the resources do update steadily and consistently, and not jump every now and then for some unknown reason.
An added benefit is being able to see your actual resource income on the user interface, very clear-cut, no guesswork involved.

With a million res nodes the resource counter would go up so fast you wouldn't even notice the resource spikes or the interval...

Seriously, though, I acknowledge that those are potential bugs that could occur, and I had been thinking on when/how the best way to update the states would be, but the very fact that we're able to just predict these issues before we've even committed anything to code bodes well for an actual implementation.

An <b>ideal</b> implementation would be: with every update, you want to <b>tally</b> the resource towers at their different states, and award resources based on those numbers.
<b>Manipulating</b> the vectors on every change/'action' (construction complete, tower destroyed, power going out, etc.) would ostensibly work, but be more cumbersome to implement and be more prone to the errors you've described. If I couldn't get the above ideal implementation to work, I would probably still try this implementation.

<div class='quotetop'>QUOTE (Soylent_green @ Jan 29 2011, 10:08 PM) <a href="index.php?act=findpost&pid=1828422"><{POST_SNAPBACK}></a></div><div class='quotemain'>If you really want res to be awarded every second, or every server tick for that matter, it is much easier to do it on an RT by RT basis. Optimizing things which do not need to be optimized at a cost of potentially introducing subtle gameplay bugs is an evil.</div>
This may work, in a sense, except that the resource towers are still going to be updating separately; even if they update more often with fractional resource income, they're not on shared time. If you could get them to operate on shared time, then that would solve this issue. Additionally, it is a lot more calculation.

Soylent_green · January 2011

<div class='quotetop'>QUOTE (Harimau @ Jan 29 2011, 10:28 AM) <a href="index.php?act=findpost&pid=1828425"><{POST_SNAPBACK}></a></div><div class='quotemain'>This may work, in a sense, except that the resource towers are still going to be updating separately; even if they update more often with fractional resource income, they're not on shared time. If you could get them to operate on shared time, then that would solve this issue.</div>

No, if you update every server tick it all updates in unison. You don't need to send a message from server to client unless the floored value(what clients actually see) has changed since last tick(either as a result of spending or res gain).

Harimau · January 2011

Then sure, that could work.

twiliteblue · January 2011

Wouldn't it be a lot simpler to increase the res income to a more perceptible rate (of 0.5 to 1 per second per node), and scale cost of things? I know a lot of people have become somewhat attached to the old numbers (eg 100 res for Onos), but we can all adapt quickly to simple changes like these.

Feha · January 2011

I agree to harimarus idea, sure it makes it impossible to add speed upgrades to extractors, but it can be made using effeciency upgrades instead, boosting amount you get every update.

Using this idea you can for example display the current income speed, which apart from being helpfull for planning how to spend resources, also is a great indicator of how many extractors you have (unless you upgrade them).
It would also make the upgrades more intuitive, as then you get strong feedback to your upgrades telling you it upgraded the plasma income, but not carbon income (or how it currently is).
Sure you can without the idea, but then it would still be confusing, as the player would at one moment see 3 resources quickly arrive, after 5 seconds later 2 more, and after some while 3 again, while it says that the income should be 5. Would not do much but confuse the player.

Just make sure you only make players display floored values, and preferably only send the floored res to players when it changed (they dont need decimals, and this lowers network traffic).

l3lessed · January 2011

Playing almost every RTS I can get my hands on, I would be up for this and I think actually prefer it. It makes me think of Starcraft. Even though there system is much different, the community has figured out what the income rate is of a fully saturated mineral line is. Now when I play, I can easily plan my moves knowing what my income rate is once I get the mineral line fully saturated. This is very important information for any serious commander to know because it has huge implications on the choices he makes.

Again, as I have said about other things, the more information you can give to players in natural and accessible ways the better.

Chris0132 · January 2011

Does irregularity over the span of twelve seconds REALLY matter that much?

You get money from extractors, build more extractors to get more money, that currently works fine, I really don't see the need to go any more in depth.

Harimau · January 2011

The answer to your question, Chris, is yes.

Chris0132 · January 2011

Why exactly? What difference does it make?

Plasma · January 2011

I agree this is a good idea.

Chris: I personally like this idea better than what it is at the moment because it means I can predict/time when I will have enough res for something by just getting a feel for how long it took to get the last few bits of res.

Harimau · January 2011

I've already explained the virtues of a steady resource flow (most are obvious), but Chris clearly doesn't read.

twiliteblue · January 2011

The problem is, with 2 RTs (a rather common situation), it takes 3-6 seconds to gain 1 P.Res, and 6 seconds to gain 1 T.Res. That is too long for the attention span of players to keep track of their income rate (nobody enjoys having to stare at the res counter for a long time). For income rate to feel "continuous", the res rate would have to be doubled, or even tripled, so you would see res gain every second or two. Which is why I prefer the much simpler solution of scaling the resource numbers up.

Feha · January 2011

<div class='quotetop'>QUOTE (twiliteblue @ Jan 31 2011, 03:00 PM) <a href="index.php?act=findpost&pid=1828803"><{POST_SNAPBACK}></a></div><div class='quotemain'>The problem is, with 2 RTs (a rather common situation), it takes 3-6 seconds to gain 1 P.Res, and 6 seconds to gain 1 T.Res. That is too long for the attention span of players to keep track of their income rate (nobody enjoys having to stare at the res counter for a long time). For income rate to feel "continuous", the res rate would have to be doubled, or even tripled, so you would see res gain every second or two. Which is why I prefer the much simpler solution of scaling the resource numbers up.</div>

This is kind of true, not many players would want a resource bar that only updates every 12 second, and you cant make it update faster without adding decimals if one extractor only gives 1/12 res/second.
Instead it could be made so that it does not only update resources every 12 seconds, but instead every second (which is the proposed idea afaik). So if you have 1 extractor it is 1/12 resources every second, making the visual counter go up with 1 res every 12 seconds. If you instead have 2 extractors, you get 2/12 res/s, which is same as 1/6 res/s, which equals 1 res every 6 second.

Chris0132 · January 2011

<div class='quotetop'>QUOTE (Harimau @ Jan 31 2011, 05:32 AM) <a href="index.php?act=findpost&pid=1828756"><{POST_SNAPBACK}></a></div><div class='quotemain'>I've already explained the virtues of a steady resource flow (most are obvious), but Chris clearly doesn't read.</div>

Other than 'I really really need to know exactly when I will get money and twelve seconds is just too irregular for me' I really don't see any.

It's twelve seconds, if twelve seconds makes that much difference then you must be running rather tight on money.

I simply cannot see sufficient justification for the time, effort, and bugs that will ensue from trying to implement this suggestion.

It's like you're suggesting they rewrite movement entirely because the footstep sounds are a few milliseconds out of regularity.

It just doesn't seem at all worth it.

l3lessed · January 2011

Chris if you were a competitive RTS player you would understand every single second and resources counts. There a numerous times that starting an upgrade a few seconds late, getting out a unit a little late, starting a building a few seconds late, and so on can cause you to completely loose a battle because your opponent kept an eye on his resource income rate and was ahead of you. I can't count the amount of games something as small as this in starcraft 2 has either won or cost me the game.

It is extremely important to any RTS.

that being said, I believe they have more important stuff to work on first, but if they get the time it is well worth it and would add another competitive edge and feel to the game.

Loey · January 2011

<div class='quotetop'>QUOTE (Chris0132 @ Feb 1 2011, 06:12 AM) <a href="index.php?act=findpost&pid=1828826"><{POST_SNAPBACK}></a></div><div class='quotemain'>Other than 'I really really need to know exactly when I will get money and twelve seconds is just too irregular for me' I really don't see any.

It's twelve seconds, if twelve seconds makes that much difference then you must be running rather tight on money.

I simply cannot see sufficient justification for the time, effort, and bugs that will ensue from trying to implement this suggestion.

It's like you're suggesting they rewrite movement entirely because the footstep sounds are a few milliseconds out of regularity.

It just doesn't seem at all worth it.</div>
except out of time footsteps dont affect gameplay where as knowing the resource rate does as stated before. you may think it doesnt matter, but every other RTS shows it does.

Chris0132 · February 2011

<div class='quotetop'>QUOTE (Loey @ Feb 1 2011, 02:51 AM) <a href="index.php?act=findpost&pid=1828925"><{POST_SNAPBACK}></a></div><div class='quotemain'>except out of time footsteps dont affect gameplay where as knowing the resource rate does as stated before. you may think it doesnt matter, but every other RTS shows it does.</div>

Nor do minor fluctuations in resource flow over the span of twelve seconds. Games do not last a matter of minutes, they last about half an hour to an hour, twelve seconds in half an hour is not a significant span of time.

At the absolute worst you will get three or four res every 12 seconds. More probably you will get more or less one res every four seconds, maybe you get one res every four seconds and two res every six seconds or something, but it's just not that important.

I have never played an RTS where I absolutely required my res flow to be perfectly steady, hell 'every other rts' most certainly doesn't do it, any RTS that has actual harvester units has a very irregular income pattern because of the time it takes for the harvester to go out, gather stuff, then bring it back, it doesn't affect my ability to play them.

NinjaWithSpoons · February 2011

<div class='quotetop'>QUOTE (Chris0132 @ Feb 1 2011, 03:21 AM) <a href="index.php?act=findpost&pid=1828978"><{POST_SNAPBACK}></a></div><div class='quotemain'>I have never played an RTS where I absolutely required my res flow to be perfectly steady, hell 'every other rts' most certainly doesn't do it, any RTS that has actual harvester units has a very irregular income pattern because of the time it takes for the harvester to go out, gather stuff, then bring it back, it doesn't affect my ability to play them.</div>

Yes but with a harvester that goes out and gets resources, you can SEE it do that and know how long it will take to get X resources. This game does not have a visible resource gatherer, you merely get resources every 12 seconds, and there is no way of telling when you will get more except by counting seconds since the last income. It is very unintuitive and the 12 seconds seems arbitrary. Also in those games, you will have upwards of 15-20 gatherers, making the resource stream pretty continuous. There really isn't a reason NOT to have it give income every 1 second.

I agree with twiliteblue that the costs should be multiplied so that each RT can give a whole number of resources every second. Getting 1/12 of a resource every second is only slightly better than what we have now, because you will still have to wait several seconds to get a full resource and not know how close you are to the next resource.

Uzguz · February 2011

I wouldn't mind making resources accumulate more steadily, but the current "encapsulated" implementation of RTs is perfectly capable of accommodating that. The shared vector part is not necessary.

Loey · February 2011

<div class='quotetop'>QUOTE (Chris0132 @ Feb 1 2011, 08:21 PM) <a href="index.php?act=findpost&pid=1828978"><{POST_SNAPBACK}></a></div><div class='quotemain'>Nor do minor fluctuations in resource flow over the span of twelve seconds. Games do not last a matter of minutes, they last about half an hour to an hour, twelve seconds in half an hour is not a significant span of time.

At the absolute worst you will get three or four res every 12 seconds. More probably you will get more or less one res every four seconds, maybe you get one res every four seconds and two res every six seconds or something, but it's just not that important.

I have never played an RTS where I absolutely required my res flow to be perfectly steady, hell 'every other rts' most certainly doesn't do it, any RTS that has actual harvester units has a very irregular income pattern because of the time it takes for the harvester to go out, gather stuff, then bring it back, it doesn't affect my ability to play them.</div>
watch a competitive starcraft game/look up the strategies, 12 seconds can be the time it takes to win or lose a match.

in regards to harvesters, the time it takes for them to go out, harvest and return is all calculated by competitive players.

fair enough ns isnt starcraft, but being able to predict resource rate allows commanders to fine tune strategies

Runteh · February 2011

I agree with the above, and OP.

Harimau · February 2011

Chris, you're providing nothing substantial nor constructive to this discussion.
The full sum of your argument is "I do not agree." That is <b>all</b>.
Reducing all of our many well-reasoned arguments down to your level: "We do not agree with your disagreement."
Accept this, and move on.

<div class='quotetop'>QUOTE (Uzguz @ Feb 1 2011, 09:01 PM) <a href="index.php?act=findpost&pid=1829004"><{POST_SNAPBACK}></a></div><div class='quotemain'>I wouldn't mind making resources accumulate more steadily, but the current "encapsulated" implementation of RTs is perfectly capable of accommodating that. The shared vector part is not necessary.</div>
Yeah, we had this discussion on the first page. One implementation would be to update resources (i.e. each resource tower) on a <b>shared</b> time (e.g. every server tick; but only send floored values to the client) with fractional resource flow (calculating the fractional resource flow is simple: It's just UpdateTimeInterval*ResourcePerSecond; ResourcePerSecond = 1/TimeItTakesToGet1Resource); however this is a lot more calculation (what each RT did every 12 seconds, it now does every server tick), but at least it doesn't require much re-writing of the code.
The shared vector, if you could get it to work ideally (i.e. just by counting the entities present on the map), would only require effectively one dot-product calculation every update.

<div class='quotetop'>QUOTE (NinjaWithSpoons @ Feb 1 2011, 07:54 PM) <a href="index.php?act=findpost&pid=1828992"><{POST_SNAPBACK}></a></div><div class='quotemain'>I agree with twiliteblue that the costs should be multiplied so that each RT can give a whole number of resources every second. Getting 1/12 of a resource every second is only slightly better than what we have now, because you will still have to wait several seconds to get a full resource and not know how close you are to the next resource.</div>
One benefit to a steady resource flow, though, is to be able to see your actual resources per second as a number on the commander interface; so you could easily tell how long you have left to wait.

Of course, the idea is that that number would also be fractional/decimal, as would your actual resource counter.
You could scale all resource production and costs up by, say, a factor of 36; and you shouldn't require any decimals or fractions, just bigger numbers.
e.g.
A single unupgraded resource tower provides 3 carbon, 3 plasma per second
First-upgrade resource tower provides 3 carbon, 4 plasma per second (+33%)
Second-upgrade resource tower provides 3 carbon, 5 plasma per second (+67%)
Third-upgrade resource tower provides 3 carbon, 6 plasma per second (+100%)
A sentry would cost 720 carbon.
(Based on the current values.)

Chris0132 · February 2011

<div class='quotetop'>QUOTE (Harimau @ Feb 2 2011, 05:22 AM) <a href="index.php?act=findpost&pid=1829131"><{POST_SNAPBACK}></a></div><div class='quotemain'>Chris, you're providing nothing substantial nor constructive to this discussion.
The full sum of your argument is "I do not agree." That is <b>all</b>.
Reducing all of our many well-reasoned arguments down to your level: "We do not agree with your disagreement."
Accept this, and move on.</div>

I explained quite extensively how the irregularity in income is not significant, and also gave examples of perfectly successful games which have even more irregular resource rates. Your counter to this is 'your argument sucks go away'.

So don't tell me that I am not giving an argument please, because I am, at length, if you aren't reading it that isn't my fault.

Loey · February 2011

you've not provided any examples of successful games with "irregular resource rates".

RobB · February 2011

How about simply syncronizing the resource towers?
A marine rt has to establish it's cycle properly with the operating system of HQ (Commandconsoles), which "coincidently" takes until the flow cycle is finished and then starts producing like the rest of the towers (in other words, the cycle the rt completes is ignored).

dunno why an alien biological tower should syncronize, though.

Chris0132 · February 2011

<div class='quotetop'>QUOTE (Loey @ Feb 3 2011, 02:29 AM) <a href="index.php?act=findpost&pid=1829318"><{POST_SNAPBACK}></a></div><div class='quotemain'>you've not provided any examples of successful games with "irregular resource rates".</div>

Like I said, any game with harvesters.

You can't exactly keep track of them while you're doing other stuff and even if you could, you still have to wait between 30 seconds to a minute to get money, so it's still very irregular because it comes in lumps. If the worst comes to the worst you can just assume NS will give you <number of extractors> income every 12 seconds, because it will, it will still be more regular than many RTS games.

Common steady-stream resource flow

Comments