|
Here at teamliquid, we take note of post counts. We might not admit it, but we do, to one extent or another. Part of post counts has morphed into something of a tradition; marking important post numbers (read: numbers many zeroes) with great posts, trying to give something back to the community. CharlieMurphy’s great post is an example of this. I wanted to join in this tradition, and do something special with my two thousandth post. I’m not a great starcraft player, I’m not a good starcraft player, or even a mediocre starcraft player. So that eliminates a replay pack.
This leaves me with my rapier wit and wondrous sense of humor to make a post that is talked about for years weeks an hour however long you can last during sex. Because of my masterful and brilliant wit, my two thousandth post will consist of...wait, what? Hot_Bid is funnier than I am? Shit, change of plans. Anyway, during my two and a half minutes of fame, I welcome you to my two thousandth post!
As I mentioned, I’m not much of a player. That said, I still like starcraft; I post on teamliquid after all. What has captured my interest today is workers mining minerals. The very basis of starcraft. One of the things we take for granted here is the respective mining speeds. I have heard several times that protoss mines faster than the other races, due to the acceleration of the probe. I set out to find out just what the difference was, and I also hoped to fine out more about what the ideal number of workers is.
My experiment was born; take each race, and mine minerals with different amounts of workers. I started with 9 workers (one per patch on python), and moved up to 30 workers (3.33 per patch).
The Experiment:
Bearing in mind that the mineral position is different for different maps, I decided to use what I’m pretty sure is still the most common map normal map on bnet: Python. Basically, for a number of workers (starting at 9 and moving up to 30), I mined minerals for five minutes, and took note of how much my minerals had changed by. Then I did it again at a different location. The locations used were the 12:00 main and the 6:00 main. No other locations were used.
+ Show Spoiler [Method detail] +
Using chaoslauncher windowed mode with BW patch 1.15.3 (I started before 1.16 came out and I didn’t want to change in the middle)I started a on UDP LAN latency, I started a 1v1 game with me and a comp. During the countdown, I closed the comp’s spot. When the game started, and reported a draw, I elected to continue playing. I mined minerals until I had the desired number of workers, and a base at both 12 and 6. If I had started at 12 or 6, I mined minerals from the nat. The map was the melee version of Python 1.3 from the iCCup map pack, updated as of 5/10/2008.
After I had everything ready (worker number, bases in the right spots), I noted my initial number of minerals, and then sent them all to one of the bases, trying to stack them somewhat so they arrived at more or less the same time. I did my best to split to each mineral patch, with extras starting at the closest patches, and then branching out to the further ones as I got more workers. When the number of workers high, I started making some mistakes in worker splitting, but that’s why I did 5 minute trials.
Since apparently one of the chaoslaucher plugins includes a timer that starts when the game does (I had it at the top of the screen), that’s what I used to measure out 5 minutes. I noted the time when the workers reached the mineral patches, and five minutes later, I gave all my workers a stop command (1s2s3s). After I wrote down the number of minerals mined, I maynarded all of my workers to the other base, and did it at the new base.
I repeated this for each number of workers for each race, for a total of over 50 trials.
Anyway, with two five minute tests for each number of workers per race, I eventually came up with what I hope is an accurate representation of mining speed, as it varies with worker number. The graph of this result is in figure 1a below:
![[image loading]](http://img123.imageshack.us/img123/7841/picture2ok6.png) Figure 1a
To my surprise, my results painted a picture different from what I was expecting. I expected the conventional wisdom to be correct, that protoss mined minerals faster than other races, due to the probe’s superior acceleration. On the other hand, Elyvilon pointed out that as each mineral patch gets a worker mining, the acceleration will not matter as much; perhaps this is to be expcted. Also to my surprise, was that the results remained linear for far longer than I had expected. I thought that I would find a fairly rapidly decaying exponential curve. Although the curve looks logarithmic, the decay is very gradual, and is nearly a linear regression.
This also has implications on killing workers via storm drops and the like. Losing 4 workers when you had 15 to start out is pretty much the same mineral loss as losing 4 workers when you have 30 to start with. Losing one of your initial workers is obviously a much bigger deal than I realized. This also makes me think about when it's a good idea to pull probes or SCV's in defense.
Also important, is the increased amount of variation as the worker count increases. I believe this is due to small variations in the initial conditions, which leads the AI to choose different paths each time. If the worker AI was perfect, I have no doubt that there would be a clear ideal amount of workers.
To my mind, the most important thing to take away from this is just how well mining scales with the number of workers. I had thought that between 1 and two workers per patch would be the ideal number of workers. It’s clear that more workers than that is better. However, I’m not sure just how many is ideal. Clearly, with a main and natural operating with 30 workers each, it would be a prohibitive limitation to your food count. However, the data clearly shows that it would be advantageous to do so. When should the line be drawn?
Figure 2a, above, shows the number of minerals mined per worker, using the same data as the previous graph. It appears to be more of an exponential decline than the other graph, but is still quite linear. Looking at this graph, we can get a much clearer sense of when we want to stop producing workers. Getting 200 minerals for a 50 mineral worker doesn’t seem so worth it. But still, those workers stay with you to use later, unless you suck at starcraft like me, and wind up losing all of them to a storm/reaver/DT/vulture/m&m drop. Again though, it seems to scale fairly well.
Shown above, Figure 3a shows the extra amount of minerals gained by adding each worker. For example, a point at 15 workers shows how many extra minerals you get for adding your 15th worker up from 14. As you can see, the effective randomness in worker AI causes very drastic fluctuations. Because of the wild jumps in the graph, it might be less useful to add workers when you already have a high worker number. But also because of the wild jumps in the graph, it’s not so clear just when to stop.
Basically, this shows that worker AI is huge, and with a lot of workers, the AI is the determining factor. While I was testing this, I frequently saw something like 5 or 6 workers running around looking for mineral patches while there was an open patch or two on the edges. That kind of thing is the reason why the worker increment is so inconsistent.
Ultimately, it’s the individual’s choice as to how many workers to get. However, I hope I’ve provided you with enough data for you to make the choice for yourself. Well, I guess that was longer than two and a half minutes. I suppose you all aren’t as impotent as I thought you were. Thanks for reading, and I look forward to posting with a mutalisk.
Thanks to Elyvilon for editing help
Above is a fascinating look at the same problem, but approached from a theoretical standpoint. Antrax (the author) brings up the problem of workers wandering, but can not address it. However, his results show the best numers in theory:
Note that this is theoretical results only
In starcraft and in real life, theory and practice are always different. In practice, the ideal number of workers is not clear, but antrax's report brings up an interesting comparison between theory and practice.
|
This is a really really good post. I'd say 2 1/2 workers / mineralblock is the best saturation. For most of the maps that would be 22. (at least at the starting position).
This is really worth a 2000 post :-)! Maybe I'll write more, but right now I just can't think about more than just "this is a good post!" Should be stickied imo, because we can discuss a lot.
|
Wow, good job man 
|
thedeadhaji
39489 Posts
I think it would be really interesting to see what happens with 40 workers, b/c as naruto says, the "conventional" knowledge saturation amount is 2.5'ish workers per patch, which corresponds to roughly 22.5 workers.
We should expect the minerals/5 mins to level off rapidly, and seeing how and where this occurs should be of interest.
|
On December 03 2008 18:00 thedeadhaji wrote:
I think it would be really interesting to see what happens with 40 workers, b/c as naruto says, the "conventional" knowledge saturation amount is 2.5'ish workers per patch, which corresponds to roughly 22.5 workers.
We should expect the minerals/5 mins to level off rapidly, and seeing how and where this occurs should be of interest.
I'm actually interested in that too, but quite frankly, I was pretty damn sick of doing the trials, they take way too long. I also wanted to make my 2k post, so I didn't have to avoid posting out of fear of my post count rising. I'll probably expand it later in the week up to 3 control groups of workers.
|
This is odd. Someone else did the same test a while back and found that the marginal gains for each worker are actually greatest for the workers that bring you to the range of 2-3 per patch (with 0-1 being nearly as good and 1-2 being surprisingly awful), with the final worker being the most valuable. Their explanation was that the AI is particularly stupid in the 1-2 worker/patch range since they spend a lot of time finding empty patches, while once you get to 3/patch they don't see empty patches and therefore wait their turn.
Unfortunately, I can't find the study, but I do remember that the guy who did it started timing after his workers had stabilized (i.e. he had them mine for a few minutes and then started timing) whereas you took the opposite approach. The discrepancy between the two studies is predictable in terms of direction, but I would have thought that it wouldn't have been so severe (he found that the final worker is worth something like 100minerals/minute after stabilizing).
|
really good post. imo, ai pathfinding has a lot to do with this.
|
This is a great post. I'm VERY surprised at the nearly linear results of the first graph...
Great job. (:
|
I would have expected to see the gain drop more when you got above 25 workers. I guess the implication of this is that delaying your expo isn't quite as damaging as it might seem.
|
I should point out that this also has implications on killing workers via storm drops and the like. Losing 4 workers when you had 15 to start out is pretty much the same mineral loss as losing 4 workers when you have 30 to start with. Losing one of your initial workers is obviously a much bigger deal than I realized.
Also, worker AI is huge. While I was testing this, I frequently saw something like 5 or 6 workers running around looking for mineral patches while there was an open patch or two on the edges. That's the reason why the worker increment is so inconsistent. I'll add this to the OP.
@Signal: If there's any way you could find that study you referenced, I'd love to read it. I'm most surprised by the magnitude difference between that one and mine.
|
wow....nice 2000th post. I wonder how big your10,000th post celebration will be :O
|
You can tell a game is great when 10 years after its release people are still studying it and making these awesome posts. Keep it up! =)
|
Happy 2,000.
Really interesting study and nice graphs to go with it. =) It's nice to have some data to go by rather than just basing it off rules of thumb which originated who knows where.
|
United States42190 Posts
This means a lot for both storm drops and saturation. I'm very surprised at the linear results and the level of saturation required.
|
WOowwowoo. I actually tried to do something like this but it was so tedious and I gave up. Thanks! It satisfied my curiousity which I tried to satisfy and failed. ^^
PS - For mining, did you split them? did you send them all to a certain patch? I just want to know which, not discrediting your results at all.
|
|
|
PSS - Wow, toss and terran had an epic 27th worker?!
|
On December 04 2008 08:42 Pokebunny wrote:
WOowwowoo. I actually tried to do something like this but it was so tedious and I gave up. Thanks! It satisfied my curiousity which I tried to satisfy and failed. ^^
PS - For mining, did you split them? did you send them all to a certain patch? I just want to know which, not discrediting your results at all.
It sounds weird to say this, but for the most accurate results you could use the auto-split function on oblivion.
People like to throw around 'exponential' a lot, but it's not really a very suitable word.
|
Pokebunny: I'm pretty sure I mentioned splitting the workers in the spoiler 'method detail'. Anyway, I split workers to each patch, with extras starting at the closest and working outwards. For example, 9 workers was 1 per patch, 13 was 1 worker per patch with 2 workers on 3 of the closest minerals. 17 was 1 worker per patch, and then a second worker per patch for every mineral patch except the furthest away. I don't think I'm phrasing this well, but I hope I get the point across.
The epic 27'th worker comes from variations in worker AI, which I think I mentioned.
SonuvBob: That's really interesting look at the theoretical aspect of mining, thanks for linking that! I'm going to add that to the OP if you don't mind.
|
Sure, credit it to antrax
I think there was another one on TL somewhere, but I'm not sure.
|
Since nobody's mentioned it yet, I have to ask: Did anybody catch the figure numbers? Figures 1a, 2a, and 3a?
|
There was a post a long time ago about working mining speeds for gas an minerals. Guy made special maps to test acceleration and other things. Maybe it was ported over to broodwarmaps.net
|
Also way more linear than I expected, this helps to explain why I suck so much. Man, missing a probe can be devastating.
|
Very interesting post. Thanks. Extremely good read.
|
That's pretty good, that's an amazing job.
I had a study of that kind saved, but since it's pretty old and I only had it on my comp, I don't know where I took it from. But they adressed the values for numbers of workers higher than 3. After 3, the linear progression stops pretty quickly:
Workers/mineral field Minerals Mined
5 14360
4 14224
3 13546
17 10968
2 9880
1.5 8304
1 5648
table extracted from this pic: http://www.imagedump.com/index.cgi?pick=get&tp=391749
They left the workers mine for 15 minutes in same bases locations. For the 17 workers per mineral patch, it seems that they get so much in the way of each other that it reduces mining  But yea, from 3 to 4 and 4 to 5, the mining is almost not improved, not worth at all the investement in those workers (considering you dont expo later)
The same kind of experiment was also done for races variations. 9 mineral patch, 9 workers, 15 minutes:
Race Minerals
Toss1 10186
Toss2 10130
Zerg1 9898
Zerg2 9706
Terran1 9466
Terran2 9210
Table extracted from this pic: http://www.imagedump.com/index.cgi?pick=get&tp=391750
So yea
Edit: Lol yea at figure 1a, 2a, 3a Didnt pay attention enough ><
|
Wow cool stuff dude! I had always been wondering about this.
I always thought there'd be a point where it would start to literally go down and get you less money due to the AI when you have more workers.
Perhaps that happens once you get up to numbers like 40.
Edit: At first I was thinking this would be mostly useless to spend the time testing, but when you think about it, it's actually useful for a situation like if your natural dies and you send all your workers back to your main. Let's say you then have like 40-45 workers all in your main. It might be so bad for the AI that it might be better to take some of them off. It'd be really interesting to see if there's any point in which it goes down (like even if you went up to like 60 or something.
|
This is a super duper long shot but does anyone have the images from the OP or something similar? I would love to see the data on Worker Saturation this looked like an amazing article.
|
|
|
|
|
|
|
|
EPT![[image loading]](http://img372.imageshack.us/img372/3377/picture3nk0.png)
![[image loading]](http://img132.imageshack.us/img132/8453/picture4yo4.png)
![[image loading]](http://img122.imageshack.us/img122/7299/picture5fj6.png)
