EPTLotV economy: non-linearity in time - Page 2
| Forum Index > Legacy of the Void |
|
Geiko
France1939 Posts
| ||
|
Genesis128
Norway103 Posts
On May 15 2015 17:16 EatThePath wrote: Question: in building your graphs, did you use an algorithm or game data? Because for n < 2N (n workers, N patches), worker micro would significantly change mine-out times, and I think some of the results you point out would differ significantly. Most importantly perfect worker control in LotV would smooth things out a lot for 4+ bases, although it is unrealistic for real gameplay. I used a mix. To generate the income function in time/worker space I used an algorithm. I backed this up by a few screen shots of in-game data to show that this is a real effect and not purely theoretical. On May 15 2015 09:57 Plexa wrote: You know shit is serious when matlab gets pulled out. Hehe, this made me smile :D. You are completely correct in that matlab was used to produce these results, but since that is a licensed software, one might use Octave if you are interested in reproducing the results. The source code is given below. + Show Spoiler + function [income, time, patches]=inc(workers, minerals, time) % function [income, time, patches]=inc(workers, minerals) % % parameters: % workers - scalar value of number of workers available % minerals - array of all mineral nodes and how much each contain % returns: % income - array of income per minute (IPM) for a given time period (length n) % time - time interval for this IPM (length n+1) % patches - number of minable mineral patches available (length n) % % example: % [I t] = inc(19, 1500*ones(8,1)); % HotS econ 1-base % [I t] = inc(19, 1500*ones(16,1)); % HotS econ 2-base % [I t] = inc(19, [9,9,9,9,15,15,15,15]*100); % LotV econ 1-base % [I t] = inc(19, [6,8,10,12,14,16,18,20]*100);% DPM econ 1-base % I = sort([I,I,0],'descend'); % t = sort([t,t(2:end)]); % plot(t,I); incPerMinute = [0, 42, 84, 810/8]; income = []; if nargin<3 time = [0]; end n = length(minerals); if n==0 patches = []; return; end workPerNode = floor(workers/n); workersLeft = mod(workers,n); w = ones(n,1)*workPerNode; w(end-workersLeft+1:end) = workPerNode + 1; w = min(w,3); w = w + 1; incOnNode = zeros(n,1); dt = zeros(n,1); for i=1:n incOnNode(i) = incPerMinute(w(i)); dt(i) = minerals(i) / incOnNode(i); end dt = min(dt); time = [time, time(end) + dt]; for i=n:-1:1 minerals(i) = minerals(i) - dt*incPerMinute(w(i)); if(minerals(i) < 1) minerals(i) = []; end end [I time newPatch] = inc(workers, sort(minerals), time); income = [sum(incOnNode), I]; patches = [n, newPatch]; The basic idea of this algorithm is to optimally allocate workers. You spread your workers out evenly, followed by putting "extra" workers left at the end to the biggest patches available. Thus if you had 5 workers mining patches of size 200, 400 and 500 you would put 2 workers on the patch with 400 and 500, leaving one worker at the 200 patch. Incidentally this is not the optimal strategy. If you had 5 workers and patches of size 300 and 400 this algorithm would put 2 workers on the 300 patch and 3 workers on the 400 patch, mining the biggest patch empty first (this has most workers on it), followed by 5 workers on the smallest patch which now contains 40 minerals. The optimal strategy would be to mine the 400 patch until it has equal amount of minerals to the 300 patch and then letting the 5th worker take turns, harvesting 5 minerals from patch 1, then 5 minerals from patch 2, then back to patch 1 again. I consider this micro infeasible in an in-game environment and the algorithm returns a sub-perfect mining results. I did do some in-game tests to verify if this mining method is reasonable. It is perfectly possible to manually assign worker pairs, letting 2 workers mine the big patches in LotV and keeping a single worker on the small patches. They do stay this way until the resources run out after which they rearrange themselves. However, it is not possible after you have two workers per patch, since the AI overrides any attempts to manually control your third worker. EDIT: For the screen-shot of the income drop in LotV economy, no micro was applied. These were AI controlled players and I only fixed their worker count. It shows that the effects discussed in this thread are real, even if you leave it up to the AI to harvest minerals. The model used here does certainly not perfectly match in-game events, but it does give understanding of the mechanics going on. The general trends are still present, and that is that the current LotV economy operates with a sharp break in income, and having unique mineral count will provide a smooth decline in income. | ||
|
EatThePath
United States3943 Posts
One issue with economies that require involved worker placement to maximize value is that harassment creates big knock-on virtual damage by disrupting all the sunk APM of worker placement at the base, which can add up to a lot of game time and effort. You could see this as an attractive feature in some ways, since it promotes harassment aka action. But it's also quite annoying from player perspective. | ||
|
ejozl
Denmark3413 Posts
Ex. what order would the patches be in, considering there's far away patches and you want an even distribution for not always having a surperior patch to rally your workers to. Honestly I prefer my previous suggestion, with: Bountiful, Fair and Scarce levels. Each Mineral patch has 1500 Minerals and from 1500-1000 it is Bountiful, from 1000-500 it is Fair and from 500-0 it is Scarce. Bountiful = Worker returns 5 Minerals pr. trip Fair = Worker returns 4 Minerals pr. trip Scarce = Worker returns 3 Minerals pr. trip I didn't make the research for this, so there's that, but I think even this is a less weird way of doing it. | ||
|
Grumbels
Netherlands7031 Posts
| ||
|
Beelzebro
United Kingdom45 Posts
| ||
|
Magnifico
1958 Posts
| ||
|
The_Masked_Shrimp
425 Posts
With your model you must account for the fact that even if you have Y bases, after some time you won't be able to keep up building X stuff; macroing is already a bit of a pain (it was even more in BW) and adding the worker planning on top of it would be a real chore. I'm all for implementing things to make pro matches more exciting but don't forget it's a game, it's supposed to be simple, it's supposed to reach out to the public. Most sports are just made of really simple tasks. | ||
|
JCoto
Spain574 Posts
http://us.battle.net/sc2/en/forum/topic/17259647265 | ||
|
tili
United States1332 Posts
I can't help but think that they thought of this and perhaps have a reason for doing the current half (or 60%) vs full patch... maybe to make it obvious to the player which nodes are fuller to maybe populate those first? On May 15 2015 09:57 Plexa wrote: You know shit is serious when matlab gets pulled out. Also this  | ||
|
linuxguru1
110 Posts
As a side note: it's great to see that the community is so engaged in making sure LotV will be a quality game | ||
|
BlackLilium
Poland426 Posts
I too think it is better than the current LotV model. Still, I think it gives less strategic options than DHx models. Why? Consider the following scenarios: Fast expansion on low worker count HotS: Absolutely no reason to expand if you don't plan to get more workers. DPM: The risk of taking base early gives no benefit. Only after several minutes the base will pay for itself. DH9: Benefit is not big, but noticeable, especially at high-level play. Allows for cutting workers for army, while maintaining income. Moderate/balanced expansion and sub-saturate (less than pathes x2) worker count DPM: The only valid economy strategy of this model DH9: Most common strategy, giving a game similar to open/expansive HotS strategy HotS: Valid in aggresive builds, otherwise you want to keep worker production ("probes and pylons") Low expansion with saturated bases (patches x2) DPM: A trap! Soon you end up with oversaturated bases. Soon you end up in a situation "must expand", although not so aburptly as in LotV. Otherwise - why did you build so many workers if you didn't plan to expand? DH9: A valid HotS-like turtle strategy, with a moderate drop in efficiency HotS: Standard build. Expansion lost: few oversaturated bases DPM: Heaviest punishment, similar to LotV. You have a lot of workers with nothing to do. DH9: Oversaturated bases, even with 24+ workers, give you a marginal income bonus - higher than HotS - giving you a chance to rebuild. HotS: Moderate punishment, you get some income bonus in 16-24 worker count range. DH9 gives you options. While losing an expansion is never wanted, every situation is a valid strategy that gives you something to do. In HotS, LotV and DPM there is one "best" strategy and all other cases are - in most cases - an error. | ||
|
ZeroCartin
Costa Rica2390 Posts
On May 15 2015 09:57 Plexa wrote: You know shit is serious when matlab gets pulled out. this so much lol | ||
|
frostalgia
United States178 Posts
A simple way to achieve this that isn't being considered yet is lowering the amount of patches from 8 to 6 per base. Each base will reach full saturation much quicker, while also slightly lowering mineral income (and I mean very slightly.. like you don't float minerals while trying to spend gas anyway). This will mean players who expand faster will make use of their workers and achieve a better income. Lowering patches from 8 to 6 (with 1500 in each patch) is easy to digest for all levels of players, yet still affects expanding and income in a way that will make things a lot more interesting. I know what you're thinking, but I ask you to fully consider the effects before writing this off. I don't believe MULEs would be a huge deal with this economic model, as it would only mean Terran gets a better income than other races.. which they already do. They'll still only be able to saturate up to 12 workers per base, and when they use MULEs the bases will mine faster. This should still even out with the faster worker-pumping Zerg and Protoss have, and if Terrans decide to camp it can be exploited now a lot easier than back in the WoL days. If MULEs did prove to create too much of an income advantage, the amount of minerals returned or the harvest time could be lowered to even things out if necessary. That's what Beta is for.. trying out reasonable ideas that work in the long run, and tweaking if necessary. Saturating every base at 12 workers is a simple change with complex ramifications on expanding and income that should add some more interesting decision making once you fully saturate a base.. instead of the current model, where you get 2-3 bases of income then only expand once you mine out a base. It's doable, it would just take the support of some of us who are willing to try it out. | ||
|
ZigguratOfUr
Iraq16955 Posts
On May 15 2015 23:52 JCoto wrote: The post seems a more complicated version of what I suggested in this forum topic, proposing mining efficiency (mining per trip) to drop as the patch gets mined, giving a clear window time of ecconomical advantage for expanding players. http://us.battle.net/sc2/en/forum/topic/17259647265 Your solution isn't as good because its harder to eyeball how much money you're getting at any given time, especially for a newer player. With this it's obvious to anyone how the economy is decreasing. | ||
|
FueledUpAndReadyToGo
Netherlands30548 Posts
| ||
|
GunLove
Netherlands105 Posts
Also, my fundamental issue with all these new style economy propositions, is that they do not consider what Blizzard is actually trying to achieve with their new style economy. Namely: 1. Speeding up the game where it counts 2. Breaking stalemate type gameplay and 200 vs 200 game-ending battles. 3. Emphasizing army control/micro over the macro side of things. - OP's idea The main point you are overlooking in this proposition is the amount of work that goes into redistributing your workers from base to base to achieve optimal saturation. If you play the beta currently, you will already notice a considerable increase in workload (especially later in the game when you have many bases), even only if it's half the patches that run out at the same time. Don't forget that this process also includes the effort that goes into re-adjusting townhall rallypoints and monitoring the saturation levels in the meantime (these do not only require extra micro actions, but also mental attention and visual confirmation). I'll bet my butt that Blizzard already considers this extra economical micro workload the main drawback of having 2 different mineral values, and secretly, in an ideal world, they'd like to automate this process, but don't dare to consider it because of community backlash "boohoo dumbing down the game" etc. Proposing to quadruple this workload (with 8 different patch mineout times instead of 2 in LotV) is just ludicrous, and only possible by someone who thinks purely in matlab (no offense). - DH9/DH10 The main problem I see here is that DH9/DH10 just induces the scenarios that Blizzard is trying to solve. This model basically wants to make the advantage of being up a base on your opponent smaller than it currently is in LotV. Indeed the argument that is used, is that the turtling tactic should be more viable. Apart from the fact this slows down the game, it also encourages 200-200 battles. If a 3 base player has an economic advantage that he cannot capitalize on reasonably soon, over a 2 basing turtler that is trying to max out, neither side will be challenged to make plays. Think about it: the macro player can't harass because the other is turtling, and the turtler can't harass because trading armies works in the favor of the opponent. In LotV, if someone expands you better expand too, or put on the pressure. In any case, you gotta do something FAST. Also, imho, the whole "encouraged to expand" vs "expand or else" argument that lines all these economy proposals is just utter sophistry. It's not the economic model that makes you have to expand, it's your OPPONENT. Go play a 100 games in beta and you will see it's only semantics, and that it's still perfectly viable to be behind a base and make a big push to punish the macroing player or even win outright. The only thing we really lose here is that turtle-to-200-and-1-big-battle style, which is exactly what one of the aims is of LotV. Addendum: - 6 instead of 8 patches Out of all the new economy ideas I actually think this one has the most merit, although I can't see how it is better than the current LotV model. The biggest thing this does is slow down the game in a meaningless way. Yes, you have to spread out earlier to more bases, so it does open more harass opportunities. But you will get to that situation slower, because of less income per second per base. One of the nice things in LotV is that the action picks up a lot earlier in the game than we are used to. Also, I have a feeling most people forget that even though your main and natural base might be mined out quickly in LotV, more than 9 times out of 10 these bases will contain most of your production and tech buildings, which are still a prime target for harass. In other words, don't forget you're still very much 'spread out', even though those bases might no longer contain minerals. | ||
|
rpgalon
Brazil1069 Posts
On May 16 2015 06:19 GunLove wrote: I commend OP on such and elaborate write-up, but to be frank I think this is a horrible idea. Perhaps it sounds good on paper, and in graphs, but it completely forgoes any practical considerations. I therefore also suspect that most of the commenters here are not playing the beta yet. Also, my fundamental issue with all these new style economy propositions, is that they do not consider what Blizzard is actually trying to achieve with their new style economy. Namely: 1. Speeding up the game where it counts 2. Breaking stalemate type gameplay and 200 vs 200 game-ending battles. 3. Emphasizing army control/micro over the macro side of things. - OP's idea The main point you are overlooking in this proposition is the amount of work that goes into redistributing your workers from base to base to achieve optimal saturation. If you play the beta currently, you will already notice a considerable increase in workload (especially later in the game when you have many bases), even only if it's half the patches that run out at the same time. Don't forget that this process also includes the effort that goes into re-adjusting townhall rallypoints and monitoring the saturation levels in the meantime (these do not only require extra micro actions, but also mental attention and visual confirmation). I'll bet my butt that Blizzard already considers this extra economical micro workload the main drawback of having 2 different mineral values, and secretly, in an ideal world, they'd like to automate this process, but don't dare to consider it because of community backlash 'boohoo dumbing down the game' etc. Proposing to quadruple this workload (with 8 different patch mineout times instead of 2 in LotV) is just ludicrous, and only possible by someone who thinks purely in matlab (no offense). - DH9/DH10 The main problem I see here is that DH9/DH10 just induces the scenarios that Blizzard is trying to solve. This model basically wants to make the advantage of being up a base on your opponent smaller than it currently is in LotV. Indeed the argument that is used, is that the turtling tactic should be more viable. Apart from the fact this slows down the game, it also encourages 200-200 battles. If a 3 base player has an economic advantage that he cannot capitalize on reasonably soon, over a 2 basing turtler that is trying to max out, neither side will be challenged to make plays. Think about it: the macro player can't harass because the other is turtling, and the turtler can't harass because trading armies works in the favor of the opponent. In LotV, if someone expands you better expand too, or put on the pressure. In any case, you gotta do something FAST. Also, imho, the whole "encouraged to expand" vs "expand or else" argument that lines all these economy proposals is just utter sophistry. It's not the economic model that makes you have to expand, it's your OPPONENT. Go play a 100 games in beta and you will see it's only semantics, and that it's still perfectly viable to be behind a base and make a big push to punish the macroing player or even win outright. The only thing we really lose here is that turtle-to-200-and-1-big-battle style, which is exactly what one of the aims is of LotV. Addendum: - 6 instead of 8 patches Out of all the new economy ideas I actually think this one has the most merit, although I can't see how it is better than the current LotV model. The biggest thing this does is slow down the game in a meaningless way. Yes, you have to spread out earlier to more bases, so it does open more harass opportunities. But you will get to that situation slower, because of less income per second per base. One of the nice things in LotV is that the action picks up a lot earlier in the game than we are used to. Also, I have a feeling most people forget that even though your main and natural base might be mined out quickly in LotV, more than 9 times out of 10 these bases will contain most of your production and tech buildings, which are still a prime target for harass. In other words, don't forget you're still very much 'spread out', even though those bases might no longer contain minerals. It's nice to see some people having these thoughts too, I agree with you 100%. I think DH does not encourage expanding enough. the blizzard system is better in avoiding deathball games because each base is extremely important, so you can get really ahead if you attack and harass a base, of course while trying to keep your bases safe, and the player that is able to stay one effective base ahead, gets a deserved clear advantage. the reward in attacking is too good to ignore. playing defensively is less effective, so each player ends up attacking each other far more in LotV. | ||
|
WhenRaxFly
45 Posts
The OP's proposal is just a more complicated version of Blizzard's suggestion. DH still pretty much the same as the current HOTS model except it's more efficient mining so you need less workers to max a base. Blizzard's model rewards worker management but doesn't over punish lack of management, so it's a pretty good compromise. | ||
|
`dunedain
655 Posts
Thanks for the effort put into this, hopefully Blizz checks this out. | ||
| ||
