|
On July 24 2010 17:10 Clipse wrote:
Sending first will give a 3 mineral advantage at the start however the first worker, and any subsequent worker will be delayed by .5 seconds, so the advantage of sending first will be lost at .5 minerals per worker built. So sending first and building first will be even at 12 supply and building first will be at an advantage after that.
Edit: see below
|
What about gather, build, then split?
|
On July 24 2010 16:04 FC.Strike wrote:Show nested quote +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. I believe this argument is fallacious. Let's say we have one nexus start making workers nonstop. We have a second nexus making workers nonstop start exactly one second after the first one. The first nexus won't pull extremely far ahead of the second nexus - instead the first nexus will only be one second ahead in minerals of the second one. Since we're assuming that the queue worker -> send workers procedure takes about a half second, the other way will only be a half second ahead of this method. That half second of having that extra worker results in a ~1/2 mineral gain while sending workers first results in 3 extra minerals. There may be other factors which play into the whole build worker / send workers first debate, but your argument is not one of them. Most of them have to do with human reaction time, splitting, etc.
This is the fallacious argument.
I'd do the math but it gets all messed up because 1min/s is a huge overestimate, so here's the verbal explanation instead:
Mining occurs at a rate equal to P*K, where P=number of probes and K is a constant minerals/seconds rate for each probe. Let this rate be designated "Rm", and be measured in minerals/second. Total minerals (Mt) accumulated are thus equal to:
Mt = Rm*T (where T is time in seconds)
If we build our worker first, and then send workers, there will be a delay of a certain duration. Let us call this delay "d". In essence, this means that the "T" term in our total minerals function is offset from a start at 0 by d seconds, thus:
Mt1 = Rm*(T-d)
If we build our worker after sending workers, "d" has a value of 0, so T starts at a true 0. Thus:
Mt2 = Rm*T
Workers take 17 seconds to build (I believe). Thus, assuming constant worker production, P increases by 1 every 17 seconds.
If we build our worker first, our 7th worker begins mining at T = 17. At this point, our mineral totals are:
Mt1 = Rm*(17-d) = 17Rm - 17d
Mt2 = Rm*(17) = 17Rm
Send first is in the lead by an amount that scales with the length of the delay we assume. However, if we build our worker second, our 7th worker is not out until T = 17 + d
Thus, there is an interval equal in length to d where worker first is mining at a higher rate than send first.
Crucially, this interval occurs every 17 seconds while constant worker production is maintained. Every time this interval occurs, worker first builds gain Mt relative to send first.
This will only compound for a small amount, because after 15 or so food you're building so much other stuff that there is likely no relevant difference in how fast you get probes out except for the initial delay. In theoretical terms, however, it will continue to increase in size until the end of constant probe production - and it will get you to critical mineral thresholds correspondingly faster.
The threshold that makes send first the correct choice is a d value such that the total gain is less than however much 6 workers mine in d seconds, and the thing is that higher d values increase the rate at which worker first gains on send first.
I'm not good enough at math to prove this, but I am pretty sure it is mathematically demonstrable that for any value of d worker-first is a better choice.
[edit] Nevertheless I will embarass myself by trying to do it:
We have our rate of increase of 1 per 17 seconds, stepwise, and we have an interval of d where worker first is mining with N+1 probes compared to send-first's N probes.
We have a rate of mining per probe, K.
Thus, every 17 seconds, worker-first gains dK minerals relative to send-first, which has gained 6dK minerals as a result of the send-first decision (6 probes, d delay, K rate per probe).
For worker-first to break even with send-first, we must thus achieve 6 intervals*, namely, make 6 probes - which I believe is pretty much guaranteed in most non-ridiculous build orders anyway (even the 2stalker opening stops at 15 probes).
*In fact slightly less, because over such a short period there will be compounding, but probably something like 5.9dK would be necessary so whatever.
There is a very slight kink in this, namely the pylon/depot/overlord. Again, in theory, worker-first will get you to 100min faster than send-first - but given the minimal size of d for most players, almost any delay in building could well wipe out some or all of the advantage (I'm not quite sure on this).
So I have in fact discovered that the key decision is not "how big is my d value" but "can I build 6 or more probes nonstop with no mistakes", contingent on what, precisely, happens if you fuck up pylon/depot/overlord timing.
[edit2] This also, obviously, assumes an absolutely perfect 1-1-1-1-1-1 split, although barring oddities with the AI it should hold true for any given split as long as the split is constant across both options.
[edit3] Goddamnit, I'm supposed to be in bed. However, if we assume that the same player is doing these two things, musn't we also assume that he will fuck up the pylon/depot/overlord timing by an equal amount in both cases? If we do, the timing no longer matters except if we want to keep considering compounding (which I don't think we do since it will be minimal in all real situations).
[edit4] Why do I nerd out on math when I hate it so much? I should also point out here that this doesn't actually conclusively prove my point - we are assuming a mining rate for workers which is an idealization - the function for minerals returned by a probe is stepwise, not continuous, and this will throw wrenches into conclusions drawn from an assumption of continuity.
|
I wish I weren't in summer mindless mode so I could actually think properly about these things. Meh :<
|
On July 24 2010 17:27 kzn wrote:Show nested quote +On July 24 2010 16:04 FC.Strike wrote: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. I believe this argument is fallacious. Let's say we have one nexus start making workers nonstop. We have a second nexus making workers nonstop start exactly one second after the first one. The first nexus won't pull extremely far ahead of the second nexus - instead the first nexus will only be one second ahead in minerals of the second one. Since we're assuming that the queue worker -> send workers procedure takes about a half second, the other way will only be a half second ahead of this method. That half second of having that extra worker results in a ~1/2 mineral gain while sending workers first results in 3 extra minerals. There may be other factors which play into the whole build worker / send workers first debate, but your argument is not one of them. Most of them have to do with human reaction time, splitting, etc. + Show Spoiler +
This is the fallacious argument.
I'd do the math but it gets all messed up because 1min/s is a huge overestimate, so here's the verbal explanation instead:
Mining occurs at a rate equal to P*K, where P=number of probes and K is a constant minerals/seconds rate for each probe. Let this rate be designated "Rm", and be measured in minerals/second. Total minerals (Mt) accumulated are thus equal to:
Mt = Rm*T (where T is time in seconds)
If we build our worker first, and then send workers, there will be a delay of a certain duration. Let us call this delay "d". In essence, this means that the "T" term in our total minerals function is offset from a start at 0 by d seconds, thus:
Mt1 = Rm*(T-d)
If we build our worker after sending workers, "d" has a value of 0, so T starts at a true 0. Thus:
Mt2 = Rm*T
Workers take 17 seconds to build (I believe). Thus, assuming constant worker production, P increases by 1 every 17 seconds.
If we build our worker first, our 7th worker begins mining at T = 17. At this point, our mineral totals are:
Mt1 = Rm*(17-d) = 17Rm - 17d
Mt2 = Rm*(17) = 17Rm
Send first is in the lead by an amount that scales with the length of the delay we assume. However, if we build our worker second, our 7th worker is not out until T = 17 + d
Thus, there is an interval equal in length to d where worker first is mining at a higher rate than send first.
Crucially, this interval occurs every 17 seconds while constant worker production is maintained. Every time this interval occurs, worker first builds gain Mt relative to send first.
This will only compound for a small amount, because after 15 or so food you're building so much other stuff that there is likely no relevant difference in how fast you get probes out except for the initial delay. In theoretical terms, however, it will continue to increase in size until the end of constant probe production - and it will get you to critical mineral thresholds correspondingly faster.
The threshold that makes send first the correct choice is a d value such that the total gain is less than however much 6 workers mine in d seconds, and the thing is that higher d values increase the rate at which worker first gains on send first.
I'm not good enough at math to prove this, but I am pretty sure it is mathematically demonstrable that for any value of d worker-first is a better choice.
[edit] Nevertheless I will embarass myself by trying to do it:
We have our rate of increase of 1 per 17 seconds, stepwise, and we have an interval of d where worker first is mining with N+1 probes compared to send-first's N probes.
We have a rate of mining per probe, K.
Thus, every 17 seconds, worker-first gains dK minerals relative to send-first, which has gained 6dK minerals as a result of the send-first decision (6 probes, d delay, K rate per probe).
For worker-first to break even with send-first, we must thus achieve 6 intervals*, namely, make 6 probes - which I believe is pretty much guaranteed in most non-ridiculous build orders anyway (even the 2stalker opening stops at 15 probes).
*In fact slightly less, because over such a short period there will be compounding, but probably something like 5.9dK would be necessary so whatever.
There is a very slight kink in this, namely the pylon/depot/overlord. Again, in theory, worker-first will get you to 100min faster than send-first - but given the minimal size of d for most players, almost any delay in building could well wipe out some or all of the advantage (I'm not quite sure on this).
So I have in fact discovered that the key decision is not "how big is my d value" but "can I build 6 or more probes nonstop with no mistakes", contingent on what, precisely, happens if you fuck up pylon/depot/overlord timing.
[edit2] This also, obviously, assumes an absolutely perfect 1-1-1-1-1-1 split, although barring oddities with the AI it should hold true for any given split as long as the split is constant across both options.
I never thought I'd end up eating my own words on an online forum. But indeed, I have.
The mistake I made was in assuming that economic growth was linear, when in reality it's not at all linear. Instead, the rate of change of growth can be fitted to a linear regression.
My mistake becomes exceedingly obvious with a very simple test, which I've reproduced in excel:
![[image loading]](http://i30.tinypic.com/210ka5t.png)
The first group represents an object which begins moving before the second group begins moving. The groups both accelerate at the same rate (1 unit / unit time), but the second group is given a small head start. After a certain amount of time, the advantage the first group gets in starting the acceleration process first exceeds the advantage given by the second group getting the slight head start.
How deeply embarrassing. I suppose I need to cross check what I'm saying before I actually say it. Thanks for the clarification.
What We Can Conclude: Sending workers first is beneficial if your build ever has you getting supply blocked in the first ~12 or so supply. However if your build never has you getting supply blocked, it's superior to build the worker first and then send your workers. I believe somebody else in this thread touched on that point - he's entirely correct.
Edit: It's probably not even worth taking all of these additional factors into account. In the end it makes such a small difference that it's not even worth losing sleep over. The only reason I followed up on this thread was because I was so outrageously wrong. Made me a sad panda :[
|
depends also on races, with zerg i like to split first, cause im able to build more workers at the same time, with terran protoss i first build the worker
|
On July 24 2010 17:21 iEchoic wrote:Show nested quote +On July 24 2010 17:10 Clipse wrote:
Sending first will give a 3 mineral advantage at the start however the first worker, and any subsequent worker will be delayed by .5 seconds, so the advantage of sending first will be lost at .5 minerals per worker built. So sending first and building first will be even at 12 supply and building first will be at an advantage after that. Read thread, this has been disproven.
Because of an earlier start to probe production, there will always be a small window when a new probe is produced, for .5 seconds the build probe first person will have an extra probe then the send probes first person, and therefor the income of the build first person will be higher for .5 seconds each time a new probe is produced, this eventually adds up to negate the advantage of the send first person by the 12th probe and eventually leads to the build first person having an advantage.
The graphs below are there to illustrate my point:
![[image loading]](http://www.4freeimagehost.com/resized/cec7be72d171.jpg)
|
[EDIT] the post above me presents it the best, IMO. Read that.
This statement for "Mining-first" was made earlier
On July 24 2010 15:54 iEchoic wrote:(...)
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.
(...)
The argument is correct on most accounts except one; when your first worker comes out 1 second earlier, your second worker will start building earlier and come out 1 second earlier as well.
If it takes 10 seconds to do your second action, mining before building gives an extra 60 seconds of worker time. Building before mining gives you an extra 10 seconds of worker time AND the second worker will come out 10 seconds earlier, also granting an extra 10 seconds of worker time. This grants 10 extra seconds of worker time PER WORKER; thus, by the 6th worker built, (assuming continuous production), it will have leveled out, and beyond the 6th worker built, building-first has the advantage, until saturation.
What this means is that a build that wants minerals fast within the first 90 seconds of a game should send workers first, but a build that can afford to be 10 minerals or so behind for the first 90 seconds will eventually pull ahead.
(This is all pure theorycraft. In reality, none of this matters; half a second of build time really is not significant)
[EDIT] the post above me presents it the best, IMO. Read that.
|
I solve this problem by not building workers at all until I have floated my command center to an island.
|
So that means, while playing protoss mining first is always superior because i have to halt probe production for the first pylon anyways? Excellent, so I dont have to change my habit :>
|
What many people have failed to account for is that boxing workers to send them is inefficient. Especially if you send first, it's much better to use ctrl+f1 (selects all idle workers) to select your workers and send them. You can also already hold down ctrl+f1 in the load screen so that your workers will be selected a split second earlier.
I did some testing with zerg on this and concluded that sending first is superior on maps with long mining distances (such as dessert oasis) and both methods are about even on maps with shorter mining distances (such as steppes of war).
I prefer to send my workers first, since when I built a drone first, I often pressed SD too quickly for the game to realise, resulting in no drone being built. Sending first is a lot less prone to errors as you can take slightly more time to press SD and if indeed no drone ends up being built, you realise this immediately.
|
On July 24 2010 20:41 Drunken.Jedi wrote:
What many people have failed to account for is that boxing workers to send them is inefficient. Especially if you send first, it's much better to use ctrl+f1 (selects all idle workers) to select your workers and send them. You can also already hold down ctrl+f1 in the load screen so that your workers will be selected a split second earlier.
I did some testing with zerg on this and concluded that sending first is superior on maps with long mining distances (such as dessert oasis) and both methods are about even on maps with shorter mining distances (such as steppes of war).
I prefer to send my workers first, since when I built a drone first, I often pressed SD too quickly for the game to realise, resulting in no drone being built. Sending first is a lot less prone to errors as you can take slightly more time to press SD and if indeed no drone ends up being built, you realise this immediately. More importantly, for zerg the crucial point is when you start your second worker.
The reason for this is that while larvae respawn in 15 seconds, a worker takes 17 seconds to build and with your starting 6 workers it will take them roughly 16 seconds to mine 50 minerals from the second you send them to mine.
This means that you are larvae capped until your second worker is started but not thereafter. Meaning for every second you delay that second drone is a second that your following drones and zerglings and what have you are delayed since most builds are designed to completely avoid larvae wasting.
TLDR: For zerg, send workers first and make sure you build your second worker as soon as you hit 50 minerals, it will make sure that your larvae cycle starts as soon as possible.
|
On July 24 2010 20:41 Drunken.Jedi wrote:
What many people have failed to account for is that boxing workers to send them is inefficient. Especially if you send first, it's much better to use ctrl+f1 (selects all idle workers) to select your workers and send them. You can also already hold down ctrl+f1 in the load screen so that your workers will be selected a split second earlier.
I did some testing with zerg on this and concluded that sending first is superior on maps with long mining distances (such as dessert oasis) and both methods are about even on maps with shorter mining distances (such as steppes of war).
I prefer to send my workers first, since when I built a drone first, I often pressed SD too quickly for the game to realise, resulting in no drone being built. Sending first is a lot less prone to errors as you can take slightly more time to press SD and if indeed no drone ends up being built, you realise this immediately.
I really notice this as zerg - having to press s then d means that to be 'perfect' you have to time your execution to your loading. Where as with other races you can just hold down one button and know your worker will be started.
because of this mechanical issue I think worker first makes sense to me.
but assuming non zerg or perfect execution with it seems that worker first is best for the first part of the game until the combined number of a new worker waves catches up and eventuallys takes over.
|
|
|
You all have missed the most important thing. In the "build order" after the game there is no way to get your worker at 00.00 if you send first.
And the actual difference is so small that it doesnt really matter. So go ahead and build first to work that E-Peen.
|
Here's a real practical application of this theory crap (we assume the player is a pro who makes no mistakes microing):
The first player to get a pylon started wins, but the ninth probe must be building before the pylon can be constructed. Which strategy, send first, or make first, allows for the 9 pylon to START earlier? I don't care if it's only a fraction of a second: This way I'm looking at the benefit in the shortest term. Can anyone say that one(send first) or the other(make first) would allow me to lay the pylon earlier than the other once I'm at 9/10?
|
Here's how I'm going to look at it.
Suppose it takes you one second to split and send your workers and produce the first worker, no matter which order you do it in.
Having both done immediately upon start is obviously superior to both actions.
Having both done 1 second after start is obviously inferior to both actions.
The difference between the two options is less than that of being one second behind - probably much less. (Actually you can further restrict this bound to the time it takes to perform the longer action)
On July 24 2010 18:05 FC.Strike wrote:
The first group represents an object which begins moving before the second group begins moving. The groups both accelerate at the same rate (1 unit / unit time), but the second group is given a small head start. After a certain amount of time, the advantage the first group gets in starting the acceleration process first exceeds the advantage given by the second group getting the slight head start.
The distance between the two is growing, but that's because both are accelerating. At the same time, the difference in time between the two is remaining constant.
Actually, now that I look at it, you have it set up a bit differently.
The one that starts with a higher initial velocity has effectively a time advantage. It's as though he started moving one second earlier. For the other guy, who starts with a distance advantage, that translates into a smaller and smaller time advantage as the velocity increases (time advantage = distance/speed).
The main point is, that the advantage of doing the correct order does NOT provide any sort of snowballing effect.
If acceleration is maintained throughout the game (e.g. constant worker production), then that advantage (distance) will build up. You may have as much as 50 extra minerals! By the time your workers have already harvested 5000, of course. The instant you stop worker production, your advantage (distance) stops increasing.
This is somewhat like premature optimization - trying to cut CPU cycles when your bottleneck is in your I/O.
On July 25 2010 01:18 CitanZero wrote:
Here's a real practical application of this theory crap (we assume the player is a pro who makes no mistakes microing):
The first player to get a pylon started wins, but the ninth probe must be building before the pylon can be constructed. Which strategy, send first, or make first, allows for the 9 pylon to START earlier? I don't care if it's only a fraction of a second: This way I'm looking at the benefit in the shortest term. Can anyone say that one(send first) or the other(make first) would allow me to lay the pylon earlier than the other once I'm at 9/10?
How long would you say it takes to do each micro action? Let's say .25 seconds for each.
The most effect you'd get out of it is placing the pylon 0.25 seconds earlier, and it's likely to be much smaller than that.
I realize that's not what you're asking for. Then in that case, what assumptions you do want to make on how long each separate action takes? Also how quickly do workers mine - Is that 1min/second on average?
Going with a (time to build), b (time to send), x min/second, ignoring the practical implications that workers don't provide a continuous stream of minerals but are discrete, ignoring that different mineral patches have different distances, time loss from workers navigating to patches (that stuff should cancel out, but will affect the value of x):
Initial benefit from sending workers first: 6*a (distance)
Temporal advantage from sending workers first: 6*a/w, where w is the number of workers produced - that is, 3 at nine pylons.
Benefit from building first: b (temporal)
So the difference [temporal] is 2*a [Send workers first] vs. b at the 9 worker pylon mark.
Using assumptions of .5, .5, 1, wait, .5 seconds?
Okay, you divide that value by 6 to get the real time advantage. Or more, maybe 9. I've kinda lost track of my units.
|
Make probe then send. Always have.
|
Conclusion:
If you ever get supply blocked in your first 12 supply or so, send workers first. The small burst of extra minerals will allow you to get that supply a little bit earlier.
If you DON'T get supply blocked in your first 12 supply or so, build the worker first. The small time advantage where you kick start your economy is superior to the small burst of extra minerals.
If you're cool, are banging hot girls every night, and love bananas, you should do whatever you want because it really doesn't matter. And who doesn't love bananas?
|
I usually make drone first, out of habit... plus it's what most pros do.
|
|
|
|
|
|
EPT![[image loading]](http://www.4freeimagehost.com/resized/8c7735031d05.jpg)
![[image loading]](http://www.4freeimagehost.com/resized/7b538df727e7.jpg)
![[image loading]](http://www.4freeimagehost.com/resized/70fdba3b583b.jpg)
