|
1, 2, 3, 4, 5, 6, and 7.
7 High Templar, a-ha-ha
|
Is it which one is produced first or which one has less energy on it?
Very nice job!
|
|
|
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
|
It's quite obvious from programming perspective: there is a loop in the code which checks damage dealt and units deaths. Apparently this loops iterates over units in the sequence of their creation (which is just a normal way of doing it, but maybe in sc2 some other solution should be applied, since it makes a difference in the game...).
|
The older one is more experienced, of course he wins!
|
Pandemona
Charlie Sheens House51493 Posts
Polish SC2 Mythbusters, well i'll be XD good job keep it up
|
Well answering the questions regarding who we are and what we do - I run a regular polish starcraft 2 television on twitch.tv with a schedule we keep and all. Mythbusters is our new show - and we didn't expect the first episode to end with this interesting discovery.
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.
|
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 
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
i only wonder if it working on SC1 too..... i tested on zealot ling and marine works 100% same as with feedback ht.
|
applies to larva selection iirc
|
|
|
|
|
|
EPT
