EPTGenocide
In Response to David Kim re: SC2 Economy - Page 15
| Forum Index > Legacy of the Void |
In response to: http://us.battle.net/sc2/en/forum/topic/17085919227 | ||
|
Penev
28536 Posts
Genocide | ||
|
OtherWorld
France17333 Posts
On April 23 2015 23:37 Freakling wrote: How about this: Just implement a less linear economic mechanic (DH, modification thereof, or something entirely else that serves the purpose) first. And then leave the other stuff, i.e. the resource distribution on the map, to the map makers? Giving freedom to mapmakers? What are you thinking about, my good man, this can only lead to disasters and terrible maps ! Mapmakers shouldn't be allowed to experiment, ever ! | ||
|
Shuffleblade
Sweden1903 Posts
On April 23 2015 17:52 Hider wrote: I want to play a game where I don't build any workers but only arguments from the get-go.... Oh I can't do this? Guess game-mechanics already do what you don't want them to.. The point is that game-mechanics are in the game to promote interesting gameplay. Some time that means to get rid of a tradeoff between 1 interesting type of gameplay and a lame type of gameplay by only making the interesting type possible. A great game-designer will then make sure that there are other more interesting tradeoffs elsewhere in the game. Well yes they do but you arguement is not valid, you can play a game without building any workers. It can work too, 6 pool xD Also for other races, its map dependant try playing 1v1 where both´spawn in the same base in a 2v2 map. no workers all out rush is is possible. | ||
|
Meavis
Netherlands1300 Posts
On April 23 2015 23:37 Freakling wrote: And then leave the other stuff, i.e. the resource distribution on the map, to the map makers? but casuals cant comprehend anything that isn't 8m2g or 6hym2g!, their minds will explode! /s | ||
|
Freakling
Germany1534 Posts
| ||
|
OtherWorld
France17333 Posts
On April 23 2015 23:52 Freakling wrote: ...And now we know why I wouldn't ever care enough to be even remotely involved in any SC2 map project... Because apart from a few individuals, most people with important roles in SC2 don't care about maps. Correct. | ||
ZeromuS
Canada13410 Posts
On April 23 2015 23:37 Freakling wrote: How about this: Just implement a less linear economic mechanic (DH, modification thereof, or something entirely else that serves the purpose) first. And then leave the other stuff, i.e. the resource distribution on the map, to the map makers? Resource distribution is up to blizzard ultimately for now. And thats why we arent changing the 6 workers or the total gas/min counts in our mod  | ||
|
Freakling
Germany1534 Posts
On April 23 2015 23:57 OtherWorld wrote: Because apart from a few individuals, most people with important roles in SC2 don't care about maps. Correct. Which is exactly why they should not be in charge of making any meaningful decisions in that regard... | ||
|
The_Masked_Shrimp
425 Posts
And that will be the case no matter what the harvesting model is. | ||
|
fancyClown
65 Posts
On April 24 2015 01:02 The_Masked_Shrimp wrote: All the theory discussion and risk to take a fourth etc. seems kind of blank to me. Taking a fourth in never purely about ncreasing your income. It's about getting more gas and mining out your 2nd and third slower. You can then afford to loose the 4th and fall back on 3rd which would be closer to be mined out without having taken the fourth before. And that will be the case no matter what the harvesting model is. Good point. I also come to the conclusion that the issue with 3 base saturation is overly exaggerated. LotV model is fine as it is. Let them do the beta tweaking and see how it turns out. | ||
|
ZeromuS
Canada13410 Posts
On April 24 2015 01:16 fancyClown wrote: Good point. I also come to the conclusion that the issue with 3 base saturation is overly exaggerated. LotV model is fine as it is. Let them do the beta tweaking and see how it turns out. We didnt bring up the 4 base vs 2 base thing blizz did :p we just responded. I disagree on the three base saturation it really has been an issue at higher levels of play for a very long time. The premise of our idea in addressing the "3 base sat cap" is that its more of a 24 mineral node cap, which is an issue due to worker pairing. Our core premise is as follows: On even workers, the player with more bases, should generally have a better economy. Of course there is an inherent cap to this being 1 worker for 1 mineral cap. This is because you cant split a worker in half to work on 2 patches. So the core premise has a caveat that takes twice as long to reach as the current economic model. Thats our main thing  | ||
|
EatThePath
United States3943 Posts
On April 23 2015 18:13 BlackLilium wrote: Technically it should probably be TH. Or maybe simply MH (Multi Harvest), since all the approaches rely on the same mechanism of having multiple harvests per trip. Originally when I was developing the idea, I was looking at double harvest first, but couldn't find a formula that would satisfy me. DH had either:
Maybe others will find a nice balance that I couldn't Triple harvest was a compromise for me and this is what I ultimately advertize. However, I used the old name and it sticked. Nowadays DH is an already recognized name, throwing in new names could confuse people and weaken the popularity of all versions. For clarity I tend to simply indicate the number of harvests and size of each harvest, using DH 2x5, DH 2x4 and DH 3x3. Did you not find bounce behavior like with DH10 settings? Since that seems to be desirable in fact. Like it's the basic functionality making DH10 appealing. On April 24 2015 01:16 fancyClown wrote: Good point. I also come to the conclusion that the issue with 3 base saturation is overly exaggerated. LotV model is fine as it is. Let them do the beta tweaking and see how it turns out. A significant portion of my ladder games get to a point where I literally say to myself "I wish it was relevant for me to take 4+ bases right now so I could win easier instead of grinding out a game I'm clearly winning based on engagement efficiency" because that's your only option in SC2 lategame. | ||
|
fancyClown
65 Posts
On April 24 2015 01:16 fancyClown wrote: Good point. I also come to the conclusion that the issue with 3 base saturation is overly exaggerated. LotV model is fine as it is. Let them do the beta tweaking and see how it turns out. A significant portion of my ladder games get to a point where I literally say to myself "I wish it was relevant for me to take 4+ bases right now so I could win easier instead of grinding out a game I'm clearly winning based on engagement efficiency" because that's your only option in SC2 lategame. Yes, but the problem doesn't lie in the economic model, it lies in the supply cap. The supply cap is relatively arbitrarily set at 200. Don't ask me why it is exactly 200, I suppose Blizzard has issues rendering more units than that. A simple fix would be if Blizzard did the following: Once you are maxed out at 200/200, you can still build workers, but workers only. This would completely eliminate all the problems mentioned with 3 base saturation. You then could build as many workers and as many bases as you want once you are maxed out. I don't see why this is not a better solution than arbitrary changes to the economic model. | ||
|
Nebuchad
Switzerland12488 Posts
On April 24 2015 02:17 fancyClown wrote: Yes, but the problem doesn't lie in the economic model, it lies in the supply cap. The supply cap is relatively arbitrarily set at 200. Don't ask me why it is exactly 200, I suppose Blizzard has issues rendering more units than that. A simple fix would be if Blizzard did the following: Once you are maxed out at 200/200, you can still build workers, but workers only. This would completely eliminate all the problems mentioned with 3 base saturation. You then could build as many workers and as many bases as you want once you are maxed out. I don't see why this is not a better solution than arbitrary changes to the economic model. There are many problems with that. Zerg can make attacking units out of their workers, and even if they couldn't, zerg has a much better capacity of massing workers, so they would be strongly advantaged by this. On top of that, it is much more arbitrary than a 200 cap: what is the logic of a situation where you're able to create one type of unit and not the other types? | ||
|
EatThePath
United States3943 Posts
On April 24 2015 02:17 fancyClown wrote: Yes, but the problem doesn't lie in the economic model, it lies in the supply cap. The supply cap is relatively arbitrarily set at 200. Don't ask me why it is exactly 200, I suppose Blizzard has issues rendering more units than that. A simple fix would be if Blizzard did the following: Once you are maxed out at 200/200, you can still build workers, but workers only. This would completely eliminate all the problems mentioned with 3 base saturation. You then could build as many workers and as many bases as you want once you are maxed out. I don't see why this is not a better solution than arbitrary changes to the economic model. Supply cap adjustments do have some positive effects but it also affects balance, unit interaction, map design, etc etc, often in detrimental ways. And it doesn't actually address the problem of an optimal worker supply ratio --> base cap, just extends it to a higher base count. That doesn't give any benefit to increasing your base count beyond the useful cap. | ||
|
BlackLilium
Poland426 Posts
On April 24 2015 02:00 EatThePath wrote: Did you not find bounce behavior like with DH10 settings? Since that seems to be desirable in fact. Like it's the basic functionality making DH10 appealing. The "break the pairing" is not accurate. What is needed is:
DH2x5 achieves that through AI bouncing the first worker to different mineral patch (this "breaking the pair" - at least as I understood it). It was done similarly in Starbow, actually - which is not a variant of DH. DH 3x3 achieves that through multiple wait-at-resources periods, when the worker sits idly at the minerals, but does not occupy it. These wait periods can be exploited by other workers, but with decreased efficiency. The more workers at minerals, the more of those gaps are filled. Interesting fact: adding more than 24 workers, DH 3x3 still shows some improvement, but it is marginal (10% mining efficiency). This is because there are still some gaps remaining. Absolute saturation is achieved at 32 workers. But that 24-32 is not worth shooting for; it may be useful only in extreme situations (e.g. you lost some bases and want to come back). | ||
|
EatThePath
United States3943 Posts
On April 24 2015 02:35 BlackLilium wrote: The "break the pairing" is not accurate. What is needed is:
DH2x5 achieves that through AI bouncing the first worker to different mineral patch. It was done similarly in Starbow, actually - which is not a variant of DH. DH 3x3 achieves that through multiple wait-at-resources periods, when the worker sits idly at the minerals, but does not occupy it. These wait periods can be exploited by other workers, but with decreased efficiency. The more workers at minerals, the more of those gaps are filled. Interesting fact: adding more than 24 workers, DH 3x3 still shows some improvement, but it is marginal (10% mining efficiency). This is because there are still some gaps remaining. Absolute saturation is achieved at 32 workers. But that 24-32 is not worth shooting for; it may be useful only in extreme situations (e.g. you lost some bases and want to come back). Well I'm asking for clarification about your experimenting because from my understanding, you didn't see bouncing, but TL's DH system is getting bouncing, which I still don't quite understand. Does it have to do with the recovery time at-patch? | ||
|
ZeromuS
Canada13410 Posts
On April 24 2015 02:38 EatThePath wrote: Well I'm asking for clarification about your experimenting because from my understanding, you didn't see bouncing, but TL's DH system is getting bouncing, which I still don't quite understand. Does it have to do with the recovery time at-patch? Bouncing is the result of a worker getting to a patch, deciding whether to wait or look for another patch. When the patch is being mined and it would take longer than a second to wait for the patch to be free they initiate a scan and go to the nearest free patch to begin mining it. In DH10 this breaks the pair by forcing the AI to bounce. In the three harvest cycle you achieve the same goal of breaking the worker pair as we know it, but it doesn't cause nearly as much bouncing. At certain worker counts there will still be a bounce but its not as common as in DH10. You basically have the workers interleaving their mining cycles creating an offset pair that still achieves the same goal of a lowered efficiency in mining on the 9th worker relative to the first 8 if left alone. This is because the workers will either wait longer (in lillium's examination) or they complete a harvest cycle quicker (something I am exploring) exploiting the worker wait times differently but to the same end | ||
|
BlackLilium
Poland426 Posts
On April 24 2015 02:38 EatThePath wrote: Well I'm asking for clarification about your experimenting because from my understanding, you didn't see bouncing, but TL's DH system is getting bouncing, which I still don't quite understand. Does it have to do with the recovery time at-patch? I explained why I get a descreased mining efficience, despite keeping a pair. I didn't explain why bouncing occurs in the first place. I don't understand it fully myself. I think it works like this: When a worker tries to mine from an occupied mineral patch it checks how long it would have to wait for his turn. If the wait is too high and another patch is available, it bounces - if not, it waits. I don't know however where this bounce condition is placed. Is it a constant time? A fraction of harvest time? .... | ||
|
ZeromuS
Canada13410 Posts
On April 24 2015 02:46 BlackLilium wrote: I explained why I get a descreased mining efficience, despite keeping a pair. I didn't explain why bouncing occurs in the first place. I don't understand it fully myself. I think it works like this: When a worker tries to mine from an occupied mineral patch it checks how long it would have to wait for his turn. If the wait is too high and another patch is available, it bounces - if not, it waits. I don't know however where this bounce condition is placed. Is it a constant time? A fraction of harvest time? .... Part of it is set at the mineral patch value in data editor i think under "wait" for when the mineral patch can receive another probe? So you can set a delay I believe using that for getting a worker to mine after another one is done and default is 0.5 seconds? And I believe the wait time for the probe itself is hardcoded as "if the patch I arrive and wait at will be free in the next 1 second I will wait, anything longer and I will scan for an open patch and go there to do my work" I think this is the case based on a previous lalush post. | ||
| ||
