Our viewers report this also works for other units - marines, zerglings, zealots...
Here is a english video of us reproducing the experiment:
Replay file:
http://drop.sc/227661
Forum Index > SC2 General |
Yegwen
Poland80 Posts
Our viewers report this also works for other units - marines, zerglings, zealots... Here is a english video of us reproducing the experiment: Replay file: http://drop.sc/227661 | ||
zhurai
United States5660 Posts
| ||
myroon
Poland1 Post
Great, good job guys. | ||
catplanetcatplanet
3815 Posts
| ||
graNite
Germany4434 Posts
you can link the video without the codes, just the link. watchingn now. | ||
Gorilla23
United States339 Posts
On July 26 2012 05:08 zhurai wrote: Show nested quote + On July 26 2012 05:07 Yegwen wrote: Hi guys, something quite interesting we have discovered today. We were running a polish version of Mythbusters show regarding Starcraft 2. And someone from the audience suggested to test two High Templars feedbacking themselves at the same time (queueed from a distance) - after a long while of testing and scratching our heads about a visible pattern we have found out that the one that has been produced earlier always dies (the older one). Our viewers report this also works for other units - marines, zerglings, zealots... Here is a english video of us reproducing the experiment: <iframe width="420" height="315" src="http://www.youtube.com/embed/zvIo9ahpAvM" frameborder="0" allowfullscreen></iframe> Replay file: http://drop.sc/227661 ... the older high templar has more energy because he's been around more..... so? 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. | ||
willoc
Canada1530 Posts
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? | ||
Toastie.NL
Netherlands232 Posts
| ||
Tosster
Poland299 Posts
| ||
Mestru
Poland10 Posts
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! This will later appear on the same youtube channel as english version. | ||
eNtitY~
United States1293 Posts
| ||
LittLeD
Sweden7973 Posts
| ||
Bomal
Poland1 Post
| ||
Szuta
Poland1 Post
| ||
JinDesu
United States3990 Posts
On July 26 2012 05:08 zhurai wrote: Show nested quote + On July 26 2012 05:07 Yegwen wrote: Hi guys, something quite interesting we have discovered today. We were running a polish version of Mythbusters show regarding Starcraft 2. And someone from the audience suggested to test two High Templars feedbacking themselves at the same time (queueed from a distance) - after a long while of testing and scratching our heads about a visible pattern we have found out that the one that has been produced earlier always dies (the older one). Our viewers report this also works for other units - marines, zerglings, zealots... Here is a english video of us reproducing the experiment: <iframe width="420" height="315" src="http://www.youtube.com/embed/zvIo9ahpAvM" frameborder="0" allowfullscreen></iframe> Replay file: http://drop.sc/227661 ... the older high templar has more energy because he's been around more..... so? I take it you like to comment without watching the video? | ||
zhurai
United States5660 Posts
On July 26 2012 05:09 Gorilla23 wrote: Show nested quote + On July 26 2012 05:08 zhurai wrote: On July 26 2012 05:07 Yegwen wrote: Hi guys, something quite interesting we have discovered today. We were running a polish version of Mythbusters show regarding Starcraft 2. And someone from the audience suggested to test two High Templars feedbacking themselves at the same time (queueed from a distance) - after a long while of testing and scratching our heads about a visible pattern we have found out that the one that has been produced earlier always dies (the older one). Our viewers report this also works for other units - marines, zerglings, zealots... Here is a english video of us reproducing the experiment: <iframe width="420" height="315" src="http://www.youtube.com/embed/zvIo9ahpAvM" frameborder="0" allowfullscreen></iframe> Replay file: http://drop.sc/227661 ... the older high templar has more energy because he's been around more..... so? 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. Ah ok, then that's... interesting o___O huh... | ||
Yegwen
Poland80 Posts
| ||
Grumbels
Netherlands7028 Posts
| ||
Fugson
Poland1 Post
| ||
szopenos
1 Post
Ahh anyway:D Very good my padawan's | ||
JinDesu
United States3990 Posts
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. From what the OP is saying, I don't think you want your oldest one to go scout. You want your newest one. | ||
MyLastSerenade
Germany710 Posts
would like to see a statment from blizz on that... | ||
Grumbels
Netherlands7028 Posts
On July 26 2012 05:18 JinDesu wrote: Show nested quote + 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. From what the OP is saying, I don't think you want your oldest one to go scout. You want your newest one. Sorry, I misread it as the oldest unit winning, because that makes more sense imo. Since I figured the game might have a list of units, add newly created units to the end of the list and then remove killed units from the list before they have a chance to fire themselves. (as feedback is instant, like tank volleys) | ||
Mephyss
Brazil128 Posts
| ||
herbie
140 Posts
| ||
SeraKuDA
Canada343 Posts
| ||
sLiMpoweR
United States430 Posts
| ||
Omri
Israel638 Posts
On July 26 2012 05:28 sLiMpoweR wrote: What if they are exactly the same age? The universe explodes? | ||
Yegwen
Poland80 Posts
| ||
JinDesu
United States3990 Posts
On July 26 2012 05:28 sLiMpoweR wrote: What if they are exactly the same age? I don't think they can be - assuming the system uses some sort of ID for timestamp. | ||
graNite
Germany4434 Posts
On July 26 2012 05:30 Yegwen wrote: And it DOES work for Ghosts vs High Templars! The younger one casts the spell faster! That's so strange because the ghost snipe has a bigger range ?! | ||
Grumbels
Netherlands7028 Posts
| ||
AcrossFiveJulys
United States3612 Posts
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. 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. On July 26 2012 05:32 graNite wrote: Show nested quote + On July 26 2012 05:30 Yegwen wrote: And it DOES work for Ghosts vs High Templars! The younger one casts the spell faster! That's so strange because the ghost snipe has a bigger range ?! Yes but there's a significant pause before the ghosts actually snipes during its animation while the feedback is near instant. | ||
Ghoststrikes
Canada1356 Posts
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. Yeah like that happens often in PvPs.... | ||
herbie
140 Posts
On July 26 2012 05:28 sLiMpoweR wrote: What if they are exactly the same age? All that matters is the order they are placed onto the collection in memory, they cannot be placed in the same index, therefore one will always be created before the other. | ||
TitleRug
United States651 Posts
| ||
urashimakt
United States1591 Posts
On July 26 2012 05:33 AcrossFiveJulys wrote: Show nested quote + 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. 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. Show nested quote + On July 26 2012 05:32 graNite wrote: On July 26 2012 05:30 Yegwen wrote: And it DOES work for Ghosts vs High Templars! The younger one casts the spell faster! That's so strange because the ghost snipe has a bigger range ?! Yes but there's a significant pause before the ghosts actually snipes during its animation while the feedback is near instant. The answer is the same as to how they mask this "problem" with attacks: add a random min/max delay to spellcasts. On July 26 2012 05:36 bgx wrote: on a more serious note im more interested in those marines, zerglings, workers.... Attacks have a min/max delay that minimizes (one might say it eliminates) the update order advantage. | ||
bgx
Poland6595 Posts
On July 26 2012 05:34 Ghoststrikes wrote: Show nested quote + 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. Yeah like that happens often in PvPs.... thank god PvP never reached templar metagame otherwise we would have to scrap all the templar vs templar games :p on a more serious note im more interested in those marines, zerglings, workers.... | ||
graNite
Germany4434 Posts
| ||
Spidinko
Slovakia1174 Posts
Fun fact, though I don't see it impacting the game much. Maybe it's better to go scouting with first worker, but besides that, idk. | ||
herbie
140 Posts
| ||
canikizu
4860 Posts
| ||
urashimakt
United States1591 Posts
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? 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 canikizu wrote: I wonder if a scv is old enough, can he 1v2 other newest scvs? No. A newer SCV could very well lose to an older SCV 1v1 with no micro. | ||
Mestru
Poland10 Posts
| ||
Lorch
Germany3657 Posts
| ||
herbie
140 Posts
On July 26 2012 05:41 urashimakt wrote: Show nested quote + 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? 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. 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. | ||
Grumbels
Netherlands7028 Posts
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? 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. I don't think the comment about snipe that some people mentioned is correct by the way. I think in the case of snipe either the ghost or high templar will always win, because both have different range. (easy enough to test) | ||
graNite
Germany4434 Posts
+ Show Spoiler + just kidding Battlecruiser yamato cannon vs feedback: feedback always wins because the yamato cannon is stopped while loading when the bc loses its energy. | ||
Aunvilgod
2653 Posts
| ||
Chronos.
United States805 Posts
| ||
urashimakt
United States1591 Posts
On July 26 2012 05:46 Grumbels wrote: Show nested quote + 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? 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. The advantage from the update order is in milliseconds at best. The randomized advantage all attacks gain upon execution is measured in centiseconds. In essence, the update order only matters for abilities with 0 seconds between cast time and impact time. Effects with travel time or a delay between cast and impact and attacks are unaffected. On July 26 2012 05:52 Grumbels wrote: Show nested quote + On July 26 2012 05:44 herbie wrote: On July 26 2012 05:41 urashimakt wrote: 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? 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. 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. 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?) Again, the advantage granted by this phenomenon is so small compared to the random attack delay that, if you were an SC2 Scientist working for SC2 NASA, you would omit it from your calculations as a margin of error. | ||
InfusedTT.DaZe
Romania693 Posts
| ||
Grumbels
Netherlands7028 Posts
On July 26 2012 05:44 herbie wrote: Show nested quote + On July 26 2012 05:41 urashimakt wrote: 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? 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. 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. 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?) | ||
graNite
Germany4434 Posts
| ||
Zenbrez
Canada5973 Posts
On July 26 2012 05:20 MyLastSerenade wrote: wtf, thats quite a discovery! would like to see a statment from blizz on that... Why? Out of the two, one of them should die. Which one? Well they decided to put in a circumstance, time happened to be the one they chose. | ||
Yegwen
Poland80 Posts
| ||
j4vz
Canada976 Posts
On July 26 2012 05:46 Aunvilgod wrote: If this applies to scouting workers too... (?) what about spawning workers? and what about drones when you gas steal, and cancel, does it reset the age of the drone? i think worker management will be important now, you dont want to send an old one and lose a 1v1 fight during a bunker rush or something edit: oh its not working on regular attack | ||
magnaflow
Canada1521 Posts
| ||
KirA_TheGreaT
France204 Posts
| ||
Toastie.NL
Netherlands232 Posts
| ||
windzor
Denmark1013 Posts
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. Wouldn't that be the reverse? you want the youngest worker to scout because it might have a higher chance of surviving, or am I understanding this wrongly? Either way, this will only impact in like 0.1% of matches where both of you attack-move two workers into eachother and don't micro any of them. The likelyhood of this must so so low as to not interresting to do... | ||
graNite
Germany4434 Posts
On July 26 2012 05:58 magnaflow wrote: Could it be because it has more energy pooled? Just tested it, no. With the same, with more and with less energy the older templar always loses. | ||
urashimakt
United States1591 Posts
On July 26 2012 05:57 j4vz wrote: Show nested quote + On July 26 2012 05:46 Aunvilgod wrote: If this applies to scouting workers too... (?) what about spawning workers? and what about drones when you gas steal, and cancel, does it reset the age of the drone? Actually, if you're still interested on whether or not it resets the age of the drone I can tell you that it doesn't. The drone isn't removed from the stack until either the extractor completes or dies. | ||
NeMeSiS3
Canada2972 Posts
This is cool though, probably one of the more interesting "mythbuster" type tests that has happened | ||
imre
France9263 Posts
On July 26 2012 05:58 magnaflow wrote: Could it be because it has more energy pooled? let's comment after reading the title >< | ||
Grobyc
Canada18410 Posts
| ||
Bloog
United States44 Posts
| ||
Mrvoodoochild1
United States1439 Posts
| ||
Papulatus
United States669 Posts
| ||
Powster
United States650 Posts
| ||
Coal
Sweden1535 Posts
| ||
Mestru
Poland10 Posts
On July 26 2012 06:10 Papulatus wrote: Would be cool if this video wasn't 30 minutes long. First 6 minutes of it should be enough to see what are we talking about. | ||
Names
Canada328 Posts
| ||
mrtomjones
Canada4020 Posts
| ||
robih
Austria1083 Posts
On July 26 2012 06:10 Papulatus wrote: Would be cool if this video wasn't 30 minutes long. its 30mins cause they also tested it in an actual game not just unittest map | ||
Charger
United States2405 Posts
| ||
MaxFatality
United States21 Posts
| ||
Adrenal6land
United States46 Posts
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 | ||
Mestru
Poland10 Posts
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 It doesn't works with normal attacks Only abilities | ||
PauseBreak
United States270 Posts
| ||
ZeromuS
Canada13372 Posts
O.O | ||
Vicarious_
Brazil17 Posts
| ||
Zenbrez
Canada5973 Posts
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. It's not very often you have high templars battles in a pvp. | ||
Mestru
Poland10 Posts
On July 26 2012 07:25 Zenbrez wrote: Show nested quote + 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. It's not very often you have high templars battles in a pvp. But Ghosts vs High Templars are quite often in TvP. It affects them too | ||
thurst0n
United States611 Posts
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! 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? | ||
-Kyo-
Japan1926 Posts
| ||
discator
Germany639 Posts
| ||
GodZo
Italy224 Posts
| ||
Shinshady
Canada1237 Posts
On July 26 2012 06:00 Toastie.NL wrote: 2 Infestors nearaling ? Since Infestor Neural Parasite is not instant and the "parasite" has some time before it actually reaches the target they end up tying and deadlocking where neither unit can be moved IIRC | ||
Al Bundy
7257 Posts
On July 26 2012 07:37 thurst0n wrote: Show nested quote + 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! 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? Please forgive my ignorance, but isn't it possible to spawn 2 units at the exact same time, using the galaxy editor? | ||
Mestru
Poland10 Posts
On July 26 2012 08:01 Al Bundy wrote: Show nested quote + On July 26 2012 07:37 thurst0n wrote: 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! 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? Please forgive my ignorance, but isn't it possible to spawn 2 units at the exact same time, using the galaxy editor? It's impossible. They will have unique id, and one of them will be "younger" one. | ||
Al Bundy
7257 Posts
On July 26 2012 08:03 Mestru wrote: Show nested quote + On July 26 2012 08:01 Al Bundy wrote: On July 26 2012 07:37 thurst0n wrote: 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! 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? Please forgive my ignorance, but isn't it possible to spawn 2 units at the exact same time, using the galaxy editor? It's impossible. They will have unique id, and one of them will be "younger" one. Thanks | ||
jcroisdale
United States1543 Posts
| ||
winthrop
Hong Kong956 Posts
in warcraft3, there was a text. (chinese forum,,) two heroes can be killed in one hit, who dead first? instance, two 1-hp mountainking use thunder bolt to each other,. conclusion is the one response first died first. how it works? train them again and check exp,, | ||
willoc
Canada1530 Posts
On July 26 2012 08:01 Al Bundy wrote: Show nested quote + On July 26 2012 07:37 thurst0n wrote: 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! 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? Please forgive my ignorance, but isn't it possible to spawn 2 units at the exact same time, using the galaxy editor? Sure! Give me a list of the 2 units at the same time (see what I did there?). | ||
Dust14
Belgium490 Posts
On July 26 2012 07:37 thurst0n wrote: Show nested quote + 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! 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? Have you even read the previous comments, they already said it's only true for abilities and not normal attacks -_- | ||
DataMiner
United States104 Posts
| ||
ZenithM
France15952 Posts
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 It kinda isn't, EMP is a projectile and has more casting range than feedback as well as AoE. So basically you'll always manage to shoot the projectile. Feedback is instant so in the time the EMP is traveling air, you can land the feedback if you're close enough to the ghost. To sum it up, if the two casters cast at the same time, both can land and it's not really up to luck or production date for that matter. This shit only affect instant spells/attacks with exactly the same range. | ||
Rah
United States973 Posts
| ||
IshinShishi
Japan6156 Posts
| ||
hpTheGreat
United States173 Posts
On July 26 2012 05:11 eNtitY~ wrote: This is pretty crazy, if it works on workers too hmm.. you just blew my mind | ||
JacobShock
Denmark2485 Posts
On July 26 2012 07:28 Mestru wrote: Show nested quote + On July 26 2012 07:25 Zenbrez wrote: 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. It's not very often you have high templars battles in a pvp. But Ghosts vs High Templars are quite often in TvP. It affects them too Do ghost and templar have the same range? | ||
Mestru
Poland10 Posts
On July 26 2012 09:20 JacobShock wrote: Show nested quote + On July 26 2012 07:28 Mestru wrote: On July 26 2012 07:25 Zenbrez wrote: 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. It's not very often you have high templars battles in a pvp. But Ghosts vs High Templars are quite often in TvP. It affects them too Do ghost and templar have the same range? No, but snipe takes additional time to prepare before shotting. It's timed properly. | ||
NB
Netherlands12045 Posts
About the topic: not only queue order is a given, there is also network environment to take in hand. If i send a command from US East to Korea sever, it will be much slower than a guy sending a same command from Korea itself. Given that we have a method to sync up our action, the data procession time will be different along with our computer specs etc... To much random element and the lack of LAN environment simply make the problem inconclusive. Pretty much /thread | ||
Yoduh
United States216 Posts
| ||
ZeromuS
Canada13372 Posts
On July 26 2012 08:18 ZenithM wrote: Show nested quote + 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 It kinda isn't, EMP is a projectile and has more casting range than feedback as well as AoE. So basically you'll always manage to shoot the projectile. Feedback is instant so in the time the EMP is traveling air, you can land the feedback if you're close enough to the ghost. To sum it up, if the two casters cast at the same time, both can land and it's not really up to luck or production date for that matter. This shit only affect instant spells/attacks with exactly the same range. 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. | ||
Infernal_dream
United States2359 Posts
| ||
Ahli
Germany355 Posts
On July 26 2012 07:48 GodZo wrote: so bad, the first that make ghost or templar win the battle? Oo I just made some tests with the editor. There is a randomness in the ghost vs HT battle. I tested ghost's snipe versus HT's feedback. Snipe has 1 range more, but a cast time of 0.5 seconds (= duration before spell effect (damage) is executed). So the mechanics behind the spells are different as snipe is no instant effect spell. In HT vs HT the order of the units checked for their ingame ability execution is applied which has been proofed by the OP. The OP's rule should/might be true for snipe vs snipe. In my tests I used triggers to create and order the units. First I gave both players full map vision, then I created one unit, waited, created the second unit, waited, ordered both to use the spells on each other. My results are that it depends on the unit's distance when they get the order. At first the ghost might always lose to the HT, but altering one factor changed the outcome. If I moved the ghost's spawnpoint slightly more left or right, it started to damage the HT on some points which means snipe was successfully casted before the feedback killed the ghost. So the distance had a factor in the result of the battle. -> Altering the spawning order had no effect on the result. -> Ghost snipe vs HT feedback is kind of random as it depends on the distance. BUT the distances in which one spell is executed before the other one might not be equally distributed (-> not 50%). So you might end up with a result of 70 to 30% for one unit to win the battle. But maybe it's 60 to 40, maybe it's 90 to 10... -> FURTHER testings are required! I tested this in 1.4.4 with multi dependency. So all balance changes should have been applied. In a short test in 1.5 the ghost never dealt damage to the HT, but I didn't alter the spawnpoints. I noticed that the distance could be a factor as the ghost dealt damage in my 1.4.4 test attempt (which contains the balance changes). To make a good test for the distances I need an example of the area in which the ghost are and where the HTs are when they both receive their order to use their ability on each other. TIME FOR A MASSIVE SCALE TEST with random distances: In the new test I would create an area in which I would spawn the units on a random position within the area. Then I would order both to use their spell on each other. In the end I would try to run the test a lot of times on the map at once and test it over and over with random points. In the end we might have a good idea which unit has how big chances to win. Since I want results now I just made a test map for that. Settings: - Every unit spawns in a random circular area. - The area has a radius of 3. - The distance between the center points of each area is 17. - Ghost and Templar have each 50% chance to spawn first (random integer between 0 and 1). - Fight is always approximated west vs east. - West unit is always created first. (But west unit's type is random.) - Both units receive their order at the same time. Result: Templar has a win chance of approx 56% versus ghost snipe in 1.4.4 in these test settings. But they might be flawed as both units spawn in circular areas. It's possible to get some stable results for the templar win percentage within a short duration with my test map. If you want me to alter the test or add some features for it to make it a useful tool for battle.net, just ask (PM me). edit: After setting the east unit's area to 0 (= always same spawnpoint), the templar's winrate was 53%. Using a cicular area still might be a problem as the distance isn't evenly distributed. next test: Now I'm using points for both units. The west unit has a random x-offset. It is now created with a random distance of 12.0 - 17.0. The result is 53% as seen in the next screenshot. => Templar has a win chance of approx 53% versus ghost snipe in 1.4.4. edit: - Changing the random distance to 12.0 - 16.0 results in the same win chance for the HT. - Changing the random distance to 12.0 - 15.0 results in the same win chance for the HT. This was only a test with west vs east. Maybe it's different in north vs south or in north-west vs south-east. ~ Ahli | ||
nanaoei
3358 Posts
for obvious reasons, no. i don't see how this is any different than when you try to feedback (wth say an observer hovering over a terran's ghosts and you queue up some feedback uses) and end up getting sniped a couple times before it goes off. snipe simply has a longer range than most abilities, including feedback. unless you have some evidence (with this new discovery i mean) i really doubt that a fresh templar gets priority over a direct-snipe that has a longer spell-cast range. how does this affect units attacking each other (at the same time) at all? where do you even jump to that idea/conclusion ? | ||
-Celestial-
United Kingdom3867 Posts
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. | ||
Yoduh
United States216 Posts
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. 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. | ||
ZeromuS
Canada13372 Posts
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. Its only important in mirrors anyway since the way drones v probes v scvs works is impacted more by race than anything. Natural regen of Drones and higher HP of SCVs comes to mind. | ||
nanaoei
3358 Posts
i'd love for there to be other finds but as is, the only thing proven is what's posted in the OP currently | ||
dafunk
France521 Posts
| ||
DMKraft
476 Posts
Edit: I guess we all get slower as we get older. | ||
QuantumChaos
Canada37 Posts
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. | ||
Ahli
Germany355 Posts
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. Weapons have random wait times as already mention a dozen of times. It would require an automatic test map to test that. | ||
ZenithM
France15952 Posts
On July 26 2012 09:28 ZeromuS wrote: Show nested quote + On July 26 2012 08:18 ZenithM wrote: 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 It kinda isn't, EMP is a projectile and has more casting range than feedback as well as AoE. So basically you'll always manage to shoot the projectile. Feedback is instant so in the time the EMP is traveling air, you can land the feedback if you're close enough to the ghost. To sum it up, if the two casters cast at the same time, both can land and it's not really up to luck or production date for that matter. This shit only affect instant spells/attacks with exactly the same range. 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. Sorry I was talking about EMP vs Feedback and forgot about snipe, but apparently tests reveal that it's close to random so I wouldn't worry too much about that. | ||
Fyrewolf
United States1533 Posts
On July 26 2012 09:57 Yoduh wrote: Show nested quote + 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. 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. It's not a mechanic, it's just the effect of SC2 using in order processing for all actions that get executed. The younger unit ends up higher in the list of actions that the game processes, it doesn't do any actions at the same time, but in very quick successions of fractions of a second, which is also why SC2 can do smart pathing and smart firing. | ||
-Celestial-
United Kingdom3867 Posts
On July 26 2012 09:57 Yoduh wrote: Show nested quote + 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. 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. Simple deduction, your proposal makes absolutely no sense as far as the actual running of the game goes. To explain...the reason this spellcasting trick works is that the game has to resolve the actions of every single unit somehow. This spellcast test demonstrates how this is done - chronologically, with the youngest given priority. What that action actually IS is irrelevant. You cannot OMIT this because its something that has to be done. Simply put: the game needs instructions for how to resolve the actions of all of the units. This test demonstrates that it does this in chronological reverse order. Unless for some insane reason they've coded different actions to be resolved in different ways which would be more complex and slow the game down. Edit: Fyrewolf summarised it rather nicely above. | ||
dNa
Germany591 Posts
i realized at one point while playing arround on the unit test map with thor vs thor 250mm strike cannon duels, the left thor nearly always lost... but as i didn't think of them as older/younger but as left/right, i thought that wasn't really worth pursuing.. thanks for actually clearing that up lol. | ||
lost_artz
United States366 Posts
| ||
lazyitachi
1043 Posts
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. | ||
RaiKageRyu
Canada4772 Posts
| ||
dani`
Netherlands2402 Posts
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. Instead of only criticizing people who have put some effort in their investigation - even though you think it's flawed - you might want to enlighten us with your knowledge of how to do it better. You have a point regarding which units casts Feedback first. I have to admit at points in their video I thought the one who died was always the one who issued the command last. They seemed to have a certain pattern in their tests such that whichever HT they thought would win would always begin with casting the spell. However, I also ran some test myself and this does not seem to matter. I think the tests are fairly conclusive, but should probably be ran automatically a couple thousand times to show that the newer one indeed wins 100% of the time. | ||
Chantastic
86 Posts
On July 26 2012 15:44 lost_artz wrote: So..has anyone tried this with siege tanks yet? 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. | ||
Nekovivie
United Kingdom2599 Posts
| ||
Infernal_dream
United States2359 Posts
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. 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. | ||
Ryuu314
United States12679 Posts
| ||
AlanSmithee
39 Posts
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! | ||
Sandermatt
Switzerland1365 Posts
On July 26 2012 16:50 Infernal_dream wrote: Show nested quote + 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. 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. I think I have seen PvP storms, in a Kespa vs GSL showmatch. I think Ace stromed to Kespa player whos name I forgot (From WJ). | ||
Sandermatt
Switzerland1365 Posts
On July 26 2012 16:41 Chantastic wrote: Show nested quote + On July 26 2012 15:44 lost_artz wrote: So..has anyone tried this with siege tanks yet? 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. It might be important for workers that approach each other with an attack command. The one who gets the first hit of wins. | ||
scypio
Poland2127 Posts
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. Sigh... Yegwen did his testing on stream with ~250 people watching. Once he was done he said that he's going to write on TL about it and perhaps some of the viewers could share their thoughts on TL too. And that's the whole conspiracy. | ||
WindWolf
Sweden11767 Posts
Also, Yegwen, have you done some English casts, or do you have any plans to? | ||
kochanfe
Micronesia1338 Posts
yeh know, because HTs are so common in PvP... | ||
Roxor9999
Netherlands771 Posts
On July 26 2012 17:12 Sandermatt wrote: Show nested quote + On July 26 2012 16:41 Chantastic wrote: On July 26 2012 15:44 lost_artz wrote: So..has anyone tried this with siege tanks yet? 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. It might be important for workers that approach each other with an attack command. The one who gets the first hit of wins. Random attack delay, will make sure that doesn't happen also that has been said about 15 times before. | ||
Big J
Austria16289 Posts
| ||
JyB
France466 Posts
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! I think you nailed it. Since those attacks are instantaneous it might just launch it and process the damage right away and not look at the rest of the stack. I d love to see their code too ! | ||
ThePlayer33
Australia2378 Posts
| ||
Roxor9999
Netherlands771 Posts
On July 26 2012 18:04 ThePlayer33 wrote: so does this work with melee units or not If you would have read the thread you would've known the answer, no. | ||
The Touch
United Kingdom667 Posts
7 High Templar, a-ha-ha | ||
AcrosstheSky
United States237 Posts
Very nice job! | ||
Thylacine
Sweden882 Posts
| ||
ThePlayer33
Australia2378 Posts
On July 26 2012 18:11 Roxor9999 wrote: Show nested quote + On July 26 2012 18:04 ThePlayer33 wrote: so does this work with melee units or not If you would have read the thread you would've known the answer, no. the op says yes, i read the thread tyvm | ||
pms
Poland611 Posts
| ||
scsnow
Slovenia515 Posts
| ||
Pandemona
Charlie Sheens House51300 Posts
| ||
Yegwen
Poland80 Posts
Polish scene is quite alive and active, great place to be. As of myself - I am torn between the awesomness of english and polish scene. For now majority of shows are in polish, but we did for example provide an english commentary to an ESL tournament, and apparently did good enough to do more of it in near future. | ||
dani`
Netherlands2402 Posts
On July 26 2012 19:11 scsnow wrote: The older one is more experienced, of course he wins! Sound reasonable, but the older one loses | ||
urashimakt
United States1591 Posts
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! 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. | ||
Bagi
Germany6799 Posts
On July 26 2012 19:11 scsnow wrote: The older one is more experienced, of course he wins! Nope he's tired from all the fighting, so he loses. | ||
AlanSmithee
39 Posts
On July 26 2012 19:38 urashimakt wrote: Show nested quote + 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! 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. 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. *EDIT 2* Delay fields are a solution if that is the behaviour you want. I do not think it is vise to ompare auto-cast abilitys (like bullets) to active ability's like feedback. Adding a random delay could have a negative effect as it would take away from the skill of the player. Again if the delay is very small this might not matter, would have to be tested to know. | ||
InPlainSight
New Zealand40 Posts
On July 26 2012 20:21 AlanSmithee wrote: Show nested quote + On July 26 2012 19:38 urashimakt wrote: 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! 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. 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. 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 agent a cast spell agent a collision detection agent a loose hp agent b cast spell agent b collision detection agent b loose hp 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. | ||
AlanSmithee
39 Posts
On July 26 2012 20:42 InPlainSight wrote: Show nested quote + On July 26 2012 20:21 AlanSmithee wrote: On July 26 2012 19:38 urashimakt wrote: 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! 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. 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. 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 Show nested quote + agent a cast spell agent a collision detection agent a loose hp agent b cast spell agent b collision detection agent b loose hp 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. 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. | ||
InPlainSight
New Zealand40 Posts
On July 26 2012 20:52 AlanSmithee wrote: Show nested quote + On July 26 2012 20:42 InPlainSight wrote: On July 26 2012 20:21 AlanSmithee wrote: On July 26 2012 19:38 urashimakt wrote: 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! 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. 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. 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 agent a cast spell agent a collision detection agent a loose hp agent b cast spell agent b collision detection agent b loose hp 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. 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. 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. | ||
AlanSmithee
39 Posts
On July 26 2012 21:03 InPlainSight wrote: Show nested quote + On July 26 2012 20:52 AlanSmithee wrote: On July 26 2012 20:42 InPlainSight wrote: On July 26 2012 20:21 AlanSmithee wrote: On July 26 2012 19:38 urashimakt wrote: 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! 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. 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. 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 agent a cast spell agent a collision detection agent a loose hp agent b cast spell agent b collision detection agent b loose hp 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. 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. 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. 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. | ||
InPlainSight
New Zealand40 Posts
On July 26 2012 21:08 AlanSmithee wrote: Show nested quote + On July 26 2012 21:03 InPlainSight wrote: On July 26 2012 20:52 AlanSmithee wrote: On July 26 2012 20:42 InPlainSight wrote: On July 26 2012 20:21 AlanSmithee wrote: On July 26 2012 19:38 urashimakt wrote: 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! 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. 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. 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 agent a cast spell agent a collision detection agent a loose hp agent b cast spell agent b collision detection agent b loose hp 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. 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. 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. 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. This type of caching happens automatically. Basically when the cpu makes a call to ram the L1, L2 caches etc may choose to emulate part of the ram dramatically increasing access times for subsequent calls to the same block of memory. Bascially if we are using the same bits of data sequentially we are likely to get a performance boost rather than loading fresh memory every time for multiple uses. | ||
Novalisk
Israel1818 Posts
On July 26 2012 05:41 urashimakt wrote: Show nested quote + 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? 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. This needs to be tested. If one marine survives a marine duel, it'll be firing on other marines for a while which can end up causing the other marines to survive and so on, leading to a landslide victory. If two armies of marines a-move into each other in a perfect line, then the younger army should in theory always win due to the landslide effect. Even if the formations aren't perfect, I wouldn't be surprised if the younger army wins a majority of the fights. | ||
CamoPillbox
Czech Republic229 Posts
| ||
HeavOnEarth
United States7087 Posts
| ||
mostevil
United Kingdom611 Posts
On July 26 2012 19:38 urashimakt wrote: Show nested quote + 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! 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. Firstly thats obviously not the correct sequence, instant attack damage is resolved as the spell is cast/shot is fired not in a later cycle. Projectiles damage resolves when they hit the target. Secondly nothing in SC2 is randomized, the replay system relies on that (you can seed a random generator but implementations on different platforms vary, and random is not good for it being a viable esport). It's not really feasible to resolve all actions at once or as if they resolve at once, nor are the rewards worth the effort as it'll tripple the time spent in that routine. If a solution is needed then the direction of traversing the lists could alternate per game frame, effectively randomising which fires first for those of us living in human time. | ||
Cubu
1171 Posts
| ||
fabiano
Brazil4644 Posts
On July 26 2012 22:15 Cubu wrote: I wish the game was designed so that both units would die at the same time. More fair that way. 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: | ||
AlanSmithee
39 Posts
On July 26 2012 22:29 fabiano wrote: Show nested quote + On July 26 2012 22:15 Cubu wrote: I wish the game was designed so that both units would die at the same time. More fair that way. 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: 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. | ||
Aerisky
United States12128 Posts
| ||
Heh_
Singapore2712 Posts
| ||
Cyber_Cheese
Australia3615 Posts
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. The buildings would have their own id's too, as well as the workers creating them. On July 26 2012 22:34 AlanSmithee wrote: Show nested quote + On July 26 2012 22:29 fabiano wrote: On July 26 2012 22:15 Cubu wrote: I wish the game was designed so that both units would die at the same time. More fair that way. 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: 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. There is no real world equivalent of a lot of things in StarCraft, how does that mean two identical units shouldn't be exactly even? | ||
fabiano
Brazil4644 Posts
On July 26 2012 22:34 AlanSmithee wrote: Show nested quote + On July 26 2012 22:29 fabiano wrote: On July 26 2012 22:15 Cubu wrote: I wish the game was designed so that both units would die at the same time. More fair that way. 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: 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. 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". | ||
Aerisky
United States12128 Posts
On July 26 2012 22:40 Heh_ wrote: The number of 1-post users from Poland is amazing, especially the accounts which were created today. 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 ^^ | ||
Heh_
Singapore2712 Posts
On July 26 2012 22:45 Aerisky wrote: Show nested quote + On July 26 2012 22:40 Heh_ wrote: The number of 1-post users from Poland is amazing, especially the accounts which were created today. 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 ^^ Well I hope that's true. There's 1 user with an account created in March so that user has been lurking for a bit. | ||
AlanSmithee
39 Posts
On July 26 2012 22:43 fabiano wrote: Show nested quote + On July 26 2012 22:34 AlanSmithee wrote: On July 26 2012 22:29 fabiano wrote: On July 26 2012 22:15 Cubu wrote: I wish the game was designed so that both units would die at the same time. More fair that way. 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: 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. 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". That's just what i said, it's a choice of design. Check few posts back and you'll see I was making the same argument you are. In theory, yes, the common paradigm is something like what you are talking about, but it's ofcourse situational. There is more then following code standards to take in to consideration. I am trying to think about other RTS games in my head atm (like C&C, AoE, WC (same publisher though), dune etc) and from memory I think they all use the same paradigm. I can't recall a situation were two units kill each other in a 1on1 fight with instant shots. What do you think? | ||
FeyFey
Germany10114 Posts
Oh and sc2 has randomizers, burrow has a random timer to it. | ||
renkin
France249 Posts
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 ? | ||
Ayoeme
Latvia59 Posts
+ Show Spoiler + 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. About the topic: not only queue order is a given, there is also network environment to take in hand. If i send a command from US East to Korea sever, it will be much slower than a guy sending a same command from Korea itself. Given that we have a method to sync up our action, the data procession time will be different along with our computer specs etc... To much random element and the lack of LAN environment simply make the problem inconclusive. Pretty much /thread made me vomit. Can't even comprehend the amount of crap and unrelated "theory" in this post. I guess it would be possible to run the update of the entire structure, which then calls for separate functions that don't collide while processing after the update, destroying your CPU in the process. Though i might be wrong as calling a function is an action by itself. On a more serious note, to answer a question this wouldn't really influence infestors as neural parasite projectile has a few random assets to it. And yes, while playwise this information isn't really breathtaking, it still is really interesting. Good job. | ||
X3GoldDot
Malaysia3840 Posts
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 ? no effect whatsoever on anything except for spellcaster wars, all units have a random delay(extremely small) added to their normal attack, which will seperate the winners of a given battle. | ||
CzaRyMaRy
2 Posts
| ||
Ayoeme
Latvia59 Posts
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. palm-to-the-face'ed when read the thing about queens. Trolling, perhaps. Although i know not the specifics of attack delays, the thing you said about zerglings and ultras should not be accurate, because of the mentioned attack delay, and the younger one should have a win-advantage of the likes of 50001-to-49999. | ||
Cuce
Turkey1127 Posts
ıntresting, it would be wild thing if random attack delays are using a seed base on production times. | ||
roemy
Germany432 Posts
but i do think it's not the most elegant mechanic. i would prefer a tiny spell duration so both units would kill each other. off topic: also: add a tiny attack 'delay' to siege tanks so they overkill dropped zealots again ^^ | ||
Prillan
Sweden350 Posts
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! Standard attacks have a short random delay. You should test all other spells (yamato, snipe, etc.) | ||
InPlainSight
New Zealand40 Posts
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 ^^ Because seige tanks need nerfing. | ||
Xpace
United States2209 Posts
| ||
| ||
[ Submit Event ] |
StarCraft 2 StarCraft: Brood War Dota 2 Counter-Strike Super Smash Bros Heroes of the Storm Other Games tarik_tv17353 qojqva4330 Grubby3242 Liquid`RaSZi2399 gofns1738 shahzam693 ArmadaUGS582 sgares547 Mew2King272 NuckleDu88 ViBE25 Organizations Counter-Strike StarCraft 2 StarCraft: Brood War StarCraft 2 StarCraft: Brood War
StarCraft 2 • musti20045 26 StarCraft: Brood War• davetesta12 • Gussbus • Poblha • Migwel • Laughngamez YouTube • LaughNgamez Trovo • IndyKCrew • aXEnki • Kozan • intothetv Dota 2 League of Legends Other Games |
StarsWar
Maru vs Stats
Cure vs Classic
Solar vs GuMiho
ByuN vs herO
Big Brain Bouts
BSL
TerrOr vs XuanXuan
Dark vs JDConan
Korean StarCraft League
StarsWar
WardiTV Invitational
CSO Cup
ForJumy Cup
BSL
Zhanhun vs WolFix
Dienmax vs Cross
Sparkling Tuna Cup
[ Show More ] StarsWar
WardiTV Invitational
ESL Open Cup
Afreeca Starleague
StarsWar
ESL Open Cup
ESL Open Cup
Afreeca Starleague
StarsWar
Club NV x Duckling Show…
GSL Code S
Stats vs SHIN
Cure vs GuMiho
|
|