|
I make probe first, as I see most do. Is there any actual advantage to doing so?
My friend believes it doesn't matter, and that he will actually have minerals sooner than me by sending probes first then building a probe, albeit by a fraction of a second.
I've heard the response, "You're ahead in the worker count," mainly because that was my explanation to him as to why building a probe first is absolutely a fundamental. I was at a loss to give him any kind of evidence as to why it's actually advantageous.
I know this a miniscule point of strategy, but I thought I'd ask more experienced members for more details about this decision at the start of the game that we all make. Is it truly inconsequential?
|
You always make the worker first then send. The advantage of having the worker .000001 seconds faster outweighs the advantage of getting extra minerals .0000001 seconds faster.
|
sorry this is my first post and i realize it's in the wrong forum.. Should be starcraft 2 strategy. I don't know how to request it moved.
|
|
I understand that that's the given logic we all take for granted. Does anyone know why it is though? Do we scoff because we'd rather not mathematically plot the gain?
|
I usually make the worjer and then send them to work. Keep your mouse centered in your screen and you pretty much land on the nexus/hatch/CC right away. You can even hold the e (for protoss) and then click on the nexus and it will start the probe production right away.
|
|
It's pretty basic in the long term it's better to have a worker .000001 seconds faster because then each time it mines it'll give you minerals .000001 seconds faster than if you send workers first, sending workers first gives you minerals .000001 seconds faster but then you would fall behind the guy who is getting that extra mineral .000001 seconds faster every time his .000001 second faster worker mines.
|
There's not really much logic to it. If you don't build your worker first, it means you complete your worker later plus you'll have more than 50 minerals by the time the first worker finishes, and we all know having extra resources in StarCraft is always a bad thing. Having just the right amount of resources for something is always ideal. However, if you did build your worker first, it'll be done sooner plus you'll be able to start another immediately afterwards anyways.
|
I find it more efficient in the long term to start the worker saturation process right off the bat then wait.
|
The difference is totally insignificant.
|
I believe somebody crunched this problem and actually discovered that sending the workers first actually nets a small advantage.
If you think about it, this makes sense.
If we assume the following: 1. Roughly 1 mineral / second per worker 2. Roughly 1/2 second between making the worker and sending the workers or visa versa
Making the extra worker 1/2 second early nets us 1/2 a mineral, whereas sending the workers first nets us 3 minerals.
Then again, you have to count in human reaction time - perhaps it's easier to make the worker first because you know your Nexus/CC/Hatch will be in the center of the screen and using that time you notice where the mineral patches are. The tests which concluded sending workers first was slightly better performed the tests on a build order tester map where the tester knew where the mineral patches were beforehand.
And in the end, none of this matters. I always make my worker first and then send my workers out. When I send my workers out, I don't even bother splitting. Less than optimal? Maybe. Do I care? Not even a tiny bit.
|
Before I say anything, the difference is insignificant. This is just an intellectual argument. I've made this argument in previous threads before, but it keeps coming up.
Sending your workers first is better. The popular consensus is that making a worker first is better, I think just because day[9] said it and everyone echoed it, but if you think about it logically you can see sending your workers first is better.
Let's say that your second action takes .5 seconds to execute after your first action. Let's look at both scenarios:
1) You send your workers first. This means that in the first .5 seconds of the game, you are not producing a worker. You are therefore down .5 seconds of mining time from one scv at the point at which the scv hits the mineral line.
2) You create your worker first. This means that you are missing out on .5 seconds of mining time from six scvs.
You can logically extend this comparison and see it more intuitively. What if you were really slow? It takes you 10 seconds to do your second action. In this case, you're missing out on a gigantic 60 seconds of worker time if you choose to build your worker first, as opposed to only 10 seconds of worker time if you choose to send your workers first.
This was worked out by some math wizards in the AoE community and it was reasoned that this is the better option. The SC2 community, though awesome, is a bit less-awesome at math.
|
Yea. It seems there's no exact math to tell us. There seem to be arguments to both. I assumed that because in the pro replays I watch I always see them building worker first, that there had to be empirical evidence that it was a benefit.
It seems while getting the worker done will get you that one worker's extra mins in sooner, the guy who sends first will only ever be one worker's worth behind, although his income will hit sooner each time, so he'll be ahead in minerals altogether by a fraction each time.
@ Kantutan -- Your logic doesn't make sense regarding always wanting to never have excess minerals--it just means that whenever your build order requires something, your excess minerals will be applied then--yes you may have more minerals than you need at first, but then maybe when that first gateway's time is come, you'll be using them there to get it up a fraction of a second sooner.
|
Aite, this is what i do, it might not work for you but it works for me.
With some practice, this works great:
Build worker.
Spam f1 while right clicking mineral patches, thus assigning each one to a seperate patch.
GL!
|
Kennigit
Canada19447 Posts
|
I don't know if the numbers show it, but it just intuitively seems faster to build a worker first.
This is why I think it's faster:
If I build a worker, then box my units and click a mineral field, the worker is building while I micro. If I box my units and click a mineral field, the worker is not building while I micro. It takes more time to box and click a mineral field than to build a worker.
|
It extends far into the late-game though. If your first worker was made .5 seconds earlier, then every worker after that will be made faster as well, meaning they got in that much more mining time. Since constant worker production often doesn't stop until at least 15 food, it means you would have over 8 workers mining sooner rather than the 6 mining sooner using the method of sending your workers first.
|
On July 24 2010 15:58 Kantutan wrote: It extends far into the late-game though. If your first worker was made .5 seconds earlier, then every worker after that will be made faster as well, meaning they got in that much more mining time. Since constant worker production often doesn't stop until at least 15 food, it means you would have over 8 workers mining sooner rather than the 6 mining sooner using the method of sending your workers first.
When creating a worker first, you often have a very, very slight supply block around when the supply depot/pylon comes up. This would be negated there. Edit: the effect would not be cumulative anyway
This is another reason I prefer sending workers first (although just for aesthetic reasons) - the second your scv pops out you can make a supply depot, and you encounter not even a moment of supply block. Makes builds feel a little bit more well-oiled.
|
KevinIX your logic is sound and I considered that too. It is a shorter micro to let's say click Nexus then tap E than to group probes send and then split. So the shorter micro is done first, as opposed to the longer then the shorter.
@ Kantutan -- I thought initially that the gain for the person who is "ahead" in worker count would be cumulative, but on deeper thought I believe it isn't.
|
|
|
|