EPTThis leaves me with my rapier wit and wondrous sense of humor to make a post that is talked about for
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?
![[image loading]](http://img372.imageshack.us/img372/3377/picture3nk0.png)
Figure 2a
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.
![[image loading]](http://img132.imageshack.us/img132/8453/picture4yo4.png)
Figure 3a
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
On December 04 2008 08:42 SonuvBob wrote:
http://www.yellowchrome.org/1com/sclegacy/final_review.pdf
http://www.yellowchrome.org/1com/sclegacy/final_review.pdf
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:
![[image loading]](http://img122.imageshack.us/img122/7299/picture5fj6.png)
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.
