• Log InLog In
  • Register
Liquid`
Team Liquid Liquipedia
EDT 20:36
CEST 02:36
KST 09:36
  • Home
  • Forum
  • Calendar
  • Streams
  • Liquipedia
  • Features
  • Store
  • EPT
  • TL+
  • StarCraft 2
  • Brood War
  • Smash
  • Heroes
  • Counter-Strike
  • Overwatch
  • Liquibet
  • Fantasy StarCraft
  • TLPD
  • StarCraft 2
  • Brood War
  • Blogs
Forum Sidebar
Events/Features
News
Featured News
TL.net Map Contest #21: Voting10[ASL20] Ro4 Preview: Descent11Team TLMC #5: Winners Announced!3[ASL20] Ro8 Preview Pt2: Holding On9Maestros of the Game: Live Finals Preview (RO4)5
Community News
Chinese SC2 server to reopen; live all-star event in Hangzhou8Weekly Cups (Oct 13-19): Clem Goes for Four0BSL Team A vs Koreans - Sat-Sun 16:00 CET6Weekly Cups (Oct 6-12): Four star herO85.0.15 Patch Balance Hotfix (2025-10-8)80
StarCraft 2
General
Chinese SC2 server to reopen; live all-star event in Hangzhou RotterdaM "Serral is the GOAT, and it's not close" DreamHack Open 2013 revealed The New Patch Killed Mech! Team Liquid Map Contest #21 - Presented by Monster Energy
Tourneys
$1,200 WardiTV October (Oct 21st-31st) SC2's Safe House 2 - October 18 & 19 INu's Battles #13 - ByuN vs Zoun Tenacious Turtle Tussle Sparkling Tuna Cup - Weekly Open Tournament
Strategy
Custom Maps
Map Editor closed ?
External Content
Mutation # 496 Endless Infection Mutation # 495 Rest In Peace Mutation # 494 Unstable Environment Mutation # 493 Quick Killers
Brood War
General
Is there anyway to get a private coach? BGH Auto Balance -> http://bghmmr.eu/ BW General Discussion The Lose More Card BSL Season 21
Tourneys
300$ 3D!Community Brood War Super Cup #4 [ASL20] Semifinal B Azhi's Colosseum - Anonymous Tournament [Megathread] Daily Proleagues
Strategy
Roaring Currents ASL final [I] Funny Protoss Builds/Strategies Current Meta [I] TvZ Strategies and Builds
Other Games
General Games
Nintendo Switch Thread Stormgate/Frost Giant Megathread Path of Exile Dawn of War IV ZeroSpace Megathread
Dota 2
Official 'what is Dota anymore' discussion LiquidDota to reintegrate into TL.net
League of Legends
Heroes of the Storm
Simple Questions, Simple Answers Heroes of the Storm 2.0
Hearthstone
Deck construction bug Heroes of StarCraft mini-set
TL Mafia
TL Mafia Community Thread SPIRED by.ASL Mafia {211640}
Community
General
Russo-Ukrainian War Thread US Politics Mega-thread The Chess Thread Things Aren’t Peaceful in Palestine Men's Fashion Thread
Fan Clubs
The herO Fan Club!
Media & Entertainment
Series you have seen recently... Anime Discussion Thread [Manga] One Piece Movie Discussion!
Sports
2024 - 2026 Football Thread TeamLiquid Health and Fitness Initiative For 2023 MLB/Baseball 2023 Formula 1 Discussion NBA General Discussion
World Cup 2022
Tech Support
SC2 Client Relocalization [Change SC2 Language] Linksys AE2500 USB WIFI keeps disconnecting Computer Build, Upgrade & Buying Resource Thread
TL Community
The Automated Ban List Recent Gifted Posts
Blogs
Certified Crazy
Hildegard
The Heroism of Pepe the Fro…
Peanutsc
Rocket League: Traits, Abili…
TrAiDoS
Customize Sidebar...

Website Feedback

Closed Threads



Active: 2577 users

Probe first then send, or vice versa - Page 3

Forum Index > StarCraft 2 Strategy
Post a Reply
Prev 1 2 3 4 Next All
iEchoic
Profile Blog Joined May 2010
United States1776 Posts
Last Edited: 2010-07-24 09:39:21
July 24 2010 08:21 GMT
#41
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
vileEchoic -- clanvile.com
Sentient
Profile Joined April 2010
United States437 Posts
July 24 2010 08:23 GMT
#42
What about gather, build, then split?
kzn
Profile Blog Joined June 2007
United States1218 Posts
Last Edited: 2010-07-24 08:52:11
July 24 2010 08:27 GMT
#43
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.
Like a G6
Kantutan
Profile Blog Joined February 2010
Canada1319 Posts
July 24 2010 08:59 GMT
#44
I wish I weren't in summer mindless mode so I could actually think properly about these things. Meh :<
FC.Strike
Profile Blog Joined April 2010
United States621 Posts
Last Edited: 2010-07-24 09:16:05
July 24 2010 09:05 GMT
#45
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]

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 :[
--------------------------> My Smiley Face Disagrees, Your Argument is Invalid -------------------------->
2v2AiSieesch
Profile Joined December 2009
Germany98 Posts
July 24 2010 09:13 GMT
#46
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
Clipse
Profile Joined July 2010
Germany20 Posts
July 24 2010 09:29 GMT
#47
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]

[image loading]
[image loading]

[image loading]


onionchowder
Profile Joined July 2009
United States137 Posts
Last Edited: 2010-07-24 09:52:52
July 24 2010 09:50 GMT
#48
[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.
Eric Guan is a sexy beast
Sabresandiego
Profile Joined July 2010
United States227 Posts
July 24 2010 10:45 GMT
#49
I solve this problem by not building workers at all until I have floated my command center to an island.
Terran
Xanatoss
Profile Joined May 2010
Germany539 Posts
July 24 2010 11:19 GMT
#50
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 :>
The chair slowly turns around. You see his face, but it can't be. He's not supposed to be here. Not him. Not a Protoss. Not THAT Protoss. MC says, "Hi Greg, long time no see." You back slowly out of the booth. But you can't. It's already forcefielded.
Drunken.Jedi
Profile Joined June 2009
Germany446 Posts
July 24 2010 11:41 GMT
#51
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.
Alsn
Profile Joined February 2008
Sweden995 Posts
July 24 2010 14:45 GMT
#52
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.
Machina improba! Vel mihi ede potum vel mihi redde nummos meos!
Galleon.frigate
Profile Blog Joined May 2010
Canada721 Posts
July 24 2010 14:48 GMT
#53
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.
Randomaccount#77123
Profile Blog Joined May 2010
United States5003 Posts
Last Edited: 2010-07-24 15:11:42
July 24 2010 15:06 GMT
#54
--- Nuked ---
xzidez
Profile Joined April 2010
Sweden147 Posts
July 24 2010 15:29 GMT
#55
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.
CitanZero
Profile Blog Joined May 2010
United States56 Posts
July 24 2010 16:18 GMT
#56
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?
Euphemism
Profile Joined June 2010
Canada57 Posts
Last Edited: 2010-07-24 17:32:20
July 24 2010 17:07 GMT
#57
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.
TheAngelofDeath
Profile Blog Joined May 2010
United States2033 Posts
July 24 2010 17:53 GMT
#58
Make probe then send. Always have.
"Infestors are the suck" - LzGamer
FC.Strike
Profile Blog Joined April 2010
United States621 Posts
July 24 2010 17:59 GMT
#59
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?
--------------------------> My Smiley Face Disagrees, Your Argument is Invalid -------------------------->
uberdeluxe
Profile Joined June 2009
Canada306 Posts
July 24 2010 18:16 GMT
#60
I usually make drone first, out of habit... plus it's what most pros do.
No mules, no collosi, no PFs, just LOVE!
Prev 1 2 3 4 Next All
Please log in or register to reply.
Live Events Refresh
PiGosaur Monday
00:00
#54
PiGStarcraft532
Liquipedia
[ Submit Event ]
Live Streams
Refresh
StarCraft 2
PiGStarcraft532
Nathanias 99
StarCraft: Brood War
Britney 11557
Shuttle 725
Artosis 658
Aegong 37
Dota 2
monkeys_forever379
PGG 100
League of Legends
Reynor50
Super Smash Bros
hungrybox307
Other Games
summit1g8668
shahzam691
Day[9].tv510
JimRising 413
C9.Mang0254
ViBE171
Maynarde146
Trikslyr69
Organizations
Other Games
gamesdonequick2010
Counter-Strike
PGL243
Other Games
BasetradeTV62
StarCraft 2
Blizzard YouTube
StarCraft: Brood War
BSLTrovo
sctven
[ Show 19 non-featured ]
StarCraft 2
• davetesta59
• Hupsaiya 56
• HeavenSC 6
• sooper7s
• Migwel
• AfreecaTV YouTube
• LaughNgamezSOOP
• intothetv
• IndyKCrew
• Kozan
StarCraft: Brood War
• Azhi_Dahaki20
• STPLYoutube
• ZZZeroYoutube
• BSLYoutube
League of Legends
• Doublelift4115
• Stunt138
Other Games
• imaqtpie1362
• Scarra883
• Day9tv510
Upcoming Events
Replay Cast
9h 24m
OSC
15h 24m
Tenacious Turtle Tussle
22h 24m
The PondCast
1d 9h
OSC
1d 11h
WardiTV Invitational
2 days
Online Event
2 days
RSL Revival
3 days
RSL Revival
3 days
WardiTV Invitational
3 days
[ Show More ]
Afreeca Starleague
4 days
Snow vs Soma
Sparkling Tuna Cup
4 days
WardiTV Invitational
4 days
CrankTV Team League
4 days
RSL Revival
4 days
Wardi Open
5 days
CrankTV Team League
5 days
Replay Cast
6 days
WardiTV Invitational
6 days
CrankTV Team League
6 days
Liquipedia Results

Completed

Acropolis #4 - TS2
WardiTV TLMC #15
HCC Europe

Ongoing

BSL 21 Points
ASL Season 20
CSL 2025 AUTUMN (S18)
C-Race Season 1
IPSL Winter 2025-26
EC S1
Thunderpick World Champ.
CS Asia Championships 2025
ESL Pro League S22
StarSeries Fall 2025
FISSURE Playground #2
BLAST Open Fall 2025
BLAST Open Fall Qual
Esports World Cup 2025
BLAST Bounty Fall 2025
BLAST Bounty Fall Qual

Upcoming

SC4ALL: Brood War
BSL Season 21
BSL 21 Team A
BSL 21 Non-Korean Championship
RSL Offline Finals
RSL Revival: Season 3
Stellar Fest
SC4ALL: StarCraft II
CranK Gathers Season 2: SC II Pro Teams
eXTREMESLAND 2025
ESL Impact League Season 8
SL Budapest Major 2025
BLAST Rivals Fall 2025
IEM Chengdu 2025
PGL Masters Bucharest 2025
TLPD

1. ByuN
2. TY
3. Dark
4. Solar
5. Stats
6. Nerchio
7. sOs
8. soO
9. INnoVation
10. Elazer
1. Rain
2. Flash
3. EffOrt
4. Last
5. Bisu
6. Soulkey
7. Mini
8. Sharp
Sidebar Settings...

Advertising | Privacy Policy | Terms Of Use | Contact Us

Original banner artwork: Jim Warren
The contents of this webpage are copyright © 2025 TLnet. All Rights Reserved.