|
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!
|
|
|
|
|
|
EPT
