|
Update 23 Jun 2015
MULEs were overpowered by accident. They were actually mining faster than in Standard model.
This problem has been fixed.
Update 22 Apr 2015
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 below.
Updated 27 Nov 2014
In short:
Try "Double Harvest: Cloud Kingdom", (version 1.2)
Workers do three harvests before returning to drop off the resources.
This allows better base saturation scaling in terms of worker count.
- 8 workers work at 100% efficiency.
- With 16 workers the efficiency already drops to 85%
- 24 workers mine at 69% efficiency.
As a result it is worth taking more bases ealier.
But, at the same time, losing a base when saturated is slightly less punishing.
In long:
The story
It has been suggested by various people that in order to enrich economy, and increased the desired amount of bases being built, the base saturation should gradually decrease the efficiency of mining. In other words, 16 workers in one base should mine slower than 16 workers split evenly in two bases.
Unfortunately, the current setup is not like this: The efficiency of 16 workers is almost as good as 8 workers. And then, as the number grows, there is a rather sharp decrease. The benefit of having a 17th worker is very low, and starting from 24 - none.
I was looking for a way to make this curve more graduate and I realized - with the current AI and mining rules, it's not possible.
Other approaches
Some other approaches, e.g. Starbow, tries to alter the mining curve by changing the AI. By having workers bounce-off one gets additional "variable". The downside is that this makes mining more random, income has higher variance and some odd results sometimes appear. It is also harder to reason about it on paper.
Harvesting phases
Harvesting can be split into three phases:
- H actual harvesting: worker is at the mineral patch and occupies it.
- W waiting: after H, a worker spends an additional moment at the patch, but does not occupy it and other workers can harvest from it
- T transporting: worker making a run towards the drop-off building and back
Double-harvesting
The core idea of double-harvesting is this: let the worker harvest a mineral patch multiple times, before it returns to the drop-off building. As a result, the complete work cycle of a worker consists of multiple H and W phases, followed by a single T.
As a result a mineral field harvested by a single worker has multiple intervals of different length, that could be used by more workers. This different length intervals allow for more interesting scenario and gives more freedom in manipulation the gathering curve.
After doing some math and experimentation we have chosen the following variables:
- Harvest time (H) reduced from 2.786 down to 1.6716
- Wait time (W) increased from 0.5 to 0.8093
- Minerals gathered in a single harvest reduced from 5 to 3
- Worker performs 3 harvests before dropping off the cargo
As a result a full triple-harvest takes 7.4427s + transport time, giving 9 minerals.
Gas minig has not been affected.
Experiments
I have compared three mineral harvesting methods:
- Standard SC2
- Starbow beta v. 1.111 from 24 Nov 2014
- Double Harvest with parameters specified as above
I did not test FRB 8m/4pt mod, as it uses the same mining strategy as Standard, but income is reduced by a factor 4/5.
All tests were performed on Nimbus LE main bases, applying different mods to the map.
Income per minute is as follows:
![[image loading]](http://i.imgur.com/n4Ib6BV.png)
Standard income is slowest at low worker count, but it increases linearly up to 16 workers, and then flattens rather quickly at 24 workers.
Starbow income is the highest at low worker count. However, at 9-11th worker there is a sudden drop in performance, which is then regained a bit in 12-16 range. I was somewhat puzzled by the fact that 13th worker actually contributes more than 11th and 12th. Tested multiple times and got similar results.
At 16+ Starbow flattens even faster than Standard.
Double Harvest at low worker count starts a bit faster than Standard. In 8-16 the efficiency drops by a small factor, falling below the Standard. At 16+ however, the penality is a little bit less severe, and at oversaturated base it reaches the Standard again.
A more interesting question is: how much benefit is there from an expansion. Assuming even split of workers between the bases, here are the results:
Benefit of 2 bases over 1
![[image loading]](http://i.imgur.com/Bm4Nxi3.png)
Even at as few as 10 workers, adding an expo can give noticeable benefits, for both Starbow and DH models. Starbow oscilates around constant 25% benefit, while DH gradually grows from 10% to Starbow's levels.
Standard falls behind a lot. Expo starts to kick in only at above 20 workers.
At higher worker counts (24+), second expo is a must for all models. Double Harvest however grows slower by few %.
Benefit of 3 bases over 2
![[image loading]](http://i.imgur.com/sMXBugi.png)
The decission of taking third base is probably more important. Standard gives no noticeable benefit until you reach around 40 worker count, and then grows very quickly.
Starbow has a strange peak around 25 worker count, caused by the odd behavior around 10-12 worker in single base.
Apart from that, Starbow and DH shows similar benefit of 10-15% when taking 3rd base at 20-40 worker count.
At higher worker counts 3rd is important for all models. Double Harvest however is the lowest - which is good: it penalitizes the loss of such base the least.
Benefit of 4 bases over 3
![[image loading]](http://i.imgur.com/AgtNzyG.png)
This is were Standard fails the most: You don't really need 4th mining base until you are really high on the worker count. In practice, given that some workers mine gas instead, you usually don't have 60 workers mining minerals.
For Starbow and DH, the benefit starts much earlier, giving you additional 5-15% income.
Which is better?
I believe the benefits of Double Harvest and Starbow over the Standard are clear: bases matter more. More expansions, more interesting gameplay.
Comapring Starbow to Double Harvest is less clear. While Starbow is easier to implement, Double Harvest is much more predictable and less random. The DH curves are more linear and puts less emphasis on any particular probe count (16, 24).
DH has also this unique property, that oversaturated bases (24+) still give slight benefit. Double Harvest becomes least punishing when losing a base. It still punishes, no doubt, but those few % of mining efficiency may help you stabilize your game.
Finally, more of an esthetic argument: since the "intelligent" AI is maintained, at 8-16 worker count, you end up having very few or no workers jumping from one mineral patch to another. In Starbow, as by their design, workers jump a lot.
Try it!
Encouraged with the experimental results I wanted to try it in real match.
For that reason I published the modification with the Cloud Kingdom map so that you can test it too.
Search for "Double Harvest: Cloud Kingdom"
How does it affect your gameplay and decision to expand? Is the overall gathering speed right, or should it be tweaked a bit?
... and if you like the idea, spread the word! Maybe it could be implemented into LotV?
Note, this is an experimental modification, and may be buggy. I expect that errors might occur when minerals get depleted.
Thank you for your time!
|
- If the time for Harvest is lower than combined time of 3. 4. 1. then having two workers on one mineral field doubles the efficiency.
- If the time for Harvest is higher than combined time of 3. 4. 1. then assigning yet another worker to that field will not increase efficiency at all.
Like, I can't get past that point. If it is lower than you have to look at the third worker, this is where the curve begins. And if it is higher there still is an efficiency gain, in gained mining time while the first worker returns his minerals the 9th worker can happily start mining, and because the patch is not free when the first one returns he starts to travel to the other ressources, increasing his walk way to a free patch each time you add another worker, hence you get slowly less efficiency by each worker. no?
|
On November 24 2014 01:20 HaRuHi wrote:Show nested quote +- If the time for Harvest is lower than combined time of 3. 4. 1. then having two workers on one mineral field doubles the efficiency.
- If the time for Harvest is higher than combined time of 3. 4. 1. then assigning yet another worker to that field will not increase efficiency at all.
Like, I can't get past that point. If it is lower than you have to look at the third worker, this is where the curve begins. And if it is higher there still is an efficiency gain, in gained mining time while the first worker returns his minerals the 9th worker can happily start mining, and because the patch is not free when the first one returns he starts to travel to the other ressources, increasing his walk way to a free patch each time you add another worker, hence you get slowly less efficiency by each worker. no?
That's the point:
- If it is lower, the curve *begins* at the 3rd worker. The first two work at the full efficiency and there is no benefit of splitting them up to a new expansion.
- If it is higher, the 2nd worker will increase your mining capacity at reduced benefit (splitting it into new expo would help), but in that scenario, 3rd worker doesn't help at all. Those 2 workers saturate the mineral field completely.
What I aim however, is such a curve, that begins to diminish early a bit (when you add 2nd worker), but when it is still worth adding 3rd line of workers.
|
Thanks for clearing things up, It really is surprising that the higher time does not generate the desired curve automatically, probably because the ai is optimized for the standart time in some dirty way.
Since your solution seem unelegant at best, have you looked how starbow has solved this? Feels more natural to me, though I don't know how they achieved it exactly, you probably can ask them in their thread here.
|
Thank you for bringing Starbow into the discussion.
The numbers cannot be directly compared because Starbow standard is 9 minerals, I assume no change from SC II - which is 8. However, for the sake of comparison (not balance!), I removed one mineral field and did the same testing. Here are the results:
No. of probes | Time for 1000 | Performance | Efficiency | New worker efficiency
8 | 154s | 0.81 | 1 | -
12 | 126s | 0.66 | 0.815 | 0.444
16 | 99s | 0.63 | 0.778 | 0.667
20 | 92s | 0.54 | 0.670 | 0.238
24 | 88s | 0.47 | 0.583 | 0.152
Starbow seem to nudge the AI of workers a bit, otherwise it is just change of gathering time and harvest amount per trip. As a result at probe count 0-8 it is supper efficient, probes 8-16 drop in efficiency drastically down to 50% and 16+ is very low (~20%). This behaves similarly to my mid example of increased mining time (Starbow seems to be more extreme with it).
Having 9 mineral patches allows to stretch the saturation a bit, but the sudden fallof at 2*N (N being the number of mineral patches) is still there.
Is their solution more elegant? I think it is a matter of taste. It's definetely simpler. But in my personal opinion nudging AI to do weird stuff is not necessarily a right night to do; and the scaling results are not that good.
|
I'm starting to read the thread, but this is untrue:
The numbers cannot be directly compared because Starbow standard is 9 minerals,
The number of minerals is not standardized on starbow, there are maps that have 9 minerals in the main as well as maps that have 8, it is up the mapmaker to define the mineral count in the bases.
|
|
|
On November 25 2014 00:25 Laertes wrote:
I'm glad other people are testing this. If you really want to test this against the Starbow solution you could host an independent Starbow tournament with a cash prize using Starbow but this economy. See how it works, yknow?
But considering it is intended as an experiment for SC2, why not host a SC2 tournament with a cash prize instead of a Starbow one?
|
On November 25 2014 00:25 Laertes wrote:
I'm glad other people are testing this. If you really want to test this against the Starbow solution you could host an independent Starbow tournament with a cash prize using Starbow but this economy. See how it works, yknow?
Hm, interesting... but I think it is a bit too early for cash prized tournament.
I have just presented the idea of double-harvesting two days ago, almost no one knows about it.
Some further balancing is needed, and - more importantly - a decision if all this is actually worth it, or should the idea be scrapped.
Finally, I never organized any SC2 tournament (prized or not). If it would come to that I would definitely need a hand.
Regarding balance, from my own experience, it might be worth considering buffing mining a bit. Current mineral-to-gas ratio maps to the standard SC2 only at the low saturation (up to 8 workers) and then - as the mineral curve drops a bit - gas begins to get easier a bit.
But I am a poor player myself, need more experienced testers 
|
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 did a bit of testing and it seems somewhat similar to SC2, only difference is that it smooths out the transition from 8-16 workers to 16+ workers, then kinda caps resource generation at 20+ workers onwards. I would think the cap would reward the player with more bases and not so much workers.
Still, I think it's an idea worth testing in real games. I never truly trust theorycrafting.
|
On November 25 2014 04:17 Laertes wrote:Show nested quote +On November 25 2014 00:39 OtherWorld wrote:On November 25 2014 00:25 Laertes wrote:
I'm glad other people are testing this. If you really want to test this against the Starbow solution you could host an independent Starbow tournament with a cash prize using Starbow but this economy. See how it works, yknow? But considering it is intended as an experiment for SC2, why not host a SC2 tournament with a cash prize instead of a Starbow one? The argument was whether Starbow's economy solution is more elegant than this mod. One side thinks Starbow is better, one side thinks this is better. SC2 doesn't even factor into the debate and I don't see why it should be inserted. I mean no disrespect to SC2, it's a great game, but this is a test to see which economy solution works more efficiently. The only reason I said cash prize is because I was gonna put the money up for it.
Well but with a Starbow tournament we would see Starbow units and metagame, as well as the effect of this mod on Starbow, while the OP's idea is about how it would affect SC2. While comparing SC2 with SB's econ and SC2 with this mod would be in my opinion a very good idea, I don't see why Starbow as a game (as a whole game ; inserting SB's economy in the argument is very interesting) should be inserted.
Sorry if I did come out as rude though, didn't want to.
|
|
|
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
|
The reason increasing harvest time does not produce much of an effect, is because of the following intelligent queuing condition which was introduced for worker AI in Starcraft 2:
http://zippy.gfycat.com/OptimisticSomeAmericanbobtail.mp4
When all mineral nodes have a harvester count of at least 1, an intelligent queueing condition kicks in which prevents harvesters from bouncing off of occupied patches as easily. The queuing condition works as follows:
Imagine a worker arrives to an occupied node such as in the video example above. All mineral nodes in the vicinity have a harvester count of at least 1.
IF the currently mining worker who occupies the node has less than 2 seconds remaining before it finishes mining THEN the arriving worker will queue politely at the node.
This condition, however, does not apply as long as there is at least one node with a harvester count of 0 in the vicinity, in which case the harvesters will always bounce upon arriving to an occupied mineral node:
http://zippy.gfycat.com/UnfoldedFrenchFruitfly.mp4
Starbow works through bypassing the intelligent queuing condition with the help of triggers. In Starbow workers will always bounce as long as all mineral nodes in the vicinity are not presently occupied.
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.
|
|
|
On November 26 2014 09:37 LaLuSh wrote:The reason increasing harvest time does not produce much of an effect, is because of the following intelligent queuing condition which was introduced for worker AI in Starcraft 2: http://zippy.gfycat.com/OptimisticSomeAmericanbobtail.mp4Show nested quote +When all mineral nodes have a harvester count of at least 1, an intelligent queueing condition kicks in which prevents harvesters from bouncing off of occupied patches as easily. The queuing condition works as follows:
Imagine a worker arrives to an occupied node such as in the video example above. All mineral nodes in the vicinity have a harvester count of at least 1.
IF the currently mining worker who occupies the node has less than 2 seconds remaining before it finishes mining THEN the arriving worker will queue politely at the node. This condition, however, does not apply as long as there is at least one node with a harvester count of 0 in the vicinity, in which case the harvesters will always bounce upon arriving to an occupied mineral node: http://zippy.gfycat.com/UnfoldedFrenchFruitfly.mp4Starbow works through bypassing the intelligent queuing condition with the help of triggers. In Starbow workers will always bounce as long as all mineral nodes in the vicinity are not presently occupied. 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.
Thanks for the pointer to how exactly the AI works.
I actually like this "intelligent queueing" because it is more predictable what happens. When experimenting with my idea, I am actually doing some math on paper assuming a single mineral node, and it projects quite well into the game for an multi-node base.
On the other hand, workers jumping to different node gives a bit of randomness, but it cannot be really controlled by the designer.
Blizzard might not want to forgo this AI behavior for the same reason.
|
As long as there is a whole thread dedicated to this type of topic, I'm going to suggest the same idea that I usually do in threads like these. Set the standard mineral collection quantity at 6 and 8 (for normal and high yield, respectively), and then institute a mechanic where the mineral patch switches to a "recently harvested" state for just under the amount of time that a worker takes to travel to the patch, mine it, and return to the town hall structure. During this time, the patches confer 4 and 6 (for normal and high yield) each time they are mined. This causes a pretty hard shift where 8 workers mine at 120% efficiency, 12 workers mine at ~106% efficiency, 16 mine at 100% efficiency, and 24 mine at 73% efficiency. The large fall at 3 is because it doesn't give any mineral patches the time to "recharge" to a fresh state.
The benefit of this is that no AI changes to the workers or time changes to the mining need to occur, which is easy for new players to understand, and experienced players to predict during attacks on mineral lines. It would also slightly speed up the early game.
The problem with this is that it's still not as easy as the current system for new players to understand, and I'm not entirely sure how to implement it in the map editor anyway.
|
Nice idea Pontius Pirate. Try to implement it and I will be happy to test it!
You could set up a set of triggers:
- when harvesting finishes, you set a "just harvested" flag on it
- after short delay you remove the "just harvested" flag (could be in the very same trigger as above)
- when harvesting starts, you check if a "just harvested" flag is on. Depending on the count you set the amount of carried minerals.
The only problem I see, is that the amount of minerals in the field would decrease at a constant rate. But you could try to change that too (not sure how atm)
Go on, launch your editor and experiment! I will be happy to test it and compare!
|
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.
|
On June 08 2015 22:34 BlackLilium wrote:
"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.
Ah, so the benefit of gold bases is marginally decreased in this mod. 1.33x normal 6-patch income vs 1.4x normal 6-patch income. In fact, 6 or 12 workers on gold base would therefore give no more income than 8 or 16 workers, respectively, on a normal blue patch base, considering the difference in number of patches.
|
Interesting observation. Frankly I didn't pay too much attention to incomes from gold bases, because they are rare.
The direct benefit of a gold base is that you need less workers for the game gain.
If the game was like that from the start, we could probably see more gold bases overall, without putting mineral:gas ratio off-balance.
I could boost gold minerals to be 3x5m instead of 3x4m, but I fear that it could be too much! (+50% income on each worker)
|
I really like gold bases as a mechanic, but if they were made that freaking good, it would probably be a destabilizing, if not overcentralizing, element. With a slightly weakening of the mechanic, they could probably be used a bit more liberally by mapmakers. If they mined 2x4 and then 1x5, making them 1.44 and therefore slightly closer to the default 1.4, they'd probably still be cool on a few specific maps that are based around a critical gold base, such as Habitation Station, but potentially could cause issues on some other maps, such as Overgrowth.
If this were implemented, mapmakers might even be at liberty to attempt 8 patch gold bases. But it would be hard to say if that would actually improve anything.
|
Bug fix
Apparently the MULE mining rate is defined as a multiplication of worker mining rate, rather than a concrete value in second (Blizzard, why do you set stuff in such convoluted way?)
Since the mining time of a single harvest has been reduced in this mod (2.786 down to 1.857), MULEs were mining at a faster rate and retuning more minerals. As a result Terrans were accidentally buffed.
Before the bug fix the MULE could harvest within its lifetime:
- 360 minerals on near mineral patch
- 330 minerals on far mineral patch
The bug fix includes:
- Harvest time multiplication: 2.05 -> 3
- Minerals mined by MULE in a single harvest: 30 -> 27
MULEs continue to make a single harvest and return. Applying multiple harvests is pointless since MULEs bypass the queue at the mineral patch anyway......
With the change, the MULE can now harvest:
- 270 minerals on near mineral patch
- 243 minerals on far mineral patch
...which is much closer to the original. In fact, it is a tiny bit lower - to balance with the lower efficiency of a fully saturated base.
|
On June 23 2015 18:34 BlackLilium wrote:
Bug fix
Apparently the MULE mining rate is defined as a multiplication of worker mining rate, rather than a concrete value in second (Blizzard, why do you set stuff in such convoluted way?)
 Good job!
|
|
|
|
|
|
EPT
