|
On November 25 2014 04:05 RFDaemoniac wrote:
This worker curve does help incentivize taking more bases, but it still punishes you pretty strongly for losing a base. Secondarily we are hoping for a max saturation of much more than 24 workers.
This is an important part of the equation if you want to mimic BW style where one player has oversaturated and fewer bases, but still gets economy gain with worker production.
I think you can do this by just tuning the numbers, much longer post inc...
|
All problems encountered so far has been resolved. Had to do some more math though.
I updated the first post with the new information. If you haven't read it yet, please do so! 
|
On November 28 2014 03:27 BlackLilium wrote:All problems encountered so far has been resolved. Had to do some more math though. I updated the first post with the new information. If you haven't read it yet, please do so!
Haha, thanks. That's basically what I was going to suggest, except I didn't think it was necessary to add a 3rd harvest to the cycle. Can you elaborate on that? I found that with my duration times and 2 harvests during at-patch, it required 4wpp (workers per patch) to be fully saturated -- essentially having 2 separate worker pairs that were interleaved, but with some downtime making it inefficient. This extended the saturation curve to top out at 4n, where n = #patches. Yours looks good though too with the same result, ~32 workers required to max out a base and obvious benefits for expanding. It just seems like a worker at patch for ~7.5s would be weird; then again, I suppose you'd get used to it. It would definitely change how harassment works a little bit. For example, hellions in your mineral line would be able to kill workers a bit more efficiently since they are standing in one place stacked up for longer instead of running back and forth constantly automatically dodging some shots. For another example, widow mines. But that's just a change, not necessarily positive or negative.
Looking forward to trying this out more! I really like the idea!
My only concern now would be how much it changes the early game income rates, which would ideally be as closed to unchanged as possible so as not to upset build orders, which would have a cascading effect on metagame/balance stuff.
|
On November 28 2014 03:55 EatThePath wrote:
Haha, thanks. That's basically what I was going to suggest, except I didn't think it was necessary to add a 3rd harvest to the cycle. Can you elaborate on that? I found that with my duration times and 2 harvests during at-patch, it required 4wpp (workers per patch) to be fully saturated -- essentially having 2 separate worker pairs that were interleaved, but with some downtime making it inefficient. This extended the saturation curve to top out at 4n, where n = #patches. Yours looks good though too with the same result, ~32 workers required to max out a base and obvious benefits for expanding.
Assuming I understand you correctly - if you were able to squeeze 2 separate pairs at a mineral patch, it would mean that - by removing 1 worker in each pair - I can have 2 workers with little or no penality. That in turn would mean that I can have 16 workers per single base without penality. That means late 3rd and no need for 4th, similarly to the standard strategy.
So, one of my constraint was, that I do want to penalize 2 workers per patch a bit, but I still want to have some room for a 3rd worker.
Now, if you want an elaboration how I reached this values (some math ahead - beware )
An important observation in double-harvest strategy is that 2 workers on same patch can be set up in two configurations:
- Sequentially: one worker would do HWH while the other would WT and then vice-versa (H for Harvest, W for wait and t for transport, as in the first post).
- Interleaved: one worker's H hits the other's W, and then they both do WT at the end, with a single, last H difference.
Now, we want both strategies to actually be equally efficient. Otherwise, a player would be forced to do "micro" on a 8-16 worker base, to set them up correctly for a % boost - and we don't want that!
So, I come up with a formula: For an n-harvest, a full sequential cycle of 2 workers takes (time between events when first worker starts harvesting again):
2*(nH+(n-1)W)
For interleaved cycle you have
(2n-1)H+W+T
We want them to be equal, yielding the formula:
(2n-3)W+H=T
I then took the formula and did some testing with different values. To my delight, this computation on paper actually matched with what was happening during experimentation. When formula was not satisfied, 16 workers interleaved or 16 workers sequential were mining faster. When satisfied - the difference was within 1-2%.
So, equipped with this equation I could continue. The value T (transport) depends on the acceleration and speed of the worker and an (average) distance to the drop-off building. I approximated the value to 4.1s. So we have:
- For n=2: W+H=T
- For n=3: 3W+H=T
- For n=4: 5W+H=T
On the other hand, the ratio W:H roughly controls how much at disadvantage the 16-worker base will be over 8-worker base. A ratio around 1:2 seemed right to me. On the third hand (lol?) we want the total harvest time 2n(H+W) to be not too long.
So, for n=2 we have
H=2.53s
W=1.36s
Total harvest time = 7.78s
That, plus 1.36s worker waiting at the end with mineral patch already in its hands (claws?) looked ugly.
With n=3 I ended up with values
H=1.6716s
W=0.8093s
Total harvest time = 7.44s (a bit better), and the worker at the end of the harvesting sits for much shorter time with the minerals.
|
On November 28 2014 04:58 BlackLilium wrote:Show nested quote +On November 28 2014 03:55 EatThePath wrote:
Haha, thanks. That's basically what I was going to suggest, except I didn't think it was necessary to add a 3rd harvest to the cycle. Can you elaborate on that? I found that with my duration times and 2 harvests during at-patch, it required 4wpp (workers per patch) to be fully saturated -- essentially having 2 separate worker pairs that were interleaved, but with some downtime making it inefficient. This extended the saturation curve to top out at 4n, where n = #patches. Yours looks good though too with the same result, ~32 workers required to max out a base and obvious benefits for expanding. + Show Spoiler +Assuming I understand you correctly - if you were able to squeeze 2 separate pairs at a mineral patch, it would mean that - by removing 1 worker in each pair - I can have 2 workers with little or no penality. That in turn would mean that I can have 16 workers per single base without penality. That means late 3rd and no need for 4th, similarly to the standard strategy. So, one of my constraint was, that I do want to penalize 2 workers per patch a bit, but I still want to have some room for a 3rd worker. Now, if you want an elaboration how I reached this values (some math ahead - beware ) An important observation in double-harvest strategy is that 2 workers on same patch can be set up in two configurations: - Sequentially: one worker would do HWH while the other would WT and then vice-versa (H for Harvest, W for wait and t for transport, as in the first post).
- Interleaved: one worker's H hits the other's W, and then they both do WT at the end, with a single, last H difference.
Now, we want both strategies to actually be equally efficient. Otherwise, a player would be forced to do "micro" on a 8-16 worker base, to set them up correctly for a % boost - and we don't want that! So, I come up with a formula: For an n-harvest, a full sequential cycle of 2 workers takes (time between events when first worker starts harvesting again): 2*(nH+(n-1)W) For interleaved cycle you have (2n-1)H+W+T We want them to be equal, yielding the formula: (2n-3)W+H=T I then took the formula and did some testing with different values. To my delight, this computation on paper actually matched with what was happening during experimentation. When formula was not satisfied, 16 workers interleaved or 16 workers sequential were mining faster. When satisfied - the difference was within 1-2%. So, equipped with this equation I could continue. The value T (transport) depends on the acceleration and speed of the worker and an (average) distance to the drop-off building. I approximated the value to 4.1s. So we have: - For n=2: W+H=T
- For n=3: 3W+H=T
- For n=4: 5W+H=T
On the other hand, the ratio W:H roughly controls how much at disadvantage the 16-worker base will be over 8-worker base. A ratio around 1:2 seemed right to me. On the third hand (lol?) we want the total harvest time 2n(H+W) to be not too long. So, for n=2 we have H=2.53s W=1.36s Total harvest time = 7.78s That, plus 1.36s worker waiting at the end with mineral patch already in its hands (claws?) looked ugly. With n=3 I ended up with values H=1.6716s W=0.8093s Total harvest time = 7.44s (a bit better), and the worker at the end of the harvesting sits for much shorter time with the minerals.
Thanks for reply! I'm going to dig into this after holiday dinner... gl me, haha. But briefly, regarding 16worker saturation, the timing I had set up was such that 2wpp suffered about a 20% efficiency hit on the 2nd worker due to overlap of the harvesting/transport cycle. If you interleaved the 2 workers instead, you'd get a worse efficiency hit due to inability to interleave fully -- harvesting was longer than waiting, roughly what you have, approx. 1.25s to harvest and .75 to wait. Thus, 2wpp would be better served as 1wpp here and 1wpp at another base. I'll get into it more later! Again, thanks. ^^
Oh, and also, I don't think you should necessarily be averse to having micro at low #workers afford higher mining rate. While not quite the same thing, it was in fact quite important in BW to micro your early workers to get better efficiency out of them; this more took the form of sending them to mine once built, but that still involved selecting which patch they'd go to. If you picture the beginning of a game of present SC2, you see players micro'ing their starting workers and first several building workers quite a bit. I don't see that interleaving micro (if it was beneficial) would detract from gameplay or spectator value, and it could in fact contribute marginally.
|
Really nice read! Thank you very much for making the numbers on this
|
On November 26 2014 09:37 LaLuSh wrote:
Your solution is creative BlackLilium. Though it is not a lack of knowledge which prevents Blizzard from implementing diminishing returns. They could just copy paste code from their alpha builds of Starcraft 2, which had a slightly modified version of the older worker AI, and be done with it. They're unfortunately being intentionally bull-headed.
Sticking to a game design principle which you don't agree with is not necessarily 'bull-headed'.
|
On November 28 2014 18:33 [F_]aths wrote:Show nested quote +On November 26 2014 09:37 LaLuSh wrote:
Your solution is creative BlackLilium. Though it is not a lack of knowledge which prevents Blizzard from implementing diminishing returns. They could just copy paste code from their alpha builds of Starcraft 2, which had a slightly modified version of the older worker AI, and be done with it. They're unfortunately being intentionally bull-headed. Sticking to a game design principle which you don't agree with is not necessarily 'bull-headed'.
I'd call it stubborn, but the fact they're actually attempting to change the economy is something I have to give them credit for. I still think I'd prefer something like this, but I thought the economy would be something they would never touch...
|
Brood War income rate curve also maxes/flattens out at 3 workers per patch. It doesn't go beyond that as someone claimed.
Blacklilium. I noticed the graphs you added of your experiments. I'm really curious to know your methodology. How did you go about measuring the income rate?
Could you share the data with me? I find it very interesting and could have use for it in a project/article I've been working on for a long time.
|
Originally, I launched a test map, sent X workers and measure my mineral count at 1-minute (gametime) intervals 3 times.
I then realized it is actually the same as simply waiting 3 minutes and dividing the result by 3 and that is how I measured.
In addition:
- At 0-8 worker count I didn't measure every number as I didn't consider it that important. Some values are interpolated.
- At 0-8 worker count each worker goes to the different mineral field. First workers go to the nearest ones, then to the further ones.
- At 8-16 worker count I try to have stable 1-2 workers per field (Starbow obviously randomizes it). First I picked the closer field.
- At 16+ I didn't pay much attention to the distribution of workers between fields as it changes constantly
- At 24-32 I measured only every second number (24, 26, 28...) and interpolated the rest
- At 32+ I measured every 4th number, until I detect a flattened result (n+4 giving same result as n)
- Some values were measured for more than 3 ingame minutes (and then result divided accordingly)
- Some values were measured second time if the previous measurement seemed odd, presuming some bigger measurement error (I know, this is not very scientific)
I will share raw data shortly...
|
Here is the data I have
Harvesters Standard Starbow DH (3x3, 1.6716, 0.8093)
0 0 0 0
1 46 54 49.5
2 92 108 99
3 138 162 148.5
4 175.83 205.3 196
5 217.5 255 241
6 254.5 306.3 286
7 294 354 331
8 335 404 375.75
9 373 428 423
10 418 456 459
11 461 473 495
12 502 497 523.8
13 546.7 540 558
14 591.7 576 591.75
15 633.3 602 621
16 673.3 635.2 650.25
17 696.7 658 677.25
18 716.7 682.7 696.85
19 743.3 705.6 707.4
20 768.3 718.85 726.75
21 788.3 728 740.25
22 798.3 738.28 757.5
23 800 739.2 768
24 805 748 780.75
25 818 754 785.9
26 830.45 760 790.875
27 830.5 762 796.5
28 830.625 764 802
29 832 765 809
30 833.8 766 816
31 834 766.5 819.1
32 834 767 822.21
33 834 767 823
34 834 767 823
35 834 767 823
36 834 767 823
37 834 767 823
38 834 767 823
39 834 767 823
40 834 767 823
|
I was curious about how the 4th worker and onwards gave a boost when spread over 2 bases, but I'm guessing you put the first few workers on the mineral nodes closest to the main building. And that the boost on those lower worker numbers simply represents that.
I did these kinds of tests before and they're really time consuming, so thanks for taking the time. Found it helps and can make the process easier to take note of the numbers from a replay instead of ingame. Ingame you just make sure x workers mine for a couple minutes before changing.
|
On November 30 2014 17:00 LaLuSh wrote:
I was curious about how the 4th worker and onwards gave a boost when spread over 2 bases, but I'm guessing you put the first few workers on the mineral nodes closest to the main building. And that the boost on those lower worker numbers simply represents that.
Yes. First few workers were sent to the nearest mineral field and the next to the further ones. That caused the slight fluctuation on the lower worker count, but I didn't pay too much attention to it. Differences are small and you usually don't want to expand when having only 8 workers alive anyway. Discussion on those would be purely academic.
But the 2-over-1, 3-over-2 and 4-over-3 graphs are just computation based on a single-base experiment.
e.g. If I have 60 workers, I compared:
2*Income[30] versus 3*Income[20]
I didn't actually create two/three/four-bases experiment. Assuming the bases are the same, I don't expect to see any differences beyond measurement inaccuracy.
|
I need to go back and read this again, but here is the scenario that I've been toying around with in my head -- I'm just not good enough with the editor to figure out how to actually test this out. What I'd like to see is the following scenario:
Mining time is increased, but the payload is also increased from 5 to 8.
With each added miner, mining time is decreased but the payload is also decreased. Time at the mine decreased by 12.5% the full mining time for each worker, and payload decreased by 12.5% for each worker (8 --> 7 --> 6); in other words, one harvest time unit equals 1 mineral gathered.
This will "naturally" cap at 4 workers per patch (going to five workers can do the same thing but will have the same rate).
So, what this would look like on one base is:
At 1 worker per patch (8 minerals each worker, 8 minerals per patch), you would harvest 64 minerals in 1 round trip for each worker.
At 2 workers per patch (7 minerals each worker, 14 minerals per patch), you would harvest 112 minerals in 1 round trip for each worker.
At 3 workers per patch (6 minerals each worker, 18 minerals per patch), you would harvest 144 minerals in 1 round trip for each worker.
At 4 workers per patch (5 minerals each worker, 20 minerals per patch), you would harvest 160 minerals in 1 round trip for each worker.
At 5 workers per patch (4 minerals each worker, 20 minerals per patch), you would harvest 160 minerals in 1 round trip for each worker.
And above this, you would simply gain no added return.
If this can be accomplished such that the time on the mineral patch were efficient, meaning for 4 worker saturation they are completely consecutive in mining time on the patch (i.e. the patch is continuously mined), then you also have a visual indicator letting you know that you are fully saturated, because before this there would be tiny gaps in there being a worker on the patch.
The difference between this and how the same 16/24/32 workers would be spread out over 2/3/4 bases would be:
112/128 = 87.5% efficient
144/192 = 75% efficient
160/256 = 62.5% efficient
These are eighths, which to me is a very intuitive scaling effect. Not only that, but for all of us nerds, the numbers involved (powers of 2, 144, 160, even 112 to a degree) I think are easy to remember and get a feel for.
For gold bases you can simply do the same thing as happens now (add 2 to the amount returned) and you will achieve a similar effect:
At 1 worker per patch (10 minerals each worker, 10 minerals per patch), you would harvest 80 minerals in 1 round trip for each worker.
At 2 workers per patch (9 minerals each worker, 18 minerals per patch), you would harvest 144 minerals in 1 round trip for each worker.
At 3 workers per patch (8 minerals each worker, 24 minerals per patch), you would harvest 192 minerals in 1 round trip for each worker.
At 4 workers per patch (7 minerals each worker, 28 minerals per patch), you would harvest 224 minerals in 1 round trip for each worker.
At 5 workers per patch (6 minerals each worker, 30 minerals per patch), you would harvest 240 minerals in 1 round trip for each worker.
Again, the numbers here are fairly intuitive and you can see easily that a 2-worker per patch gold base would equal a 3 worker per patch blue base, and that a 3 worker per patch gold base would be like 3x 1 worker per blue base, AND that a 4 worker per patch gold base is like 2x 2 worker per patch blue base.
In other words, this system is meant to be VERY intuitive despite whatever "complexity" is being added to the AI / mining time, etc. Anyone want to help me develop / test this? I don't have a lot of time to fiddle with the editor these days... ={{{
|
This is the original thread of "Double Harvest" which is actually triple harvest.
With all the discussion lately about eco in LotV I think it is proper that it is brought back to life so people can see the original research.
|
"Double Harvest (3x3)" is now available as a mod in all regions.
Other mods based on this one share the name, but do not include the "(3x3)" which describes the parameters of this particular harvesting method that is described in this thread.
If there are any problems with it, please let me know here or send a PM. I don't have that much experience with SC2 modding and some stupid mistakes may be lurking in...
|
"Double Harvest (3x3)" v 1.1 is now available in all regions.
It fixes the bug that prevents you from shift-queueing another order to a worker that is currently mining.
|
On November 26 2014 04:31 BlackLilium wrote:Show nested quote +On November 25 2014 04:05 RFDaemoniac wrote:
This worker curve does help incentivize taking more bases, but it still punishes you pretty strongly for losing a base. Secondarily we are hoping for a max saturation of much more than 24 workers. I think it punishes you a bit less than either SC2 standard or Starbow. I will however experiment with tripe and quadruple harvest algorithm. Those might actually smooth the curve further, reducing the pain of losing the base. I need to do some experiments though... On the other hand, when testing Double Harvest further, I noticed that it is actually possible to have 2 probes on a single patch in two configurations: sequential and interleaved. The interleaved behavior was expected, but what was not - is that it actually reduces your harvesting efficiency by around 10%. Since SC2 should be about strategy and not correct/incorrect "micro" of your half-saturated base, fixing this is a must, before the idea of DH goes any further. Problem encountered, but I don't surrender. Stay tuned
I think it is a very good point to decrease the maximum income off 2 bases and punish more higher worker setups. So far in LotV it has been working a lot better than expected, income drops very fast and it's not that problematic since players are always against the clock to expand.
So I think Starbow is not as penalizing as it seems. That type of econ opens a lot of space to rework some macroboosters, specially Mules and Larva, and rebalance the early/early midgame (specially for Zerg, that would get a big explosive buff that need to be compensated, and for Protoss, that always had a very poor early)
|
Awesome whisper casting done by catz!
Ty tl, ty to the players, ty catz for tl open!
|
"Double Harvest (3x3)" v 1.2 is now available in all regions.
It fixes the gold mineral bug that was encountered in the recent showmatch between RuFF and Scarlett (https://www.youtube.com/watch?v=EyFpaAonqv8) hosted by Bacon_Infinity. Thank you for reporting it!
Now, the gold mineral patches are mined 3 times, same as normals, but each harvest brings 4 minerals, making it 12 minerals per trip.
|
|
|
|
|
|
EPT
