EPTThey could change any unit colision size by just editing one single variable. Units in SC2 clump up together more closer than in SC1 because their colision box (or circle even) is smaller. Nothing else, absolutely nothing else. They clump up to that position faster (ie: the "auto-surround" behaviour you see) because of the faster response (ie: looking for a way around another unit every 0.1sec instead of every 0.5sec, which also makes the game more responsive and natural). That is all intentional. They could change it whenever they felt like it. They will change it if they feel like it. We will only know if it's "too small" or "too fast" or whatever, and give proper feedback, when we get our hands on it and play it. Chill out, and wait for beta.
[D] Pathfinding in SC2 - Page 4
| Forum Index > SC2 General |
|
VIB
Brazil3567 Posts
They could change any unit colision size by just editing one single variable. Units in SC2 clump up together more closer than in SC1 because their colision box (or circle even) is smaller. Nothing else, absolutely nothing else. They clump up to that position faster (ie: the "auto-surround" behaviour you see) because of the faster response (ie: looking for a way around another unit every 0.1sec instead of every 0.5sec, which also makes the game more responsive and natural). That is all intentional. They could change it whenever they felt like it. They will change it if they feel like it. We will only know if it's "too small" or "too fast" or whatever, and give proper feedback, when we get our hands on it and play it. Chill out, and wait for beta. | ||
|
Funchucks
Canada2113 Posts
| ||
|
MultiMarine
Sweden39 Posts
On April 05 2008 08:21 VIB wrote: What they're calling "magic boxes" are known as "colision boxes" in any video game since freaking pacman. They're programed on purpose, there is no such thing as an "accidental 2d specific bug" leading to colision boxes. It's a simple "if (SomeUnitPosition - AnotherUnitPosition <= SomeUnitColisionSize) then StopMoving". If you were a programmer like you said, or if you had the slightest superficial idea of what programming is, you would surelly know this. They could change any unit colision size by just editing one single variable. Units in SC2 clump up together more closer than in SC1 because their colision box (or circle even) is smaller. Nothing else, absolutely nothing else. They clump up to that position faster (ie: the "auto-surround" behaviour you see) because of the faster response (ie: looking for a way around another unit every 0.1sec instead of every 0.5sec, which also makes the game more responsive and natural). That is all intentional. They could change it whenever they felt like it. They will change it if they feel like it. We will only know if it's "too small" or "too fast" or whatever, and give proper feedback, when we get our hands on it and play it. Chill out, and wait for beta. Do you really belive there is no difference in collision detection between 3D and 2D? Can you please describe to me how 2D and 3D is the same when a unit has to stand right behind another on the Z axis? | ||
|
MultiMarine
Sweden39 Posts
On April 05 2008 08:18 Funchucks wrote: Jesus... play the game a little. It works for flying units as well, and they don't even bother with pathfinding. Get some mutalisks together, select them all at once, send them to a place within the bounding box of their group - they bunch up. Get some mutalisks together, select them all at once, send them to a place outside of their group - they keep the same relative distance. The bounding box of their group is the "magic box". Anyone who knows anything about game programming would find it absolutely obvious that there is a bit of code in the Starcraft source that looks something like this: if (destination_in_box(current_destination, bounding_box_of_selection(current_selection))){ send_all_to_destination(current_selection,current_destination); }else{ current_center=box_center(bounding_box(current_selection)); for(each unit in current_selection){ unit_displacement=unit_displacement_from_center(unit, current_center); unit_destination=destination_displaced_from_center(unit_displacement, current_destination); send_to_destination(unit, unit_destination); } } Now, various exploits of this code may be considered bugs, but if you think the magic boxes themselves just happened accidentally, you're an idiot. Im gonna start a new thread about how new players that don't know any stracraft history has no idea what was intentional and not in Starcraft. I think this would be a big eye opener for alot of people. And people would stop trusting Blizzard knows exactly what they are doing. | ||
|
Funchucks
Canada2113 Posts
On April 05 2008 08:52 MultiMarine wrote: Do you really belive there is no difference in collision detection between 3D and 2D? Can you please describe to me how 2D and 3D is the same when a unit has to stand right behind another on the Z axis? The game logic for Starcraft 2 will almost certainly be 2d and tile-based, as it was in Warcraft 3. Units move in two planes: ground and air, which are divided into small squares. When a unit moves on the ground plane, it identifies one square as its position, and marks that square and a pattern of surround squares as occupied by it. (burrowed units and flying units don't mark squares as occupied) When units are pathfinding, they only have to look at the map of occupied spaces to see where they can and can't go. Area effect spells and attacks do something similar (the "occupied space" map is probably a flat 2d array, while the "location" or "vulnerability to attack" map is probably a grid of linked list heads - that's how I'd do it, anyway). Starcraft has a lot of clever little tricks programmed into behaviors related to the map. For instance, if a unit is sitting on top of space occupied by other units or buildings, it just walks out of the occupied space. Mining SCVs pass through unit-occupied space, but not building-occupied space, etc. Starcraft doesn't do "collision detection" as such, and neither will Starcraft 2. Everything is based on occupation of spaces on a grid. This is why there are so many exploitable stacking mechanics. The SC2 team could probably change the game to have an ugly 2d graphics engine in a few days of work, because the 3d graphics are only a representation of an underlying 2d model. I've programmed RTSs (nothing great, just little ones for fun). You obviously know nothing and should stop spreading bad information. | ||
|
teamsolid
Canada3668 Posts
On April 05 2008 07:45 MultiMarine wrote: I just want to make this really clear! - Magic boxes is a made up word and concept from a TL poster. - Blizzard never knew they created "magic boxes" while coding. - "Magic boxes" is a "bug" in a 2D world with imperfect pathfinding. - Units clump because 3D models can move and interact perfectly in a 3D world, while in 2D you have to move squares around no matter what the unit looks like. 2D creates alot of bugs in the pathfinding and the collision detection since you are not working with 3D models but with sprites. -Yes, the name might've been made up, but the concept is very real and can be easily demonstrated in the game. It may not have been noticed before by the players until July started abusing it, but it was always there. Whether it's unintentional or not, it doesn't matter, because it's good for the game. -No, it has nothing to do with 3-D. How does a 3-D world change unit pathing? Units don't "jump" up in the Z-axis to move around another unit, they have to walk around (X/Y-axis) in the same way a 2-D based map works. Use your brain. -No, the interaction between units (i.e. collision detection) is 2-D based. Just look at War3. Units have very large collision sizes which causes units to trip up all the time, which allows players to surround and block units. | ||
|
BluzMan
Russian Federation4235 Posts
On April 05 2008 09:01 MultiMarine wrote: Im gonna start a new thread about how new players that don't know any stracraft history has no idea what was intentional and not in Starcraft. I think this would be a big eye opener for alot of people. And people would stop trusting Blizzard knows exactly what they are doing. I'm gonna start a thread about how ridiculously hard it is to program in something like magic boxes by accident. Someone had to code in the constants (hardcode, they're not in the datafiles). It is perfectly ok to assume that this feature was not known to the Blizzard PR guys, but to assume it's accidential is idiocy. Not because "Blizzard is god they know what they're doing", but because lines of code of such complexity don't fucking appear by themselves. Is that hard to get? You were at WCG, that's cool, but aside from your claim you were there, you have done exactly nothing, so you don't really start acting like a prophet who's going to open everyone's eyes, ok? | ||
|
[X]Ken_D
United States4650 Posts
On April 05 2008 11:04 Funchucks wrote: The game logic for Starcraft 2 will almost certainly be 2d and tile-based, as it was in Warcraft 3. Units move in two planes: ground and air, which are divided into small squares. When a unit moves on the ground plane, it identifies one square as its position, and marks that square and a pattern of surround squares as occupied by it. (burrowed units and flying units don't mark squares as occupied) what about slopes? | ||
|
Luhh
Sweden2974 Posts
Formation (magic boxes) In Brrodwar, units behave and execute attacks/abilities/movement in "formation behaviour" when they are within "the magic box" - ie a certain distance from one another. Thus they'll maintain their relative distance from one another when moved about etc, unless they have to navigate and obstacle (I'm not sure if a unit end up in the "predetermined formation position" afterwards if it had to navigate and obstacle which delayed it compared to the other units (while no other movement input were added to the unit group, but I believe so.) Minelaying and spellcasting may be unintentional effects to this, since they use the same functions. (positive ones though). Unit grouping (air unit stacking) The other behaviour, ie unit clumping, occurs when units are grouped and ordered that find themselves outside the "magic box" and thus all units strive to reach the same coordinate. This because in 99% of all unit movement situation where the units are widely spaced you'd like them to form up, and not move in a formation wide enough to span the map. "Side effects" to this is of course the "muta stack "bug"" (again poorly phrased by whomever) since it's an intentional unit movement behaviour used, and not a glitch. So magic boxes does not have to do with collision detection (only indirectly), and I find it very hard that this formation versus grouping behaviour is unintentional and a pathing bug. They seem like two distinct and coded units behaviours that are logical as well. - Thank you, and let discussion recommence. | ||
|
MultiMarine
Sweden39 Posts
Do you really think Blizzard had a meeting when someone said... oh btw.. units should behave in different ways depending on the magic boxes! | ||
|
BluzMan
Russian Federation4235 Posts
On April 05 2008 19:35 MultiMarine wrote: I'm not saying the units walking in formations was unitentional. I'm saying units behaving differently inside and outside of "magic boxes" were. Do you really think Blizzard had a meeting when someone said... oh btw.. units should behave in different ways depending on the magic boxes! I stopped understanding wtf you're talking about. Either way, it's complete nonsense. Btw, 3D pathfinding isn't fundamentally different from 2D. Actually, it is not different at all. Take a piece of paper, draw a tank, then draw a destination point. Feel free to also draw "placeholders" for rocks and other shit that blocks it's path. Now fold the piece. Does the trajectory change? For the observer, yes it does. But for the unit, it doesn't. It still has to do the same movement, because even a 3D unit that is deterministically tied to a surface, is essentially 2D. Terrain folding and slopes are a mere change of metrics which, as we all know from differential geometry, is only felt "outside" the system, but not "inside" it. Your unit still uses the pathfinding algorythms for a plane, the complexity of the surface for it doesn't exist, it only exists for you, the observer, since you are in the third dimension. At least this is how it done for the dominating majority of RTS'es in 3D and I don't think SC II will be any different. The only reason to do otherwise would be including realistic gravity in the behavior of ground units (climbing is harder than going down etc), because the gravity vector does not transform with the surface and isn't affected by metrics. But that feature in StarCraft would only bring unneeded complexity and will not be in. Also, 3D pathfinding uses collision sizes like 2D does. The only difference of SC collision from War III collision is that in War3, collision bounds are being represented by circles, whereas in SC, they are represented by rectangles. That difference is the only one, being there due to increased processor power, so that more complex calculations can be done without hampering play experience. But they smooth out pathfinding, so such a tradeoff is worthwhile. "True" 3D pathfinding (that is based on objects not overlapping) is a remarkably redundant feature for an RTS, as it add a CRAPLOAD of unneeded complex math for an unnoticeable increase in realism. Models nowadays are extremely complex, why the hell calculate their collisions when you can just represent them with a circle and achieve similar results for no processor power? Sure, sometimes units will overlap abit. But they overlap in Warcraft III, Dawn of War, Command & Conquer 3 and noone seems to care. | ||
|
Unentschieden
Germany1471 Posts
Magic boxes are a unitntuitive and comperativly "weak" mechanic (doesn´t work with obstacles) so it is no surprise Blizzard never told anyone about it. On the other hand they improve pathfinding for small groups over small distances, ergo in battles. We don´t know yet how they will handle it in SC2, personally I hope for a switch in the UI like in WC3. Naturally that requires the pathfinding AI to improve. | ||
|
KonekoTyriin
United States60 Posts
For example, if two units are very far apart, they should not maintain formation. Their relative positions are likely irrelevant to the player anyway. If you have two zealots on the 12 and 6 mains of Lost Temple, for example, and you tell them to move to a different main, it wouldn't make sense for the zealots to move to the places above and below the target location. That would be frustrating. So: Check to see if the units are far apart. If they are, don't maintain formation. BUT if the units are very close, and the player has made an intricate formation, it would be frustrating for that formation to disappear just because he wanted to move his units forward. Therefore it's best to keep formation if units are all within a small area. (As a side note, I believe 'korean casting' is a consequence of this. Casters choose their targets using the same algorithm as all units choose destinations. So psi storms are centered at the places the templar would move to if the command issued was a move command instead of storm.) So: Check to see if the units are close together. If they are, do maintain formation. This gives rise to the different behavior inside and outside of what the community has termed "magic boxes." The magic box is really just the maximum distance apart units can be before the game ignores the formation of the units. If units are in magic boxes, they keep formation and do korean casting. Otherwise, to prevent weird, frustrating, and non-useful pathfinding, they ignore formation. It makes sense to me. Please tell me what you think is wrong with my analysis. I have been playing starcraft for only 2 years and have never been to Korea or played in a WCG, and I'm only in school learning to be a programmer, so it is possible that I am missing something here. Thank you. | ||
|
BluzMan
Russian Federation4235 Posts
On April 06 2008 02:37 KonekoTyriin wrote: Yeah, I think some programmer at Blizzard thought about the pathfinding algorithm and decided that it was best to split up the pathfinding task based on unit distance. For example, if two units are very far apart, they should not maintain formation. Their relative positions are likely irrelevant to the player anyway. If you have two zealots on the 12 and 6 mains of Lost Temple, for example, and you tell them to move to a different main, it wouldn't make sense for the zealots to move to the places above and below the target location. That would be frustrating. So: Check to see if the units are far apart. If they are, don't maintain formation. BUT if the units are very close, and the player has made an intricate formation, it would be frustrating for that formation to disappear just because he wanted to move his units forward. Therefore it's best to keep formation if units are all within a small area. (As a side note, I believe 'korean casting' is a consequence of this. Casters choose their targets using the same algorithm as all units choose destinations. So psi storms are centered at the places the templar would move to if the command issued was a move command instead of storm.) So: Check to see if the units are close together. If they are, do maintain formation. This gives rise to the different behavior inside and outside of what the community has termed "magic boxes." The magic box is really just the maximum distance apart units can be before the game ignores the formation of the units. If units are in magic boxes, they keep formation and do korean casting. Otherwise, to prevent weird, frustrating, and non-useful pathfinding, they ignore formation. It makes sense to me. Please tell me what you think is wrong with my analysis. I have been playing starcraft for only 2 years and have never been to Korea or played in a WCG, and I'm only in school learning to be a programmer, so it is possible that I am missing something here. Thank you. It doesn't take a WCG presence to write a good post, and you just proved it. | ||
|
Funchucks
Canada2113 Posts
Height and slope just are properties of the tiles. A tile might be marked "flat: height=5" or "slope: 4 to 5" (obviously, not with words and numbers, but in coded data that can be intepreted this way). I might remember the mechanic wrong, but I believe slopes do work differently. You shoot as if standing on the lower level, but see as if standing on the higher level. If that isn't true, there might not be a slope code at all, and ramps are just marked as being the same height as the higher level they lead to. Anyway, the point is not the specifics (which I might have slightly wrong), but the principle: tiles can have very simple properties which can create the appearance of a complex environment. Other tile properties would include "can't walk on" and "can't build here". They could easily have had properties such as "passable only by hovering units", "navigable only by watercraft and amphibious units", "rough ground, movement slowed", "hard ground - no burrowing", etc. but they chose not to put those in. | ||
|
funkie
Venezuela9376 Posts
plz close and featured. | ||
|
InRaged
1047 Posts
On April 05 2008 18:23 Luhh wrote: (I'm not sure if a unit end up in the "predetermined formation position" afterwards if it had to navigate and obstacle which delayed it compared to the other units (while no other movement input were added to the unit group, but I believe so.) Yes, units end up in the right position if you don't interrupt. But almost every time, player does issue new move order before units are finished relocating, thereby he forces the game to memorize new distances. That's probably the main difference between "magic boxes" and "user-defined formation", and that's the biggest problem of magic boxes in starcraft (at least for me...). The gross thing, starcraft, having pretty rough mechanics, have got plenty of ways to fuck up this distance besides natural (and unnatural) map obstacles: - relatively slow reaction time - some units in group react later than other causing unneeded spacing - bizarre turn around mechanics of air units and couple others  . I really don't know how to explain that, but this very mechanics is also the cause of famous and funny scv dance (when you command move to fast in opposite directions unit starts fidgeting perpendicularly to your order)- units move only in 16 (unique ^_^) directions. So instead of moving directly to their new destination each unit calculate their own path based on this restriction and the further units are from each other the more differences in their paths. Good thing is that at least 2 of these issues (first and last) are no existent in sc2 and even if blizz devs include magic boxes without any improvements it still will work much more smoother and pleasing than before. | ||
|
Zanno
United States1484 Posts
On April 05 2008 02:22 teamsolid wrote: Nobody could understand it because everyone thought that you could turn it off by disabling formations, goes to show how exactly how much people the people incessantly bashing warcraft 3 have played itBut the post quality was horrendous, both spelling/grammar and logic wise (just like the other thread he created, which no one could even understand after reading the whole post). Magic box has been brought up before many times and I think it was generally agreed that we want it in SC2, and could be asked in the "submit your questions" thread to Blizzard. FYI, collision detection in sc and war3 the same - every unit has a circle around it. War3 is only 3d visually, gameplay wise it is still a 2d game. I imagine SC2 will be the same way. | ||
|
DTDominion
United States2148 Posts
| ||
|
Funchucks
Canada2113 Posts
It would also be nice if you could tell a group of units to attack through a choke, and the first one to reach firing range won't stop in the choke and block all of the other units from attacking. | ||
| ||
