[DISCOVERY] 2x high templar feedback - older dies

On July 26 2012 05:08 zhurai wrote:

... the older high templar has more energy because he's been around more.....

so?

On July 26 2012 05:09 willoc wrote:
Sweet find!

I was originally born in Poland and can still speak it fluently, would you be able to share a link to this Polish SC2 'Mythbusters' show?

Edit: You beat my request!

On July 26 2012 05:08 zhurai wrote:

... the older high templar has more energy because he's been around more.....

so?

On July 26 2012 05:09 Gorilla23 wrote:


I haven't watched the video, but I'm assuming both HTs had full energy at the time of this test.

EDIT: I now have, and my assumption was correct.

On July 26 2012 05:15 Grumbels wrote:
If you want to investigate something else, can you discover if there is a pattern as to which of the starting workers would count as 'older'? It would be funny if it would become correct play to keep an eye on your 'oldest' worker and use that one to scout. After all, if you're playing a mirror and you're attack-moving your worker and your opponent isn't aware of this trick, you are ensured a worker kill if he engages you like this.

On July 26 2012 05:18 JinDesu wrote:


From what the OP is saying, I don't think you want your oldest one to go scout. You want your newest one.

On July 26 2012 05:28 sLiMpoweR wrote:
What if they are exactly the same age?

On July 26 2012 05:28 sLiMpoweR wrote:
What if they are exactly the same age?

On July 26 2012 05:26 herbie wrote:
New units are obviously first in the update cycle, so their commands are processed before older units. I would assume this affects all units where the interaction is extremely close. Really interesting.

On July 26 2012 05:32 graNite wrote:


That's so strange because the ghost snipe has a bigger range ?!

On July 26 2012 05:32 Grumbels wrote:
In any case, an application for this is: if you warp in a high templar you know it can win any immediate feedback face-offs.

On July 26 2012 05:28 sLiMpoweR wrote:
What if they are exactly the same age?

On July 26 2012 05:33 AcrossFiveJulys wrote:


This analysis sounds about right to me. One way to fix this issue would be to randomize which unit commands are processed first. However, that might introduce performance issues... it's possible they have the order in which commands are processed streamlined in some way to optimize performance, so actually in reality it might be more complicated than just which unit is newer.




Yes but there's a significant pause before the ghosts actually snipes during its animation while the feedback is near instant.

On July 26 2012 05:36 bgx wrote:
on a more serious note im more interested in those marines, zerglings, workers....

On July 26 2012 05:34 Ghoststrikes wrote:


Yeah like that happens often in PvPs....

On July 26 2012 05:39 herbie wrote:
It does make me wonder, if you created a newer army of 10 marines and an older army of 10 marines, would the newer army win slightly more often because it is updated first?

On July 26 2012 05:39 canikizu wrote:
I wonder if a scv is old enough, can he 1v2 other newest scvs?

On July 26 2012 05:41 urashimakt wrote:

Over a long period of testing, sure. A LONG period. Super long. This advantage is infinitesimal when the random min/max delay appended to attacks is considered.

On July 26 2012 05:39 herbie wrote:
It does make me wonder, if you created a newer army of 10 marines and an older army of 10 marines, would the newer army win slightly more often because it is updated first?

On July 26 2012 05:46 Grumbels wrote:

It can only happen if two marines are attacking each other at exactly the same time, which won't happen with larger armies because of how you group up your marines is kind of random. Maybe it comes into play just for the first two marines that come into range of each other, but it won't make a real difference.

On July 26 2012 05:52 Grumbels wrote:

You're wrong, I think. Most attacks are projectiles that take time to land. This means that all two units that attack each other at the exact same time, bar marines, tanks, snipe, feedback, infested terrans and immortals afaik - will also kill each other at the exact same time. What can happen is that a newly created marine fires at a colossus and will kill it just as the colossus was about to fire, however these moments are really random and require for the timings to match up exactly (which will rarely happen). This problem still exists even with random attack delays. (you're talking about a random delay before firing, right?)

On July 26 2012 05:44 herbie wrote:

Oh yeah, I guess thats one of the big reasons to have attack delays lol. Without them newer units would probably have a bit of an advantage. When they both get into range they would start firing and always update on the same cycle.

On July 26 2012 05:20 MyLastSerenade wrote:
wtf, thats quite a discovery!
would like to see a statment from blizz on that...

On July 26 2012 05:46 Aunvilgod wrote:
If this applies to scouting workers too... (?) what about spawning workers?

On July 26 2012 05:15 Grumbels wrote:
If you want to investigate something else, can you discover if there is a pattern as to which of the starting workers would count as 'older'? It would be funny if it would become correct play to keep an eye on your 'oldest' worker and use that one to scout. After all, if you're playing a mirror and you're attack-moving your worker and your opponent isn't aware of this trick, you are ensured a worker kill if he engages you like this.

On July 26 2012 05:57 j4vz wrote:


and what about drones when you gas steal, and cancel, does it reset the age of the drone?

On July 26 2012 05:58 magnaflow wrote:
Could it be because it has more energy pooled?

On July 26 2012 06:10 Papulatus wrote:
Would be cool if this video wasn't 30 minutes long.

On July 26 2012 06:10 Papulatus wrote:
Would be cool if this video wasn't 30 minutes long.

On July 26 2012 06:52 Adrenal6land wrote:
i love this game so much. its very fitting that there is a story as to which high templar survives. i love that its not random. this game is so interesting on so many levels <3
i remember, every time a ling got into a fight at a watch tower id cross my fingers and now i know that the younger ling will always win, so i should send the last ling i produced to fight for the tower. just a little thing that will make me smile every time i take a tower and the other player is like.... hmmmmmm wha happen

On July 26 2012 07:06 PauseBreak wrote:
This is actually a pretty huge find! So basically, you want to have a pretty good turn over of casters.

On July 26 2012 07:25 Zenbrez wrote:

It's not very often you have high templars battles in a pvp.

On July 26 2012 07:24 Vicarious_ wrote:
Please, someone make a map where both HTs are spawned at the same time and let's see what happens!

On July 26 2012 06:00 Toastie.NL wrote:
2 Infestors nearaling ?

On July 26 2012 07:37 thurst0n wrote:

They wouldn't actually be spawned at the same TIME, they would each have to trigger and that can't happen simultaneously. It appears simultaneous to you because it's milliseconds...

That's SICK, So basically send your newest probe/scv/drone to defend the harassing probe/scv/drone. And also send your newest probe/scv/drone to scout as it has a better chance of winning the engage in an exact tie?

Any other applications?

On July 26 2012 08:01 Al Bundy wrote:

Please forgive my ignorance, but isn't it possible to spawn 2 units at the exact same time, using the galaxy editor?

On July 26 2012 08:03 Mestru wrote:

It's impossible. They will have unique id, and one of them will be "younger" one.

On July 26 2012 08:01 Al Bundy wrote:

Please forgive my ignorance, but isn't it possible to spawn 2 units at the exact same time, using the galaxy editor?

On July 26 2012 07:37 thurst0n wrote:

They wouldn't actually be spawned at the same TIME, they would each have to trigger and that can't happen simultaneously. It appears simultaneous to you because it's milliseconds...

That's SICK, So basically send your newest probe/scv/drone to defend the harassing probe/scv/drone. And also send your newest probe/scv/drone to scout as it has a better chance of winning the engage in an exact tie?

Any other applications?

On July 26 2012 07:20 ZeromuS wrote:
I think the fact that this impacts Ghost v Templar might be a bigger issue.

O.O

On July 26 2012 05:11 eNtitY~ wrote:
This is pretty crazy, if it works on workers too hmm..

On July 26 2012 07:28 Mestru wrote:

But Ghosts vs High Templars are quite often in TvP. It affects them too

On July 26 2012 09:20 JacobShock wrote:


Do ghost and templar have the same range?

On July 26 2012 07:48 GodZo wrote:
so bad, the first that make ghost or templar win the battle? Oo

On July 26 2012 09:49 Lightspeaker wrote:
In fairness to people saying about workers: it DOES still provide an advantage.

That advantage is infinitesimally small when compared with the comparatively huge effect of random attack delay but it IS there. It may only translate to winning an extra 1v1 worker vs worker battle once in every 10,000 times, or every 100,000 games or whatever, but it is still an advantage. Its just not a significant one.

On July 26 2012 10:15 QuantumChaos wrote:
Just tried it with SCVs, built 2 SCVs and fought them, the older one killed the younger one. Then took a new one I had built and put it against one of my original 6, and the older one died. In another test, the original SCV killed the new SCV.

http://drop.sc/227785 new SCV killed by original SCV
http://drop.sc/227786 First built SCV kills Second built SCV, then third built SCV kills original SCV.

On July 26 2012 09:28 ZeromuS wrote:


No, actually, younger templar will feedback first if both units have a queued attack and then with no energy they dont get sniped

As it is, a single younger ghost will get one snipe off for sure on the templar in the case of snipe before they are hit by feedback.

On July 26 2012 09:57 Yoduh wrote:


and how do you know this? as far as we know this is a mechanic only active in spell vs. spell calculations. normal attacks might just omit this completely. to say you know for sure you would have to prove it and run 10,000 1v1 worker battles and get some statistics going.

On July 26 2012 09:57 Yoduh wrote:


and how do you know this? as far as we know this is a mechanic only active in spell vs. spell calculations. normal attacks might just omit this completely. to say you know for sure you would have to prove it and run 10,000 1v1 worker battles and get some statistics going.

On July 26 2012 16:25 lazyitachi wrote:
Another thread derailing into know nothings discussing everything.

The op also seem to not know how to do proper hypothesis testing.

not sure what is with all the randoming since the tests will bee much more conclusive without random.
Also it is not possible to issue the command to both units at the same time.

Tl at its best. Lol.

On July 26 2012 15:44 lost_artz wrote:
So..has anyone tried this with siege tanks yet?

On July 26 2012 16:46 Nekovivie wrote:
I can't even remember the last time I saw HT's feedbacking HT's before today.. so I doubt the implications of this will be groundbreaking.

On July 26 2012 16:50 Infernal_dream wrote:


Mostly because storm sucks against protoss due to the mass hp of the units anyways. And that you rely on a lot of melee vs. melee so you'd storm the shit out of your own stuff as well.

On July 26 2012 16:41 Chantastic wrote:


I doubt there is any real effect with siege tanks.

When sieged, whoever sieges first will get the first, and thus last, shot in. Because you can't move when sieged, there isn't an issue where you'll run into each other and start attacking at the same time.

On July 26 2012 09:20 NB wrote:
for a random thread like this there are quite a handsome first post in the front page. Mod definitely should check IP to make sure there is no smurfing involved.

On July 26 2012 17:12 Sandermatt wrote:


It might be important for workers that approach each other with an attack command. The one who gets the first hit of wins.

On July 26 2012 17:06 AlanSmithee wrote:
This finding is very wierd to me.

It's fundamental in game programmnig that all agents are handled with the same priorety each loop.
for example:

agent a cast spell
agent b cast spell

agent a collision detection
agent b collision detection

agent a loose hp
agent b loose hp

By your results the loop would look like

agent a cast spell
agent a collision detection
agent a loose hp

agent b cast spell
agent b collision detection
agent b loose hp

and that would be a very fundamental flaw in the code design.

I doubt it is actually a bug, it must be an active desicion of blizzards part to have it work this way.
I wonder why though, it makes very little sense to me.

And why would they sort their priority-queue baed on how it was added.. Like they are using a stack or something... Efficient but not very dynamic for this kind of a game.. Would love to see their code.

Nice find!

On July 26 2012 18:04 ThePlayer33 wrote:
so does this work with melee units or not

On July 26 2012 18:11 Roxor9999 wrote:

If you would have read the thread you would've known the answer, no.

On July 26 2012 19:11 scsnow wrote:
The older one is more experienced, of course he wins!

On July 26 2012 17:06 AlanSmithee wrote:
This finding is very wierd to me.

It's fundamental in game programmnig that all agents are handled with the same priorety each loop.
for example:

agent a cast spell
agent b cast spell

agent a collision detection
agent b collision detection

agent a loose hp
agent b loose hp

By your results the loop would look like

agent a cast spell
agent a collision detection
agent a loose hp

agent b cast spell
agent b collision detection
agent b loose hp

and that would be a very fundamental flaw in the code design.

I doubt it is actually a bug, it must be an active desicion of blizzards part to have it work this way.
I wonder why though, it makes very little sense to me.

And why would they sort their priority-queue baed on how it was added.. Like they are using a stack or something... Efficient but not very dynamic for this kind of a game.. Would love to see their code.

Nice find!

On July 26 2012 19:11 scsnow wrote:
The older one is more experienced, of course he wins!

On July 26 2012 19:38 urashimakt wrote:

Stacks are pretty good and efficiency is super important in a game where you might have over 1000 actionable entities in a single 1v1 match. Blizzard already has the solution to this issue and it's not reworking the foundation, choosing another abritrary insertion index (or worse yet, randomizing insertion or remixing at intervals).

The solution is to add the same random delay fields to abilities that attacks already have.

On July 26 2012 20:21 AlanSmithee wrote:


Uhm.. randomizing insertion? mixing at intervals? Why on earth would you do that? Anyone with the slightest knowledge of databasemanagement or register handling would know that is a bad idea for many reasons.

However, would you profile this game I am 99% sure there would be no bottleneck or any risk of a bottleneck in this part of the logic. Potential risk in the logics department might be pathfnding but they've managed that nicely and other then that the heavy workload is on the graphics-side and network side of things.

About "choosing another abritrary insertion index", there is no need for that, using any template-based container that support binary search trees, finding agents is done with very few iterations, no mather the method of insertion. Again tehre is no heavy workload in this.

*EDIT* Ok, im tired, the method of insertion does matter since the agents would have to be ordered to be able to do a binary search, hoever this is easily and efficiently done using recursion, so my claims are still valid.

And also i just pulled the word stack out of my *** since it was the first that popped to mind, there is ofcourse no way they would even consider use a stack for this as they need to be able to access elements from within the container and not only the last inserted. They are probably using and normal dynamic array (read vector) or container with mapped values (read map) I wouldnt know if i cant see the code first.

Again, they must have an active reason for having it this way, which i can't think of. I dont think your sTatements are accurate though.

agent a cast spell
agent a collision detection
agent a loose hp

agent b cast spell
agent b collision detection
agent b loose hp

On July 26 2012 20:42 InPlainSight wrote:


From the fact that the last unit created is iterated first I assumed that the data structure was a linked list. Addressing why this progression would be used


instead of the other would likely be due to caching as putting the same unit in the cache 3 times is much slower than once and performing many operations on it. Additionally the game engine doesn't like simultaneous attacks which in spite of the random variation in attack speed would still occur if every unit had it's attack processed in a separate loop to deaths being processed.

On July 26 2012 20:52 AlanSmithee wrote:


Might be a linked list, might not, I am fairly sure it is not a stak though.
I don't see why they would use a linked list though since it doesn't support random access.

Hmm you really think they would cache that during the loops? using good OO design, they should be able to access these agents in any point of the execution/loop, why would they cache it?

Also, what about the game engine does not "like" simultaneous attacks? I have no knowledge of the engine blizzard built for this game, please enlgihten me.

Just to avoid any confusion i am not talking about multi-threaded loops, just standard game-loop logic as in
ab
ab
ab
as oposed to
aaa
bbb

Thanks in advance.

On July 26 2012 21:03 InPlainSight wrote:


Th reason I thought it would be linked list is that out of the different structures which would be iterated from newest element to oldest a linked list with insertation at the head makes the most sense. I always assumed that a basic array would do as that allows random access and can easily remove units however in blizzards engine where units seem to die part way through a game state and not at the end as is shown by units not being overkilled by instantaneos attacks a linked list actually makes sense as removing an element from a linked list is easy to do even mid iteration whereas removing units from an array whilst being iterated ends up being messy.

I assume units are held in several datastructures but the linked list is the one iterated each turn. They will probably be in some kind of geohash as well as maybe some tree structures for help with target finding and collision detection.

In terms of the caching what I mean is processor level caching, the processor caching a unit to L1 and performing many operations is much faster than caching the thing once, caching another item and then coming back to that one after iterating all other units in the game. I'm no expert on caching so I could be very wrong here but that's an explaination I came up with.

In terms of not liking simutaneos attacks I simply mean that instant attacking units seem unable to kill one another. Any melee unit, marine or seige tank (and there are probably others) are incapable of killing each other. If units all have there attacks processed they would often kill each other even accounting for the random variation. I don't know why blizzard decided this was for the best but since they decided to do it this was processing all of a units actions at a time seems logical and would also remove some redundant processes for units which just end up dying at the end of the loop anyways.

On July 26 2012 21:08 AlanSmithee wrote:



All your points makes sense, except maybe the processor level caching (just seems to me it would caus a lot of overhead, but I am in no way good at low level optimization so dont take my word for it)

Thanks for your answers.

On July 26 2012 05:41 urashimakt wrote:

Over a long period of testing, sure. A LONG period. Super long. This advantage is infinitesimal when the random min/max delay appended to attacks is considered.

On July 26 2012 19:38 urashimakt wrote:

Stacks are pretty good and efficiency is super important in a game where you might have over 1000 actionable entities in a single 1v1 match. Blizzard already has the solution to this issue and it's not reworking the foundation, choosing another abritrary insertion index (or worse yet, randomizing insertion or remixing at intervals).

The solution is to add the same random delay fields to abilities that attacks already have.

On July 26 2012 22:29 fabiano wrote:


This is one of the foundations of game programming.

I bet there are other people here who like me took a course on Computer Graphics and had one assignament to create a "game", and if your code didn't fulfill that foundation then you would lose a shit ton of fuckload of points...

I can't believe blizzard programmers, who are probably really really skilled, made such a mistake D:

On July 26 2012 05:31 JinDesu wrote:


I don't think they can be - assuming the system uses some sort of ID for timestamp.

On July 26 2012 22:34 AlanSmithee wrote:


If two units who have an projectile shoot at each other at aprox. the same time, both die. (Vikings, stalkers etc.) But for the units with instant shots, like marines, it would make little sense if both units die.

There is no real world equivalent of "instant" shot but it if there were the two units would ahve to fire at the exact same time, and that would never happend.

Again, there is no flaw, you can consider it bad design if you want to (i disagree, i think it works well), but belive me, it's very much intentially.

On July 26 2012 22:45 Aerisky wrote:

Well, the OP is a Polish Mythbusters type show, so I think he is encouraging more Polish SC2 players/fans to come to TL in his show, which is a pretty great thing ^^

On July 26 2012 22:43 fabiano wrote:


It doesnt matter if the shot is instant or not, what matters is if both of them fired and hit at the same time, in a later cycle the state of both units should be set to dead.

Basing who dies first on who is on top of the stack, later in the queue or any other code-only related situation is a design flaw, unless it is related to a feature of the game, such as "the veteran will always prevail".

On July 26 2012 22:58 renkin wrote:
So how can we use this discovery efficiently ?
By putting the younger units in front lines and the older ones behind ?

I guess 4gates micro wars gain a new dimension...
Maybe it could influence the outcome of zerglings vs zerglings battles ?

On July 27 2012 00:43 CzaRyMaRy wrote:
I checked it out and it's the same with zerglings and ultralisks - the younger always wins. BTW Queens are interesting exception - they both die.

On July 26 2012 05:12 Yegwen wrote:
http://www.twitch.tv/yegwen We are live and testing this for all other units now if you are as intrigued as we are!

On July 27 2012 19:26 roemy wrote:
off topic: also: add a tiny attack 'delay' to siege tanks so they overkill dropped zealots again ^^