• Log InLog In
  • Register
Liquid`
Team Liquid Liquipedia
EDT 06:01
CEST 12:01
KST 19:01
  • Home
  • Forum
  • Calendar
  • Streams
  • Liquipedia
  • Features
  • Store
  • EPT
  • TL+
  • StarCraft 2
  • Brood War
  • Smash
  • Heroes
  • Counter-Strike
  • Overwatch
  • Liquibet
  • Fantasy StarCraft
  • TLPD
  • StarCraft 2
  • Brood War
  • Blogs
Forum Sidebar
Events/Features
News
Featured News
Power Rank - Esports World Cup 202550RSL Season 1 - Final Week9[ASL19] Finals Recap: Standing Tall15HomeStory Cup 27 - Info & Preview18Classic wins Code S Season 2 (2025)16
Community News
BSL Team Wars - Bonyth, Dewalt, Hawk & Sziky teams4Weekly Cups (July 14-20): Final Check-up0Esports World Cup 2025 - Brackets Revealed19Weekly Cups (July 7-13): Classic continues to roll8Team TLMC #5 - Submission re-extension4
StarCraft 2
General
RSL Revival patreon money discussion thread Power Rank - Esports World Cup 2025 Jim claims he and Firefly were involved in match-fixing RSL Season 1 - Final Week The GOAT ranking of GOAT rankings
Tourneys
Esports World Cup 2025 Sparkling Tuna Cup - Weekly Open Tournament Sea Duckling Open (Global, Bronze-Diamond) FEL Cracov 2025 (July 27) - $8000 live event RSL: Revival, a new crowdfunded tournament series
Strategy
How did i lose this ZvP, whats the proper response
Custom Maps
External Content
Mutation #239 Bad Weather Mutation # 483 Kill Bot Wars Mutation # 482 Wheel of Misfortune Mutation # 481 Fear and Lava
Brood War
General
[Update] ShieldBattery: 1v1 Fastest Support! Ginuda's JaeDong Interview Series BW General Discussion ASL20 Preliminary Maps BGH Auto Balance -> http://bghmmr.eu/
Tourneys
CSL Xiamen International Invitational [Megathread] Daily Proleagues [CSLPRO] It's CSLAN Season! - Last Chance [BSL 2v2] ProLeague Season 3 - Friday 21:00 CET
Strategy
Simple Questions, Simple Answers I am doing this better than progamers do.
Other Games
General Games
Stormgate/Frost Giant Megathread Nintendo Switch Thread [MMORPG] Tree of Savior (Successor of Ragnarok) Path of Exile CCLP - Command & Conquer League Project
Dota 2
Official 'what is Dota anymore' discussion
League of Legends
Heroes of the Storm
Simple Questions, Simple Answers Heroes of the Storm 2.0
Hearthstone
Heroes of StarCraft mini-set
TL Mafia
TL Mafia Community Thread Vanilla Mini Mafia
Community
General
Things Aren’t Peaceful in Palestine US Politics Mega-thread Russo-Ukrainian War Thread The Games Industry And ATVI Stop Killing Games - European Citizens Initiative
Fan Clubs
SKT1 Classic Fan Club! Maru Fan Club
Media & Entertainment
[\m/] Heavy Metal Thread Anime Discussion Thread Movie Discussion! [Manga] One Piece Korean Music Discussion
Sports
2024 - 2025 Football Thread Formula 1 Discussion TeamLiquid Health and Fitness Initiative For 2023 NBA General Discussion
World Cup 2022
Tech Support
Installation of Windows 10 suck at "just a moment" Computer Build, Upgrade & Buying Resource Thread
TL Community
The Automated Ban List
Blogs
Ping To Win? Pings And Their…
TrAiDoS
momentary artworks from des…
tankgirl
from making sc maps to makin…
Husyelt
StarCraft improvement
iopq
Socialism Anyone?
GreenHorizons
Customize Sidebar...

Website Feedback

Closed Threads



Active: 866 users

[DISCOVERY] 2x high templar feedback - older dies - Page 8

Forum Index > SC2 General
Post a Reply
Prev 1 6 7 8 9 10 Next All
The Touch
Profile Joined September 2010
United Kingdom667 Posts
July 26 2012 09:24 GMT
#141
1, 2, 3, 4, 5, 6, and 7.

7 High Templar, a-ha-ha
You Got The Touch
AcrosstheSky
Profile Joined January 2011
United States237 Posts
Last Edited: 2012-07-26 09:47:42
July 26 2012 09:43 GMT
#142
Is it which one is produced first or which one has less energy on it?

Very nice job!
Thylacine
Profile Joined August 2011
Sweden882 Posts
July 26 2012 09:56 GMT
#143
Mysterious..
What you're looking at could be the end of a particularly terrifying nightmare. It isn't. It's the beginning. Introducing Mr. John Valentine, air traveler. His destination: the Twilight Zone...
ThePlayer33
Profile Joined October 2011
Australia2378 Posts
July 26 2012 09:59 GMT
#144
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
| Idra | YuGiOh | Leenock | Coca |
pms
Profile Joined April 2008
Poland611 Posts
July 26 2012 10:02 GMT
#145
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...).
scsnow
Profile Joined April 2010
Slovenia515 Posts
July 26 2012 10:11 GMT
#146
The older one is more experienced, of course he wins!
Pandemona *
Profile Blog Joined March 2011
Charlie Sheens House51484 Posts
July 26 2012 10:13 GMT
#147
Polish SC2 Mythbusters, well i'll be XD good job keep it up
ModeratorTeam Liquid Football Thread Guru! - Chelsea FC ♥
Yegwen
Profile Joined September 2011
Poland80 Posts
July 26 2012 10:25 GMT
#148
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.
We don't grow old, we get old by not growing
dani`
Profile Joined January 2011
Netherlands2402 Posts
July 26 2012 10:33 GMT
#149
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
Profile Joined October 2009
United States1591 Posts
Last Edited: 2012-07-26 10:42:36
July 26 2012 10:38 GMT
#150
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.
Who dat ninja?
Bagi
Profile Joined August 2010
Germany6799 Posts
July 26 2012 10:48 GMT
#151
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
Profile Joined May 2012
39 Posts
Last Edited: 2012-07-26 11:36:50
July 26 2012 11:21 GMT
#152
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
Profile Joined January 2009
New Zealand40 Posts
July 26 2012 11:42 GMT
#153
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
Profile Joined May 2012
39 Posts
July 26 2012 11:52 GMT
#154
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
Profile Joined January 2009
New Zealand40 Posts
July 26 2012 12:03 GMT
#155
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
Profile Joined May 2012
39 Posts
Last Edited: 2012-07-26 12:09:03
July 26 2012 12:08 GMT
#156
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
Profile Joined January 2009
New Zealand40 Posts
July 26 2012 12:17 GMT
#157
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
Profile Blog Joined February 2011
Israel1818 Posts
July 26 2012 12:23 GMT
#158
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.
/commercial
CamoPillbox
Profile Joined April 2012
Czech Republic229 Posts
Last Edited: 2012-07-26 13:00:28
July 26 2012 12:55 GMT
#159
i only wonder if it working on SC1 too..... i tested on zealot ling and marine works 100% same as with feedback ht.
Czech Terran(Hots) player
HeavOnEarth
Profile Blog Joined March 2008
United States7087 Posts
July 26 2012 13:01 GMT
#160
applies to larva selection iirc
"come korea next time... FXO house... 10 korean, 10 korean"
Prev 1 6 7 8 9 10 Next All
Please log in or register to reply.
Live Events Refresh
Esports World Cup
10:00
2025 - Day 3
Reynor vs Zoun
Solar vs SHIN
Classic vs ShoWTimE
Cure vs Rogue
EWC_Arena3095
ComeBackTV 462
EWC_Arena_2381
Hui .261
TaKeTV 103
CranKy Ducklings74
Rex54
3DClanTV 52
Reynor42
mcanning36
LiquipediaDiscussion
[ Submit Event ]
Live Streams
Refresh
StarCraft 2
EWC_Arena3095
EWC_Arena_2381
Hui .261
Rex 54
Reynor 42
mcanning 36
SpeCial 12
StarCraft: Brood War
firebathero 1320
Bisu 1242
BeSt 750
Jaedong 710
Hyuk 491
ggaemo 481
ToSsGirL 212
Leta 212
JulyZerg 161
EffOrt 158
[ Show more ]
Hyun 132
Soma 119
Zeus 107
actioN 88
soO 40
ZerO 38
NaDa 37
Sacsri 34
sorry 31
Mind 28
Sharp 24
Noble 18
yabsab 17
ivOry 5
Britney 0
Dota 2
XcaliburYe280
BananaSlamJamma192
Counter-Strike
shoxiejesuss480
allub271
x6flipin209
Other Games
singsing1794
ceh9756
Happy339
crisheroes225
Fuzer 194
ZerO(Twitch)5
Organizations
Other Games
gamesdonequick1130
StarCraft 2
Blizzard YouTube
StarCraft: Brood War
BSLTrovo
sctven
[ Show 15 non-featured ]
StarCraft 2
• Berry_CruncH250
• LUISG 11
• AfreecaTV YouTube
• intothetv
• Kozan
• IndyKCrew
• LaughNgamezSOOP
• Migwel
• sooper7s
StarCraft: Brood War
• iopq 2
• BSLYoutube
• STPLYoutube
• ZZZeroYoutube
League of Legends
• Stunt631
Other Games
• WagamamaTV176
Upcoming Events
Esports World Cup
1d 1h
OSC
1d 4h
CranKy Ducklings
2 days
BSL20 Non-Korean Champi…
2 days
CSO Cup
2 days
BSL20 Non-Korean Champi…
2 days
Bonyth vs Sziky
Dewalt vs Hawk
Hawk vs QiaoGege
Sziky vs Dewalt
Mihu vs Bonyth
Zhanhun vs QiaoGege
QiaoGege vs Fengzi
FEL
2 days
BSL20 Non-Korean Champi…
3 days
BSL20 Non-Korean Champi…
3 days
Bonyth vs Zhanhun
Dewalt vs Mihu
Hawk vs Sziky
Sziky vs QiaoGege
Mihu vs Hawk
Zhanhun vs Dewalt
Fengzi vs Bonyth
Sparkling Tuna Cup
5 days
[ Show More ]
Online Event
5 days
uThermal 2v2 Circuit
6 days
The PondCast
7 days
Liquipedia Results

Completed

CSL Xiamen Invitational
Championship of Russia 2025
Murky Cup #2

Ongoing

Copa Latinoamericana 4
Jiahua Invitational
BSL20 Non-Korean Championship
Esports World Cup 2025
CC Div. A S7
Underdog Cup #2
IEM Cologne 2025
FISSURE Playground #1
BLAST.tv Austin Major 2025
ESL Impact League Season 7
IEM Dallas 2025
PGL Astana 2025
Asian Champions League '25

Upcoming

CSLPRO Last Chance 2025
ASL Season 20: Qualifier #1
ASL Season 20: Qualifier #2
ASL Season 20
CSLPRO Chat StarLAN 3
BSL Season 21
RSL Revival: Season 2
Maestros of the Game
SEL Season 2 Championship
uThermal 2v2 Main Event
FEL Cracov 2025
HCC Europe
ESL Pro League S22
StarSeries Fall 2025
FISSURE Playground #2
BLAST Open Fall 2025
BLAST Open Fall Qual
Esports World Cup 2025
BLAST Bounty Fall 2025
BLAST Bounty Fall Qual
TLPD

1. ByuN
2. TY
3. Dark
4. Solar
5. Stats
6. Nerchio
7. sOs
8. soO
9. INnoVation
10. Elazer
1. Rain
2. Flash
3. EffOrt
4. Last
5. Bisu
6. Soulkey
7. Mini
8. Sharp
Sidebar Settings...

Advertising | Privacy Policy | Terms Of Use | Contact Us

Original banner artwork: Jim Warren
The contents of this webpage are copyright © 2025 TLnet. All Rights Reserved.