So I received a question from agsub quite some time ago, about the effectiveness of Hatch blocking the fast expanding Protoss player. The question is basically, is this strategy worth doing at all, considering the amount of time (and potential mining) invested, and if yes, how rewarding is it.
As always, I prepared a little pdf about the topic with detailed mathematical explanation, which can be found here, and also below in the spoiler tag as images:
EDIT: The calculations were flawed, which resulted in wrong conclusions. I corrected them, now they should be all right. EDIT2: There are still some minor issues with the calculation of the Zerg delay. Will check shortly. EDIT3: Checked again, I think conclusions should be about right.
There are two important conclusions here to say: 1. If you are a Protoss player and you see your natural Hatch blocked, you have two options. Either you want to kill the Hatchery as fast as you can, resulting in as little time delay as possible. In this case, you should pull all your Probes, but it will cause you to lose more mining time than optimal. I only recommend this if you want to hit a very crisp timing which fails even at the slightest of delays. The other option is to kill the Hatchery with as little mining lost as possible. Surprisingly, that does not coincide with the fastest killing of the Hatchery. In this case, you have to pull 8 Probes (provided that you discovered the Hatch very shortly after having been placed). This will result in more time delay than optimal. A good compromise between the two is to bring about 11-12 Probes. That way you will not lose much more minerals than optimal, but you can reduce the time lost quite effectively. In any case, make sure that your opponent won't plant a Hatchery again. 2. Hatch block is no superweapon. It won't give the Zerg player suddenly a tremendous lead, but it will give a slight advantage in both time and minerals, even if the Protoss reacts properly.
So this is my answer, agsub, I hope it suffices . If anyone has any comments, ideas, criticisms, I am open, as always.
I assume this only is for gateway-expanding and nexusfirst protosses? What if the Protoss throws up two cannons at his choke and does not pull probes? Does the math change?
EDIT: In the case of gateway expanding, what about making a zealot and pulling only a few probes? Is there an optimal number of probes to pull when a zealot is present?
On November 04 2014 06:32 linuxguru1 wrote: I assume this only is for gateway-expanding and nexusfirst protosses? What if the Protoss throws up two cannons at his choke and does not pull probes? Does the math change?
EDIT: In the case of gateway expanding, what about making a zealot and pulling only a few probes? Is there an optimal number of probes to pull when a zealot is present?
I specifically thought of Nexus first, but I think it should be the same for any build so long as you only fight with your Probes (because what would change, really). The reason I chose Nexus first is that clearly you lose the most mining time when you have to fight with Probes only, and even then you don't really fall behind. For gateway expand, I am not exactly sure how fast the Zealot would come out, so I can't answer that just yet. For the cannons, I think that is an effective way to kill it, and possibly the Drone even. Worst case is you built two cannons for 300 minerals, one of which you may have built anyway. I don't know, though, do Zergs Hatch block against FFE?
Looking over your math, you appear to only consider a one-way trip for probes to kill (cancel) the hatchery. Is that wrong? Wouldn't mining time lost be equal to (travel time) + (attacking time) + (travel time) for Protoss?
edit: Also building structures do not benefit from armor, as far as I know.
Interesting. I've never seen a protoss pull all his workers. Hatch blocking vs ffe is suicidal in my experience. They can block your natural and even cannon you in since your pool is so late.
On November 04 2014 06:32 linuxguru1 wrote: I assume this only is for gateway-expanding and nexusfirst protosses? What if the Protoss throws up two cannons at his choke and does not pull probes? Does the math change?
EDIT: In the case of gateway expanding, what about making a zealot and pulling only a few probes? Is there an optimal number of probes to pull when a zealot is present?
I specifically thought of Nexus first, but I think it should be the same for any build so long as you only fight with your Probes (because what would change, really). The reason I chose Nexus first is that clearly you lose the most mining time when you have to fight with Probes only, and even then you don't really fall behind. For gateway expand, I am not exactly sure how fast the Zealot would come out, so I can't answer that just yet. For the cannons, I think that is an effective way to kill it, and possibly the Drone even. Worst case is you built two cannons for 300 minerals, one of which you may have built anyway. I don't know, though, do Zergs Hatch block against FFE?
They do against nexus first, but if they see the forge they should not. They sometimes do, which isn't the brightest idea, but there you have it.
2 cannons means you only have to pull a few probes at most to kill it quickly, and it's not even necessary at all if you're quick enough.
You have missed out the cost of bringing the drone at all. In general, if a Zerg is not going to proxy hatch, a drone scout is not often done, as waiting for the overlord to get there is sufficient for scouting purposes. This is important information as that drone will lose ~50min/game minute, which vastly skews the graphs in Protoss' favour unless the Protoss massively overreacts.
Thanks for the replies! It seems, there is at least one (possibly two) sereious flaw in the math.
On November 04 2014 07:58 Synastren wrote: Looking over your math, you appear to only consider a one-way trip for probes to kill (cancel) the hatchery. Is that wrong? Wouldn't mining time lost be equal to (travel time) + (attacking time) + (travel time) for Protoss?
edit: Also building structures do not benefit from armor, as far as I know.
1. You are right, I should have calculated with travel time * 2, about 20 gs. 2. Can you give a source (like Liquipedia) that building structures don't have armor? I thought it may be so but I couldn't find anything. Anyway, I can test it, if there is no source.
I will fix the numbers as soon as I get back home from college, until then, don't believe a thing I wrote .
I always use to block protoss expand onto 3rd and 4th base with overlord creep. And it delays his base for pretty much one minute or so, and that gives me pretty good advantage in many games, especially if he attacked me before in game and I was in disadvantage.
Some questions: - How profitable is it for the Zerg to instantly recreate an evo chamber just after the hatch cancel assuming the protoss reacted best and sent all is probe to kill the hatch ?
- Theoriticaly Protoss should have between 300 and 400 when the hatch block happen, if he send all is probes he might not reach 400 at the hatch cancelation. So he would not be able to build a nexus instantly, leaving the zerg with options to further capitalize with his drone: to prevent building a new hatch the protoss would have to leave at least 4 probes (one at each corner of the nexus position ) or maybe only 3 with the right micro... Anyway to prevent that he could leave like one or two probe mining thus reaching 400 minerals at hatch canceletion, so the better defense might not be sending all his probes ...
What a coincidence... Actually watching a GSL S3 VOD (RO32 DRG vs Stork) and Artosis said he wanted someone to do the math on hatch blocking. And said you'd be his friend forever if you did.
So congrats OP, tweet this to Artosis and claim your lifetime friendship certificate.
Using your own numbers, restated below: 0.7 minerals lost per second not mining per probe 15 probes travel to interrupt hatchery 10s travel time between mining and natural
75 minerals lost for Zerg when cancelling hatchery
So, if Protoss sends 15 probes to interrupt the hatchery, and Zerg cancels the hatchery the moment the 15 probes arrive, we get the following:
Protoss loss = 15probes * 2 directions *10s/direction * 0.7minerals /(s*probe) = 210 minerals Zerg loss = 75 minerals
Edit: The crux of the issue seems to be the way you calculate lost time for the Zerg. It doesn't make sense - losing access to 300 minerals which mostly get refunded for a short while doesn't slow the whole build order down as much as you suggest. He makes back a lot of the time when he gets the refund and builds the third hatchery (for instance) earlier than he otherwise would.
How in the world is pulling all your workers supposed to gain you an advantage?
I was kinda thinking the same thing when I saw that advice. It might be a good idea if the hatch is already done, but otherwise...
and at this point, is there a forge? or is it a gateway opening?
Pulling all the probes appears an advantage because the math considers protoss has in bank the 400 necessary to build a nexus (no delay between hatch cancel and nexus built).
I think if you send all your probes, kill the hatch and then send them back, minimal build delay is 10s travel from main to natural + 11s killing the hatch (less if building hatch has no armor) + 10s travel back from natural to main, which gives 31s compared to the 29s of the zerg.
As stated above, those 29s do not take into account the refund of the 225 upon cancel, which would lower the delay to the 21s between the block and the cancel.
How in the world is pulling all your workers supposed to gain you an advantage?
I was kinda thinking the same thing when I saw that advice. It might be a good idea if the hatch is already done, but otherwise...
and at this point, is there a forge? or is it a gateway opening?
Pulling all the probes appears an advantage because the math considers protoss has in bank the 400 necessary to build a nexus (no delay between hatch cancel and nexus built).
I think if you send all your probes, kill the hatch and then send them back, minimal build delay is 10s travel from main to natural + 11s killing the hatch (less if building hatch has no armor) + 10s travel back from natural to main, which gives 31s compared to the 29s of the zerg.
As stated above, those 29s do not take into account the refund of the 225 upon cancel, which would lower the delay to the 21s between the block and the cancel.
Still needs some work I guess.
If the Protoss has 400 banked, he is losing the exact same time Zerg is losing by having 300 minerals quasi-banked in a to-be-cancelled hatchery. Both are getting their next build delayed. The main difference is that the Zerg is mining while the Protoss isn't. The 75 mineral cancel penalty is much smaller than this.
Besides, how is Protoss supposed to mine 400 in the time Zerg mines 300? Doesn't Zerg start with extra larva? Does Protoss stop building probes to maintain the 400 bank while interrupting the Hatchery, or is he planning to lose Nexus build time as well?
There is a flaw in what you did...Usually when you send a drone and chose to hatch block you already had the hatch block in mind so you wouldn't have sent that drone if you wanted to play "standard". And you didn't take the mining lost by that drone in your calculations. But now, let's see what is really wrong with what you wrote :
The real problem is how you're calculating time lost for both Protoss and Zergs, but let's go with the Protoss player first : he loses way more than 11 gs on his build. He loses 11 gs only to kill the hatchery, but he also loses 20 gs due to pulling his probe to the hatch and getting them back on the mineral line. So he loses 21 gs on the nexus timer (time to pull the probes+kill the hatch), but more than 30 gs on all his "real" tech, which is really bad considering he's exposed to a follow-up attack. In the meantime, the Zerg player doesn't lose 30 gs. He can lose it to his 1st hatch, but his 2nd hatch before pool (if he goes for an econ build and not a follow up because we're trying to see who wins economically/tech after this) will be almost as fast as it would be otherwise. So his tech and econ doesn't get that much delayed.
Edit: basically, I'm quite sure pulling all the probes is the best way to lose the game, be it to a follow-up or to an econ game. And let's face it, when you go for a Nexus first against a hatch block into 3 hatch before pool, you're behind. What's interesting to see is if it's still worth it to hatch block a FFE or 1 Gate-Expand.
On November 04 2014 19:39 Darkwhite wrote: Using your own numbers, restated below: 0.7 minerals lost per second not mining per probe 15 probes travel to interrupt hatchery 10s travel time between mining and natural
75 minerals lost for Zerg when cancelling hatchery
So, if Protoss sends 15 probes to interrupt the hatchery, and Zerg cancels the hatchery the moment the 15 probes arrive, we get the following:
Protoss loss = 15probes * 2 directions *10s/direction * 0.7minerals /(s*probe) = 210 minerals Zerg loss = 75 minerals
Edit: The crux of the issue seems to be the way you calculate lost time for the Zerg. It doesn't make sense - losing access to 300 minerals which mostly get refunded for a short while doesn't slow the whole build order down as much as you suggest. He makes back a lot of the time when he gets the refund and builds the third hatchery (for instance) earlier than he otherwise would.
Honestly it might be worth it anyways if you were to include all of the variables. Is having a second nexus producing probes worth the probe pull? I would guess so, but it would leave you vulnerable to a zergling follow up. If the ling followup wasn't a concern then probably having 2 nexus early would counter the economic damage of pulling all of your probes.
On November 04 2014 06:10 Sholip wrote: 2. Hatch block is no superweapon. It won't give the Zerg player suddenly a tremendous lead. If the opponent reacts properly, it should even be just barely better for him, but definitely not terribly good for the Zerg. The reason why it may still work is it is a surprising, unorthodox move, which may catch the opponent off guard. If he underreacts, it can cause heavy economic deficit, or even cost the game. This stragety should be regarded as a mind game, nothing more.
I see you've edited after some remarks written in this thread, but I still disagree with this. In case of hatch block versus nexus first, the Protoss player is behind, no matter what. Here's why : if the Zerg player goes for an econ build after this, he'll get his 3 hatch before pool in the same time he'd have them without the hatch block, while the Protoss's tech is 30gs late, so he'll get away with his econ build, and he already has delayed the build of the Protoss player (+20gs on the Nexus timer, probe count also delayed) => Zerg is ahead. If Zerg choses to follow up the hatch block with an attack, having delayed the Protoss defenses by 30+ gs, he'll most likely get very far ahead (or win the game).
The real reason why hatch block is no secret weapon is : you have to send a drone do to this strat before knowing what build the opponent is using. In case of 1Gate-expand, you're behind and in case of FFE I don't know (that would be the interesting case imho). That's why it's not that good, because it only counters Nexus first and its kind of a gamble.
I corrected my calculations and edited the OP (twice). According to new calculations, Hatch block does provide the Zerg an advantage in every sense, albeit not a huge one. I will reply to other suggestions soon.
On November 05 2014 00:27 Sholip wrote: I corrected my calculations and edited the OP (twice). According to new calculations, Hatch block does provide the Zerg an advantage in every sense, albeit not a huge one. I will reply to other suggestions soon.
On November 05 2014 00:27 Sholip wrote: I corrected my calculations and edited the OP (twice). According to new calculations, Hatch block does provide the Zerg an advantage in every sense, albeit not a huge one. I will reply to other suggestions soon.
I am still unsure about the zerg delay as described. The scenario is: - 12th? drone pulled - 45gs to the protoss natural - ~20gs to try and morph the hatch - 45gs back to mining
During 45gs of the drone pull, you produce 4 drones and harvest the 300 minerals for the hatch block. During the 20gs of the block, you have ~15 drones mining that harvest 15*0.7*20=210 minerals At mid-block, you pull a drone to create your natural At time of cancel, you add to that 225, making 428 minerals and put down your expand, leaving 128 minerals in bank for the next structure.
This means ~23gs delay on the first structure (3gs linked to the mining time lost of the scouting drone) and ~11,5gs delay on the second structure (because of the 128 already mined).
2. Hatch block is no superweapon. It won't give the Zerg player suddenly a tremendous lead, but it will give a slight advantage in both time and minerals, even if the Protoss reacts properly.
Surely this is a balance issue then? I mean if even a proper reaction to it results in a guaranteed loss there is basically no reason to not do it against a Protoss trying to fast expand? Or am I missing something here?
But if that's the case...wouldn't a proper response therefore be to NOT expand and instead pressure in response to this, given that a "proper fast expand" response puts you behind? It just seems very strange to simply accept that this always puts the Protoss behind.
I think the real value behind this strategy is of how awkward of a situation you put most Protoss in, and as a Zerg player who has experience doing this, you can exploit the Protoss player, and force him to react to the Zerg from this point on, and not the other way around which is 95% of PvZ.
On November 05 2014 00:27 Sholip wrote: I corrected my calculations and edited the OP (twice). According to new calculations, Hatch block does provide the Zerg an advantage in every sense, albeit not a huge one. I will reply to other suggestions soon.
I am still unsure about the zerg delay as described. The scenario is: - 12th? drone pulled - 45gs to the protoss natural - ~20gs to try and morph the hatch - 45gs back to mining
During 45gs of the drone pull, you produce 4 drones and harvest the 300 minerals for the hatch block. During the 20gs of the block, you have ~15 drones mining that harvest 15*0.7*20=210 minerals At mid-block, you pull a drone to create your natural At time of cancel, you add to that 225, making 428 minerals and put down your expand, leaving 128 minerals in bank for the next structure.
This means ~23gs delay on the first structure (3gs linked to the mining time lost of the scouting drone) and ~11,5gs delay on the second structure (because of the 128 already mined).
The 29gs is an overestimate.
But great work as is !
The way I thought is the following: - You pull the Drone so that it reaches the opponent's natural when you have 300 minerals. - Then you plant the Hatch block. With a Hatch first, you would put down your expansion now (actually, even before that, as you would have slightly more income if you hadn't sent out the Drone, but let's neglect that). But instead, you have to wait until you have the money to expand. Now that I think about it, I think I made a mistake here. I thought you have to wait until you have 300 minerals again (at least 29 gs), but in reality, you only have to wait until you cancel the block, which is about 13...23 gs depending on how many Probes the Protoss pulls. If you cancel the Hatch, you will immediately have 300 minerals, so your natural Hatchery will most likely be 23 gs late at most (if you don't account for the delay caused by the Drone sent out, which may also be some game seconds). Is that what you were referring to? I have to correct it once again, it seems. Does that mean, though, that it is even better for the Zerg than anticipated?
2. Hatch block is no superweapon. It won't give the Zerg player suddenly a tremendous lead, but it will give a slight advantage in both time and minerals, even if the Protoss reacts properly.
Surely this is a balance issue then? I mean if even a proper reaction to it results in a guaranteed loss there is basically no reason to not do it against a Protoss trying to fast expand? Or am I missing something here?
But if that's the case...wouldn't a proper response therefore be to NOT expand and instead pressure in response to this, given that a "proper fast expand" response puts you behind? It just seems very strange to simply accept that this always puts the Protoss behind.
i dont think it puts the protoss behind if you opened 1gate fe or ffe, it only really seems that effective vs nexus first in wich case its not so much a balance issue as punishing greed ( as a cannon rush punishes 15 hatch)
if a protoss just leaves a probe on a spot that will completely block the contruction of a hatch, they can prevent a zerg from doing a hatch block in the first place.
2. Hatch block is no superweapon. It won't give the Zerg player suddenly a tremendous lead, but it will give a slight advantage in both time and minerals, even if the Protoss reacts properly.
Surely this is a balance issue then? I mean if even a proper reaction to it results in a guaranteed loss there is basically no reason to not do it against a Protoss trying to fast expand? Or am I missing something here?
But if that's the case...wouldn't a proper response therefore be to NOT expand and instead pressure in response to this, given that a "proper fast expand" response puts you behind? It just seems very strange to simply accept that this always puts the Protoss behind.
i dont think it puts the protoss behind if you opened 1gate fe or ffe, it only really seems that effective vs nexus first in wich case its not so much a balance issue as punishing greed ( as a cannon rush punishes 15 hatch)
2. Hatch block is no superweapon. It won't give the Zerg player suddenly a tremendous lead, but it will give a slight advantage in both time and minerals, even if the Protoss reacts properly.
Surely this is a balance issue then? I mean if even a proper reaction to it results in a guaranteed loss there is basically no reason to not do it against a Protoss trying to fast expand? Or am I missing something here?
But if that's the case...wouldn't a proper response therefore be to NOT expand and instead pressure in response to this, given that a "proper fast expand" response puts you behind? It just seems very strange to simply accept that this always puts the Protoss behind.
It only works against Nexus first, not FFE or 1Gate expand, and you basically have to plan to hatch block before knowing what's the Protoss doing. So there's absolutely no balance issue here, if the Protoss player gets too greedy and the Zerg player anticipated then the Zerg player is ahead, and that's how it should be.
On November 05 2014 03:01 Sholip wrote: If you cancel the Hatch, you will immediately have 300 minerals, so your natural Hatchery will most likely be 23 gs late at most (if you don't account for the delay caused by the Drone sent out, which may also be some game seconds). Is that what you were referring to?
This is what I meant, but it is a consequence of the fact that you have to take into account in the zerg income both the mining of 15 drones and the spike of the cancel.
First impact is that natural goes down as soon as hatch is canceled as you mention.
Second impact is that up to 29gs between hatch placed and hatch canceled, the delay impacts both protoss and zerg builds: if you pull 9 probes, you are delayed overall for 38gs and the zerg natural is delayed 28gs. If you are pulling 12, you are delayed 31gs, and the zerg natural is delayed 21gs.
Third impact is that the delay is on the protoss build as a whole, not for the zerg. Once natural is down, zerg still has a growing unspent bank and the next structure is not as delayed: If 9 probes were pulled, when hatch is canceled at 38gs zerg bank is ~300+225, which can mean natural+pool down already, or 3rd hatch 75 minerals away.
I edited the OP once again, the Zerg delay should be 23 gs on the natural Hatch. To examine the effects of delayed expansion and lost mining time, I will do a write-up on these kinds of economic impacts in the next few weeks or so (already in the making, but... college). I hope it will help get across my whole concept better (and that it will give me, as well, a better understanding of the whole thing).
2. Hatch block is no superweapon. It won't give the Zerg player suddenly a tremendous lead, but it will give a slight advantage in both time and minerals, even if the Protoss reacts properly.
Surely this is a balance issue then? I mean if even a proper reaction to it results in a guaranteed loss there is basically no reason to not do it against a Protoss trying to fast expand? Or am I missing something here?
But if that's the case...wouldn't a proper response therefore be to NOT expand and instead pressure in response to this, given that a "proper fast expand" response puts you behind? It just seems very strange to simply accept that this always puts the Protoss behind.
It only works against Nexus first, not FFE or 1Gate expand, and you basically have to plan to hatch block before knowing what's the Protoss doing. So there's absolutely no balance issue here, if the Protoss player gets too greedy and the Zerg player anticipated then the Zerg player is ahead, and that's how it should be.
The zerg player loses very little by sending out their 12th drone, there's basically no reason NOT to try this out every game. It's still not a balance issue though, if it becomes common, Toss will simply block the hatch which is pretty easy to do it you are ready for it, IMO.
I couldn't see this but I may have missed it. I think technically you must also consider the fact that after you force a cancel on the hatch, the drone is still there and therefore you are actually losing several more seconds before you can plant your nexus. I don't know how you would measure that given the worker dance of the drone blocking a nexus, in the same way that a probe blocks a hatch could be nothing to several gs.
men are you are why starcraft is awesome, eat that MOBA lovers
hi, also question : shouldnt the optimal timing be you pulling probes at a cost of NOT affecting your probe/pylon production (macro)? if you pull the 'optimal' amount as you stated are you still able to do your probes/pylon without delay?
Will you be extending your work to include other openers at some point? The results versus NF don't appear all that unexpected to me personally ( based on previous testing of NF versus the opener). However what does seem uncertain, and perhaps debatable among Protoss players, is what's the most optimal response when opening 1 gate. Everyone seems to have a slightly different response; perhaps looking at this might help some players greatly.
Also concerning kv's comment: I think what the op might mean in that first conclusion is that pulling all probes is beneficial if there is no error correction by the zerg for pre-pulled probes. More or less I think he's assuming that the hatch goes down the moment your probes get there and start attacking - which is not realistic at all. Any player at a decent level can tell you that this situation will basically never happen (or if it does, then zerg cancels the hatch); making the first conclusion practically useless (assuming I didn't misidentify the assumption).
However, the second conclusion seems pretty useful - having a ballpark number of around ~8 probes for an "early" spot and ~11-12 for a later spot will probably help some people. Thanks for your work op!
On November 14 2014 07:57 Poo wrote: Cool! Math modeling applied to SC2, that's dope!
Will you be extending your work to include other openers at some point? The results versus NF don't appear all that unexpected to me personally ( based on previous testing of NF versus the opener). However what does seem uncertain, and perhaps debatable among Protoss players, is what's the most optimal response when opening 1 gate. Everyone seems to have a slightly different response; perhaps looking at this might help some players greatly.
Also concerning kv's comment: I think what the op might mean in that first conclusion is that pulling all probes is beneficial if there is no error correction by the zerg for pre-pulled probes. More or less I think he's assuming that the hatch goes down the moment your probes get there and start attacking - which is not realistic at all. Any player at a decent level can tell you that this situation will basically never happen (or if it does, then zerg cancels the hatch); making the first conclusion practically useless (assuming I didn't misidentify the assumption).
However, the second conclusion seems pretty useful - having a ballpark number of around ~8 probes for an "early" spot and ~11-12 for a later spot will probably help some people. Thanks for your work op!
This applies to most openers because when the hatchery goes down to block your expand, the only units you can have out to attack it are probes.
With a gateway expand you will get a zealot out towards the end, but if you spot it early and pull probes with the magic number 8, the results are very close to what OP wrote. It will be slightly less so in zerg favor however because of the added DPS of the zealot, but in zerg favor regardless.
On August 24 2015 12:50 Joedaddy wrote: love your posts~ but, being as I am a complete tard with the maths..... I wish there was a 1 paragraph "Yes (or No) "X" is a good/marginal/bad thing.
Thanks. It is not always easy to draw a simple conclusion in a game as complex as Starcraft. In this case, the conclusion should be that if you are being Hatch blocked, you should not pull less than 8 Probes to kill it (if you plan to kill it with Probes only), but even better to pull 10-12. Also, it seems that this strategy is slightly better for the Zerg, in that they lose less than the Protoss does, compared to a standard build order.
What does it mean for the Zerg player? If Protoss brings 7 or fewer probes, let the hatch finish, 8 or more cancel it? Should the Zerg always try and complete the hatch, if possible? What if it's a gateway first?