|
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.
|
I wish the game was designed so that both units would die at the same time. More fair that way.
|
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:
|
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.
|
Hm...this is pretty interesting. I don't think it should create any huge changes in the metagame or anything like, but it's interesting nonetheless. I wonder whether this was a rather incompetent mistake or whether this was actually implemented on purpose for some reason.
|
The number of 1-post users from Poland is amazing, especially the accounts which were created today.
|
On July 26 2012 05:31 JinDesu wrote:Show nested quote +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.
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?
|
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".
|
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 ^^
|
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.
|
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?
|
so the newest units actions come into effect first, this is pretty common, thats why you add small random delays to stuff like this. Understandable that they left it out with marine kiting being so important. Adding a failsave for this would make instant attack units stronger, and they are already favored through the ai.
Oh and sc2 has randomizers, burrow has a random timer to it.
|
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 ?
|
Agree with alot what AlanSmithee said. Also this:
+ 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.
|
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.
|
I checked it out and it's the same with zerglings and ultralisks - the younger always wins. BTW Queens are interesting exception - they both die.
|
On July 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.
|
hmm
ıntresting, it would be wild thing if random attack delays are using a seed base on production times.
|
cute find, but i'm not too worried. unless someone has an eidetic memory combined with an awesome eye for a shellgame of 'find the oldest caster unit in your saved group', i don't see a lot of applications for this little gem -.-
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 ^^
|
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.)
|
|
|
|
|
|
EPT
