|
|
Canada13378 Posts
On April 23 2015 09:03 Barrin wrote:So there's what I would call a problem with triple harvest that I suspected from my experience doing the double harvest tests, and just confirmed in-game. Basically, when you have 2 workers on a patch, they will take turns harvesting. In triple harvest, the following situation is literally how the game is coded when there are more workers than patches: - Worker A starts mining a patch.
- Worker B arrives at the patch.
- Worker A finishes his first harvest.
- Worker B starts mining the patch.
- Worker B finishes his first harvest.
- Worker A starts mining the patch again.
- Worker A finishes his second harvest.
- Worker B starts mining the patch again.
- Worker B finishes his second harvest.
- Worker A starts mining the patch again.
- Worker A finishes his third harvest and heads back.
- Worker B starts mining the patch again.
- Worker B finishes his third harvest and heads back.
I'm not entirely sure, but I do suspect that 3 on a patch will cycle as well (ABCABCABC). I think this is a problem because the workers stand on top of each other a lot more often and are therefore too susceptible to AoE attacks.
They already stand on top of eachother a lot pre 16 and they appear in my testing to be bouncing similar to hots i think in the 17-24 ratio for now?
Ill watch more to keep that in mind though.
And yeah simply lengthening the amount of time mining isn't actually enough to do anything meaningful to the pairing issue and really makes pulling harsh on low worker counts.
DH9 curve might be better? Not sure, still collecting data we will see. DH8 is however too shallow a curve compared to HotS too soon raising the value of gas to be a lot higher so you would need to reduce gas incomes and we don't necessarily want to tweak that variable. We just want a mining model that allows the CONCEPT that we want to show in games as working. However Blizz translates the diminishing returns starting on the 9th worker that is up to them.
I think our messaging has become cluttered with regards to the goal of our mod and approach.
|
|
On April 23 2015 09:36 Barrin wrote:Show nested quote +On April 23 2015 09:17 EatThePath wrote:On April 23 2015 09:01 Big J wrote:On April 23 2015 08:18 ZeromuS wrote:On April 23 2015 08:14 Penev wrote:On April 23 2015 08:09 ZeromuS wrote:I think I got too caught up in the destiny trap of emotional circle roundabouts. also we've been bothering nathanias a lot and I think he's just tired of hearing about it XD And its fair for someone to be critical nothing wrong with that. I'm glad I had jakatak to help me out and once I went back to the core concerns of worker pairing and overall income I felt like it went a lot better. Also we want to be in the middle of the LotV road and the HotS road. In response to the overall higher income of DH we agree that looking at more info and replays it might be too high. Thats okay, we admit this. I am looking into how to implement DH9 which should be closer to what we want Fair enough. I asked in one of the other threads: I take it DH9 is 4+5 mins/ trip? (or 5+4?) Can't do 4 and 5 so need to find some way to make 3 trips of 3 work but not in the time that blacklilliums did it (that was too long a mining cycle i think). Can't you just up the mining time? Like 10%slower mining time. This? Someone said that a mining time long enough to break worker pairing makes them spend so long at the patch that harassing the workers becomes too effective. I personally would love to see more harassment with initial scouts, but there might be a point here when it comes to trying to defend a 6pool or proxy 2gate for example. Yeah it's a good thing to note. But a 10% increase (really 5% in two chunks for DH) seems like a negligible change in disruptability. Maybe 20% would begin to be too much.
Also you could make it 8 per trip (4 + 4) at a 10% faster mining rate, giving an overall rate of ~89% of DH10 (very close to DH9).
https://docs.google.com/spreadsheets/d/1qfnd_Ydfqj8qY9-RiZcn9j0EL_puoNF0vKnTJ859pdg/edit?usp=sharing
Barrin, this is a link to a spreadsheet I was working on that visually blocks out mining cycles in a DH system using altered mining phase times. (Sheet 2.) The multiple worker part might interest you.
|
Canada13378 Posts
On April 23 2015 10:09 EatThePath wrote:Show nested quote +On April 23 2015 09:36 Barrin wrote:On April 23 2015 09:17 EatThePath wrote:On April 23 2015 09:01 Big J wrote:On April 23 2015 08:18 ZeromuS wrote:On April 23 2015 08:14 Penev wrote:On April 23 2015 08:09 ZeromuS wrote:I think I got too caught up in the destiny trap of emotional circle roundabouts. also we've been bothering nathanias a lot and I think he's just tired of hearing about it XD And its fair for someone to be critical nothing wrong with that. I'm glad I had jakatak to help me out and once I went back to the core concerns of worker pairing and overall income I felt like it went a lot better. Also we want to be in the middle of the LotV road and the HotS road. In response to the overall higher income of DH we agree that looking at more info and replays it might be too high. Thats okay, we admit this. I am looking into how to implement DH9 which should be closer to what we want Fair enough. I asked in one of the other threads: I take it DH9 is 4+5 mins/ trip? (or 5+4?) Can't do 4 and 5 so need to find some way to make 3 trips of 3 work but not in the time that blacklilliums did it (that was too long a mining cycle i think). Can't you just up the mining time? Like 10%slower mining time. This? Someone said that a mining time long enough to break worker pairing makes them spend so long at the patch that harassing the workers becomes too effective. I personally would love to see more harassment with initial scouts, but there might be a point here when it comes to trying to defend a 6pool or proxy 2gate for example. Yeah it's a good thing to note. But a 10% increase (really 5% in two chunks for DH) seems like a negligible change in disruptability. Maybe 20% would begin to be too much. Also you could make it 8 per trip (4 + 4) at a 10% faster mining rate, giving an overall rate of ~89% of DH10 (very close to DH9). https://docs.google.com/spreadsheets/d/1qfnd_Ydfqj8qY9-RiZcn9j0EL_puoNF0vKnTJ859pdg/edit?usp=sharingBarrin, this is a link to a spreadsheet I was working on that visually blocks out mining cycles in a DH system using altered mining phase times. (Sheet 2.) The multiple worker part might interest you.
Hmm are you factoring in the wait times into your second sheet? because those impact the way the AI works to pair as well as the time it takes to mine.
Thats something to consider as well.
Simply making them mine quicker and doing two 4+4 trips to approximate DH9 is an interesting solution, but at its core as long as we approximate a curve of DH9 from barrin's other graph that might be ok?
We need more in game tested graphs
|
|
Based on this thread, people should have a better appreciation for David Kim. Balancing a video game isn't easy. My guess is they've already tested all of this type stuff at one point or another over the last 5+ years, and there's a good reason they're sticking to what they have with minor tweaks.
That said, I'm all for trying out these changes, but ultimately I think they've already tried and dismissed it.
|
On April 23 2015 10:53 vesicular wrote: Based on this thread, people should have a better appreciation for David Kim. Balancing a video game isn't easy. My guess is they've already tested all of this type stuff at one point or another over the last 5+ years, and there's a good reason they're sticking to what they have with minor tweaks.
That said, I'm all for trying out these changes, but ultimately I think they've already tried and dismissed it.
I don't recall many people saying otherwise. I just really dislike the design. At least they're trying different things lol. I wouldn't agree with the last part about good reason why they're sticking to what they have with minor tweaks. It could very well as come as stubbornness. No this is the way we want people to try and play.
|
If DH9 is problematic to implement, what about trying DH8 but with more starting workers?
That might compensate for what would otherwise be a slower start to the game, while reducing the overall economic pace. Seems to me that could broaden the windows for making things happen with your units.
|
On April 23 2015 11:05 StarStruck wrote:Show nested quote +On April 23 2015 10:53 vesicular wrote: Based on this thread, people should have a better appreciation for David Kim. Balancing a video game isn't easy. My guess is they've already tested all of this type stuff at one point or another over the last 5+ years, and there's a good reason they're sticking to what they have with minor tweaks.
That said, I'm all for trying out these changes, but ultimately I think they've already tried and dismissed it. I don't recall many people saying otherwise. I just really dislike the design. At least they're trying different things lol. I wouldn't agree with the last part about good reason why they're sticking to what they have with minor tweaks. It could very well as come as stubbornness. No this is the way we want people to try and play.
Could be they have a design philosophy for SC2 and that's what they want to stick with. But in my experience it's rare for someone outside of a dev team to come up with ideas the team has never considered or already went back and forth on or tried and tested. This is after all their job.
Whatever their reasoning for not trying it out publicly (stubbornness or no), I doubt this is the first time they've considered such an approach. The fact that they haven't changed it in years past (or launched WoL with it) should speak volumes.
Also, this isn't me agreeing with the current design. I've always thought it was rubbish. I much prefer the BW econ design. But I've developed enough software over the last 20 years to have seen this kind of stuff happen before.
|
|
Canada13378 Posts
On April 23 2015 11:28 Barrin wrote:Show nested quote +On April 23 2015 11:10 Umpteen wrote: If DH9 is problematic to implement, what about trying DH8 but with more starting workers?
That might compensate for what would otherwise be a slower start to the game, while reducing the overall economic pace. Seems to me that could broaden the windows for making things happen with your units. Indeed.
Its not just about the starting workers, its about an overall issue where DH8 is just flatout a lot lower income than HotS and HotS gas as a ratio is balanced alongside other unit counts and we don't want to drop the income too hard for that.
Also barrin love your map <3
|
On April 23 2015 10:53 vesicular wrote: Based on this thread, people should have a better appreciation for David Kim. Balancing a video game isn't easy. My guess is they've already tested all of this type stuff at one point or another over the last 5+ years, and there's a good reason they're sticking to what they have with minor tweaks.
That said, I'm all for trying out these changes, but ultimately I think they've already tried and dismissed it. I'm don't mean to shit on blizzard or DK, I just don't think it is that hard to be honest + Show Spoiler +(it is definitely a lot of work; but I think it has more to do with grinding out a lot of games in the most imbalanced alpha stages, polishing, doing larger scale alpha and beta tests and then Nash-equilibria in form of standard builds will eventually present themselves; from there you just have tweak the builds until they have equal winchances) , neither do I think they have tested these sorts of systems thoroughly. They don't have the manpower to internally do larger scale tests. I think the way their closed alpha tests work is that they give the game to basically everyone in the company and they get to play the game in their worktime. That way they can get a good amount of games and data in. But they can't do this for economy tests and stuff like that. At best, they can do the theorywork and a little bit of in-team testing and theorycraft about it.
I much rather think that the way they decided upon SC2 economy was that they found worker pairing visually pleasing - and calibrated all mining values in ways to achive that with the given worker speed of broodwar - and values of 5 instead of the broodwar 8 easier to read with all costs being multipliers of 25. Because they mined less it led to a situation in which each base needed a little more workers than they did in broodwar. And worker pairing moved the scaling back from 8 to 16.
But all of that did not matter in WoL alpha gameplay. It simply wasn't figured out that 60to80workers with 120to140 army supply was "the optimum". That only really occured with gameplay being figured out. And after the maps got changed and the players got good at macroing. I'm pretty much certain that the developers at that time imagined the game to be centered around 1-2base plays. Just look at the maps. You won't ever have the issue of maxing too fast or wanting to have 80workers on Steppes of War or Blistering Sands. Also, they explicitely put in a feature that would still allow players with mapcontrol to mine more than the other player: gold bases. That was their idea of punishing a overly defensive player economically, and quite frankly, it isn't a bad one, because it does exactly what DH10 tries to achieve. More income for less workers. Like, if there was a way to make every base past the first 2-3 a gold base without making it abuseable (blizzard's idea to put rocks onto those bases to ensure only a player with mapcontrol and an army can take them), it would actually be quite a nice solution too in my opinion. But I don't think this is possible.
To come back to my original point, I don't think they have tested this form of scaling economy. However, I do think they have tested other forms of economy that rewards a faster expanding player, like gold base maps. And I think they came to the conclusion that it breaks the game, hence, DKs comment that he thinks it rewards expanding too much. I think out of fear that the DH10 model gets dismissed to easily, this topic doesn't get to be touched too deeply upon, but DH10 breaks the balance. DH10 might only be feasable with a nerfhammer to some (zerg) units or racial mechanics (inject). And I'm afraid, blizzard isn't willing to go back into WoL-alpha like tests with each and every unit in the game, but rather just want to release more content for starcraft and go with their economy model. Which - from their perspective - is quite a brilliant model. If one thinks about it, what was the initial development that led to 3base plays? Bigger maps! The community and professional pressure to play on bigger maps, because the smaller ones ended up too broken for the game to be fixed for their style of play. By making bases mine out faster, blizzard is trying to bring the game back to its Steppes of War roots and original design intentions - low economy games - while surpassing the issue of too small rush distances.
|
Just want to express my immense gratitude to Zeromus, Plexa, and the other people of the TL team that have constructed this solution.
While exact numbers may need to be hashed out, this illustrates the core issue with the economy since sc2 came out. Additional workers' lack of diminishing returns and the resulting linear growth of income on 1 base has stagnated strategic options for too long. The lack of strategic depth that arises from this issue is in my opinion has contributed immensely to the lack of growth of starcraft in recent years.
|
On April 23 2015 06:37 Plexa wrote:Show nested quote +On April 23 2015 06:04 fancyClown wrote:On April 23 2015 05:40 Plexa wrote:On April 23 2015 05:33 fancyClown wrote:On April 23 2015 05:25 SC2John wrote:On April 23 2015 05:21 fancyClown wrote:On April 23 2015 04:52 Plexa wrote:On April 23 2015 04:47 fancyClown wrote: If you want Blizzard to abandon their current economy model for LotV, you need to clearly show what effect DH10 has on the available money vs. LotV.
The only meaningful way to do that is to plot minerals earned as a function of time for both DH10 and LotV. This allows you to see when the first base gets mined out in both models. Anything else is just baseless conjecture. LotV and HotS have the same curves as in the OP. The difference is that half the patches run out sooner than the other half. That's not really something we can easily model since the timing on when those patches are depleted varies considerably depending on when the expansion was taken. Our preference is for a DH model with reduced minerals per patch (say 1350) as opposed to non-uniform mineral distributions. The curves of LotV and HotS are the same, but the big difference is the initial worker count. This makes it really hard to compare the 3 models in terms of actual effect on money earned over time. All you need to model is one base that produces workers until saturation. When saturated, worker production stops and no further expansions are taken. You are just modeling this one base and then ask: At which point is this base mined out? How does income increase over time? How does this compare between LotV and DH10? This is the only thing you are really interested in to get the point across. The difference is that you don't lose 50% of your income at 50% of HotS mineout time (~7:00) -_- At 16 workers, DH10 and HotS have almost the same efficiency and income. Literally the only difference in graphs would be that at 7:00, LotV economy would chunk off like a step function. We are talking about plotting minerals earned as a function of time, not as a function of worker count. Since DH10 and LotV start with different worker counts, the graphs would most certainly look different. DH10 =/= 12 worker start. The number of workers you start with is irrelevant, and in LotV we'd expect initial tests with DH10 to be done with 12 workers. SC2john is right when he says income/time for a normal game in lotv would look identical to hots except when you mine out the 4 patches (~7:00) when the graph jumps down rapidly (step function behavior). EDIT: our comparison to HotS is for two reasons 1) People generally have greater access to HotS and we can put extension mods online there 2) The efficiency curves for HotS and LotV are identical assuming equal number of nodes available If you would start HotS with 12 workers and compare it to HotS started with 6 workers you are saying that both mine out their base at the same time? Intuitively that doesn't make a lot of sense. After 1 min, your money earned from 12-worker-start HotS would be higher than from 6-worker-start HotS. As a result, the 12-worker-start HotS base would be mined out faster. And that is what I mean by saying that plotting only the worker count doesn't reflect the differences between the models. The graphs in the OP assume you have a fixed worker count and then calculate the income/minute you receive from having that fixed worker counter. We're not making any claims about bases running out faster. Show nested quote +On April 23 2015 05:54 FabledIntegral wrote:On April 23 2015 05:09 EatThePath wrote:On April 23 2015 04:59 rigginssc2 wrote:On April 23 2015 04:12 velvex wrote: Yet, with your use of the word "optimal", you're suggesting that people choose their worker count in order to maximise (= optimise) worker efficiency, which is not very realistic. I think is pretty realistic. When you are playing currently you always want to saturate your base before expanding to another. You always want to make sure your bases are saturated. This is not unrealistic at all, this is just common knowledge and how you play the game. You over-saturate (go over 16) as you are expanding and then move workers to the new base. (saturate meaning 16 mining workers per base) On April 23 2015 04:13 BlackLilium wrote: You will still double the income on 4 bases with 32 workers, compared to 2 bases with 16 workers, regardless if Standard or DH 2x5. That is rather pointless comparison, since you simply have doubled everything (workers and bases).
First, in Hots/Lotv you wouldn't need 4 bases if you had 32 workers. You would stop at 2. And that would not be double the income from 16-32 in standard it would be identical income. That is the whole point of the 2:1 argument in this article. The point is, in DH10 you actually can get 4 bases saturated (4x8=32), but in Hots/Lotv you cannot (4x16=64). The premise here is that if you were trying to power out economy or tech. A player in the Hots/Lotv version would not get the economy advantage that a player in DH10 would IF he tried to fast expand to 4 bases over the 2 base player. He simply could not get an efficiency advantage until he got over 48 workers (3x16). That's a lot and in Hots that would take a terran nearly 10 minutes to accomplish. On April 23 2015 04:13 BlackLilium wrote: Why 16 is considered a saturated base? Is it because worker efficiency drops? Defining "saturation" as a point when workers start losing maximum efficiency is misleading.
I am not defining it to be anything. I am simply saying that the word "saturation" is already used to mean one thing -- 16 workers on a base -- so "defining it" to mean something else in this article/thread is confusing. I would imagine David simply used the word "saturation" in the normal SC2 way, which is understandable since his job/life is SC2, and it shouldn't be taken as his necessarily misunderstanding the original article. Personally, I think a few of the terms are a bit loose in this thread (like "optimal" as I mentioned), but the most important thing is just everyone being on the same page. Saturation is already a well-understood term meaning "adding workers to the patch achieves no income gain". AKA "The patch is saturated." Which you can extend to a base being saturated meaning all its patches are saturated. Saturation itself has nothing to do with efficiency but they often get conflated in discussions about mining and economy. I would disagree with this statement. I would say that "common usage," regardless of whether or not it's actually correct, is to use 16 workers on minerals to be saturated, not 24. I actually struggled with the articles notably as a result as well as a result - I understood the article established what the definition was going to be (and it's fairly accurate at that), but it's not how I have ever seen it used in the game itself. Nearly any caster will also use "saturated" base as 16 workers in tournament games, which further reinforces it's colloquial usage being 16 instead of 24. Yeah, hence why I made is exceptionally clear in the OP by what I meant by "saturation point". We need words to describe the concepts we mean, and saturation literally means "cannot hold anymore" (eg. saturated sponge) so it seems very appropriate to use that term to describe a mineral line which cannot hold anymore workers. That said, being careful with language in these articles is paramount.
I acknowledge you made it exceptionally clear the definition, don't think I ever denied that. Doesn't mean it's not still confusing to constantly have to tell yourself to use the definition as opposed to the term you've become associated with.
|
On April 23 2015 11:50 Big J wrote: Also, they explicitely put in a feature that would still allow players with mapcontrol to mine more than the other player: gold bases. That was their idea of punishing a overly defensive player economically, and quite frankly, it isn't a bad one, because it does exactly what DH10 tries to achieve. More income for less workers. Like, if there was a way to make every base past the first 2-3 a gold base without making it abuseable (blizzard's idea to put rocks onto those bases to ensure only a player with mapcontrol and an army can take them), it would actually be quite a nice solution too in my opinion. But I don't think this is possible. There's distance gold patches, but that never caught on, because innovation is forbidden in SC2 mapping:
"Lalush" 4th base I am coining a term here, in reference to an old thread analyzing SC2 macro which concluded that it was pointless to have more than three bases in SC2. Zergs and protoss get more bases for the gas, but we don't see the same incentive as in BW to get more and more expansions for better mining by distributing workers.
This base changes that.
Because it is a gold base, it gives you better mining income per worker. But only 3 of the mineral patches are at a normal distance. The other 3 are at a distance of 5 or 6 squares. This means that only 6 workers will give you a substantial economic boost, even if you pull them from elsewhere instead of add them. But to engage the full mining rate, you need more workers than normal to saturate the distant patches. You need at least 3 workers for each, so an "optimal" saturation is 15 workers, as opposed to the 12 normally needed at a gold base (compared to 16 on a standard base). This means the mineral income possible is nearly standard, and so is the number of workers required to achieve it. The gases are normal.
So you are rewarded for expanding before you "have to", but the base functions as a normal base if it has to.
A small point is that it also discourages mule spam by having distant patches.
It pretty much does everything you want in terms of expansion incentive, and you don't have to change anything about the worker behavior. But, eh, Blizzard MUST have thought of it and found 14 good reasons not to use it, right?
On April 23 2015 10:16 ZeromuS wrote:Show nested quote +On April 23 2015 10:09 EatThePath wrote:On April 23 2015 09:36 Barrin wrote:On April 23 2015 09:17 EatThePath wrote:On April 23 2015 09:01 Big J wrote:On April 23 2015 08:18 ZeromuS wrote:On April 23 2015 08:14 Penev wrote:On April 23 2015 08:09 ZeromuS wrote:I think I got too caught up in the destiny trap of emotional circle roundabouts. also we've been bothering nathanias a lot and I think he's just tired of hearing about it XD And its fair for someone to be critical nothing wrong with that. I'm glad I had jakatak to help me out and once I went back to the core concerns of worker pairing and overall income I felt like it went a lot better. Also we want to be in the middle of the LotV road and the HotS road. In response to the overall higher income of DH we agree that looking at more info and replays it might be too high. Thats okay, we admit this. I am looking into how to implement DH9 which should be closer to what we want Fair enough. I asked in one of the other threads: I take it DH9 is 4+5 mins/ trip? (or 5+4?) Can't do 4 and 5 so need to find some way to make 3 trips of 3 work but not in the time that blacklilliums did it (that was too long a mining cycle i think). Can't you just up the mining time? Like 10%slower mining time. This? Someone said that a mining time long enough to break worker pairing makes them spend so long at the patch that harassing the workers becomes too effective. I personally would love to see more harassment with initial scouts, but there might be a point here when it comes to trying to defend a 6pool or proxy 2gate for example. Yeah it's a good thing to note. But a 10% increase (really 5% in two chunks for DH) seems like a negligible change in disruptability. Maybe 20% would begin to be too much. Also you could make it 8 per trip (4 + 4) at a 10% faster mining rate, giving an overall rate of ~89% of DH10 (very close to DH9). https://docs.google.com/spreadsheets/d/1qfnd_Ydfqj8qY9-RiZcn9j0EL_puoNF0vKnTJ859pdg/edit?usp=sharingBarrin, this is a link to a spreadsheet I was working on that visually blocks out mining cycles in a DH system using altered mining phase times. (Sheet 2.) The multiple worker part might interest you. Hmm are you factoring in the wait times into your second sheet? because those impact the way the AI works to pair as well as the time it takes to mine. Thats something to consider as well. Simply making them mine quicker and doing two 4+4 trips to approximate DH9 is an interesting solution, but at its core as long as we approximate a curve of DH9 from barrin's other graph that might be ok? We need more in game tested graphs That sheet was just illustrating worker cycling based on information from blacklilium's original thread that ended up with a triple harvest system. I was trying to determine if multiple workers always end up in a repeating periodic pattern, which it seems they do (if we assume they never bounce due to oversaturation). The "recovery" phase was assumed to behave as stated in the thread where a worker sits doing nothing for a given period, but other workers can mine. The order of which worker is mining next is determined by a simple queue of who got there first as I've observed it to work in game. I didn't test each of those setups in game however.
|
On April 23 2015 08:18 ZeromuS wrote: Can't do 4 and 5 so need to find some way to make 3 trips of 3 work but not in the time that blacklilliums did it (that was too long a mining cycle i think).
For reference:
DH 2x5: Mining time: 2.786s Return delay: 0.5s Full cycle: 6.572s + travel time
DH 3x3 Mining time: 1.6716s Return delay: 0.8093s Full cycle: 7.4427s + travel time
Agreed that DH 3x3 is a bit longer, but the difference is that that big as you think. Ultimately, how much you return and how long the cycle is, is tightly coupled together when you want to have the same overall income. Reduce the cycle time without harvest amount, and your income will be too high.
The mining and return numbers are not random. They were selected to ensure that ABAB, and AABB mining patterns yield the same income. Originally taken from http://www.teamliquid.net/forum/sc2-maps/471776-mod-double-harvesting-better-saturation-curve?page=2#24 I quote here becase I think it is important for the model
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. 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.
If you play with the numbers of DH 3x3, please make sure you don't fall into the same trap I did, where reorganizing workers gave different results.
|
On April 23 2015 06:37 Plexa wrote:Show nested quote +On April 23 2015 06:04 fancyClown wrote:On April 23 2015 05:40 Plexa wrote:On April 23 2015 05:33 fancyClown wrote:On April 23 2015 05:25 SC2John wrote:On April 23 2015 05:21 fancyClown wrote:On April 23 2015 04:52 Plexa wrote:On April 23 2015 04:47 fancyClown wrote: If you want Blizzard to abandon their current economy model for LotV, you need to clearly show what effect DH10 has on the available money vs. LotV.
The only meaningful way to do that is to plot minerals earned as a function of time for both DH10 and LotV. This allows you to see when the first base gets mined out in both models. Anything else is just baseless conjecture. LotV and HotS have the same curves as in the OP. The difference is that half the patches run out sooner than the other half. That's not really something we can easily model since the timing on when those patches are depleted varies considerably depending on when the expansion was taken. Our preference is for a DH model with reduced minerals per patch (say 1350) as opposed to non-uniform mineral distributions. The curves of LotV and HotS are the same, but the big difference is the initial worker count. This makes it really hard to compare the 3 models in terms of actual effect on money earned over time. All you need to model is one base that produces workers until saturation. When saturated, worker production stops and no further expansions are taken. You are just modeling this one base and then ask: At which point is this base mined out? How does income increase over time? How does this compare between LotV and DH10? This is the only thing you are really interested in to get the point across. The difference is that you don't lose 50% of your income at 50% of HotS mineout time (~7:00) -_- At 16 workers, DH10 and HotS have almost the same efficiency and income. Literally the only difference in graphs would be that at 7:00, LotV economy would chunk off like a step function. We are talking about plotting minerals earned as a function of time, not as a function of worker count. Since DH10 and LotV start with different worker counts, the graphs would most certainly look different. DH10 =/= 12 worker start. The number of workers you start with is irrelevant, and in LotV we'd expect initial tests with DH10 to be done with 12 workers. SC2john is right when he says income/time for a normal game in lotv would look identical to hots except when you mine out the 4 patches (~7:00) when the graph jumps down rapidly (step function behavior). EDIT: our comparison to HotS is for two reasons 1) People generally have greater access to HotS and we can put extension mods online there 2) The efficiency curves for HotS and LotV are identical assuming equal number of nodes available If you would start HotS with 12 workers and compare it to HotS started with 6 workers you are saying that both mine out their base at the same time? Intuitively that doesn't make a lot of sense. After 1 min, your money earned from 12-worker-start HotS would be higher than from 6-worker-start HotS. As a result, the 12-worker-start HotS base would be mined out faster. And that is what I mean by saying that plotting only the worker count doesn't reflect the differences between the models. The graphs in the OP assume you have a fixed worker count and then calculate the income/minute you receive from having that fixed worker counter. We're not making any claims about bases running out faster. If you pitch your company to investors, you don't show them some theoretical model, you show them concrete data. The same is necessary here if you want to convince anyone at Blizzard.
The whole justification of the DH10 model is to prevent bases mining out too fast. If you want to sell your idea, you need to display concrete data to show how money accumulates and when a base is mined out in DH10 compared to LotV.
As BigJ shows this can also be done empirically if modeling is too hard.
|
On April 23 2015 14:25 BlackLilium wrote:
>snip<
If you play with the numbers of DH 3x3, please make sure you don't fall into the same trap I did, where reorganizing workers gave different results. FWIW I don't think that's necessarily a bad thing. This is why I made the sheet showing periodic settling, to show that it happens, and that organizing the workers manually will achieve the desired pattern once it settles. It's akin to the worker micro we have now to set up paired workers. But it would lead to random differences in mining rate without attending to it (albeit small differences) that competitive players might baulk at. However, bouncing would always disrupt the patterns once it started happening.
|
On April 23 2015 14:30 fancyClown wrote: The whole justification of the DH10 model is to prevent bases mining out too fast. If you want to sell your idea, you need to display concrete data to show how money accumulates and when a base is mined out in DH10 compared to LotV. DH2x5 is not trying to mine out the bases slower. You can apply DH2x5 to HotS bases, LotV bases or any other mineral distribution bases. The point of DH2x5 was to give the player with more active bases an imminent advantage of having slightly higher income... right there, when he has those bases - and not later, when bases start to dry out.
|
On April 23 2015 07:10 Big J wrote:Just to add to the discussion, I think that DH10 at the moment provides too much income already in the early game. I ran two tests with HotS vs DH10 with Zerg, featuring (very economic) hatch/pool/hatch builds and summed the minerals mined at each minute in the game for the first 7mins. These are the results: And in numbers This test was run on the premise of similar build orders, which with the changed economy sytem is probably suboptimal in the DH10 model.Since in HotS I was more or less spending all of my money, it goes without saying that in DH10 it became quickly apparent that I was building a bank. Enough money that I could have expanded a 4th and possibly even 5th time within the first 7mins to even further boost my economy through extra production and extra worker spreading. This happens, because DH10 is modelled to behave similar to the HotS model in full saturation, but before that, the income is quite a bit higher. Rapid expansion - like a hatch first build, but just in general the acquisation of a fast 3rd, or even 4th and 5th base - allows you to spread your workers very thinly. Therefore, each of your bases rides on the more effective bottom of the saturation curve. + Show Spoiler +Obviously, this is the intended expansion effect, but it needs to be noted that this effect starts to kick in within the first few minutes of a game. Trying to model the same fully-saturated 1base income might be too much of an economy boost, given that the common openings usually evolve around a very quick second if not even third base. To quote Downfall : "DH8 is poetry"
|
|
|
|