test content
Logo
What is the Arc Client?
Install Arc
Clean up Big Monster AoEs plez!
vonqball
Posts: 923 Arc User
I died to Mega Destroid frontal cone attack earlier today. I was standing about 5' behind his rear foot. I don't think that should happen. Attacks AoEs should be consistent with the animations. And frontal cones shouldn't hit people who are behind the..uhhhmm... coner! Ape breathes on his own butt, and Kiga does kiga things that kill people who get pushed too close. These invisible death zones should just go away.
Bubbles should also match up exactly with the AoE of the attack they are warning of. With lag and bodyblocking and all that fun stuff, we don't need visual misinformation too.
Think about it!
Bubbles should also match up exactly with the AoE of the attack they are warning of. With lag and bodyblocking and all that fun stuff, we don't need visual misinformation too.
Think about it!
0
Comments
I've never actually seen Ape hit people behind him, but he does have a fairly mean side zone on that.
An alternate fix to this would be to just make the VFX for the attack bigger so it actually fills the entire collision area - that would at least let us know why we just died instead of making us ask "Was it ghosts?". VFX and collision not matching up is apparently a long standing issue... remember how long it took them to make the lava patches at ape actually match up their VFX and collision?
My super cool CC build and how to use it.
Yeah, changing the VFX to include the "buttdeathzones" would also work. Like a ring of fire around ape while he breathes or something.
Ofc, if it only happens when the target is close then that makes finding a neat solution even more complicated.
Some of the AoEs are also mis-aligned in the 4th dimension too. Like, you need to block the destroid bubbles early to avoid maximum damage (I'm fine with that ofc)... but you don't actually have to be blocking when the explosion happens... which is just unacceptable silliness!
Separately from this, there are some tells that are just wrong. Other than PG, above, mega-destroid thunderclap has an orange bubble tell, but the bubble does not seem to have anything to do with where the attack actually hits.
Epic Stronghold
Block timing explained
Yah, I still only have a vague idea of what that orange-bubble attack actually looks like. Real area of affect seems quite small.
The blue box is an approximation of a player's hit volume. In this case, it's a cube that covers the entire body of the character. The yellow circle is an AoE being generated by a bomb going off, and in champions, this does and could have a sphere model that just about accurately reflects this AoE's volume (I say just about due to limitations of polycount versus the absolute roundness that can be reflected via coded AoEs, but that's a minor point.)
The red star shows the point at which the player's hit area intersects with the bombs blast, even though the visual character model is outside the radius of the blast. So while it looks like the player is safe, they are not. And this can happen surprisingly often even in 2D games, as it's generally much easier to measure how collisions interact between simple shapes (circles, squares) than it is to measure collisions between individual pixels of an image. I'm completely positive that the way that character hit areas in CO are calculated is by using crude cube volumes, or some other rough approximation like this - otherwise we wouldn't keep getting these issues of clicking randomly on an area even remotely close to a player model with big wings and targeting that person instead of what actual enemy we might want to be attacking.
It's kind of amusing because the issue of pixel-perfect collision is something that some games like Star Control 2 have solved creatively in the past, and yet we keep getting hung up on stuff like approximation of shape and the need to avoid concaves at all costs, when 90% of the time we aren't really even using the collisions to calculate physical reactions such as elasticity, which is mainly where those complexity issues arise.
While one solution is to use a much more detailed hit volume measure for hit detection - most FPS' use a plain cube or capsule for calculating hit detection for character movement, but then measure ray-traced bullet shots locationally on a set of shapes rigged to the approximate skeleton of a player model - This usually isn't necessary for games where high precision isn't necessary. That's usually something you see in the context of FPS simply because having reliable feedback is really important to making a player-versus-player, fast-paced chaotic game actually work properly.
A simpler solution that both saves player headache and conserves a lot of computation time would be to have AoEs like this just measured against the center point of a player - that's not even an extra component you need to tack on to an entity, all you do is create the attack's hit area and see whether the position of some target (npc or not) is within that area. That position data's already being leveraged by a ton of other things: determining where the character is standing, measuring line of sight... But it does raise some issues especially if this were to be leveraged on extremely large enemies. Thing is, this could be a feature only enabled for player entities or characters below some size limit (a limit beyond what players can achieve, barring the super-magnifier because it doesn't actually change your hitbox size and also doesn't really exist anymore). It also is an issue that already happens on some really big targets! Ever tried using a cone AoE combo on a giant monster to just have certain hits not register? I know I have. Actually, I've had that happen on things that aren't even giant monsters:
(if it's not linking to the middle of the video, go to 7:34 to see me fail to hit an object with a combo)
Which makes me suspect another factor that's more directly related to the FOOM issue at hand:
That's really insidious, because using only the information of 'degrees coverage' and 'range' as a basis for constructing a cone hit area, this is how I'd do it:
- Start with a sphere with a radius that is the range of the cone, and a vector line indicating the direction the cone is being aimed.
- Exclude all area that is beyond a specific angle's difference from the vector. This would produce a circle intersecting the sphere, perpendicular to that vector.
- Perform hit detection. Any hitboxes that satisfy a ray-trace from the origin of the cone, to a point on the sphere that is on the same side as the main direction vector as that circle, counts as a hit.
The only major advantage this has versus defining a cone by "range and radius" rather than "range and angle" is that the cone can then be conditioned to reach beyond 180 degrees, forming a hit area that's like a sphere with a weird conical section missing (for lack of a better analogy, a cross-section or 2d equivalent of this shape would look like pac-man). Aside from like maybe a few melee AoEs though, this condition almost never occurs.The implementation has some pretty nasty implications because:
- Hit detection at the root of that cone can get really messy, there's a lot of corner-space that the cone can still technically cover really close to the origin. Things become a bit more distinct once the target being hit is further from that origin.
- Most cone hit tracers in CO display a cone with a flat end (i.e. an actual cone). What this would produce is a cone with a rounded bottom, meaning it doesn't quite reach as far at the cone's outer edges.
Probably still doesn't fully explain what's happening here, as there's still discrepancy about where exactly the cone of the MegaD is coming from (big targets usually originate stuff from their foot area), where it's being aimed since it doesn't display a tracer (also big because while its animation shows horizontal rotation, it does not show vertical rotation at all) And frankly there's way too many unknowns about the exact degreeage of the cone it's firing out or if the model I'm hypothesizing is even close to accurate.Alternatively from my model (and possibly it might be closer to the truth) the hit area might just be a 2D circle that's cast along the Y axis with only points within that specific angle counting as possible to hit. Then, if something technically within that area is also within the main range of the attack, it will count as a full hit. The hit volume that produces would look like a slice of orange.
Frankly that would explain a lot more about the behavior that I've seen, including situations where I've been hit by the FOOM while hovering almost directly above the MegaD: certainly a lot more than the sphere-subtraction model I was postulating about.
In short: cones are dumb, hitboxes are too big.
Epic Stronghold
Block timing explained
Most player cones have an initial radius of 0, but NPC powers don't always do that.
Epic Stronghold
Block timing explained
My super cool CC build and how to use it.
Epic Stronghold
Block timing explained
That'd cleanly explain how and why 'cones' nearby the origin target can still hit, especially on large stuff. Doesn't explain what kind of shape a '200 degree cone' would be though.
not only as a quality of life and an actual warning, but to help newbies from STOP STANDING ON THE TAIL WHIP RANGE
Or people could just start blocking it o3o
My super cool CC build and how to use it.
A 200 degree cone is taking a 180 degree cone and adding 10 degrees on each side. Just take half of the pie and add a little more on each side.
As for what a 200 degree cone attack looks like, my best guess is
The red circle is melee range. The cone basically has to start behind the player and starts out wider than it ends. I'm not sure this is right though because then technically it would hit targets behind the player, like Cleave does. So I dunno... maybe they have to use 2 collision volumes for this.
My super cool CC build and how to use it.
Right, which would map up to this model roughly (excuse crappy art):
More clearly, here's what this looks like if viewing it from top-down:
It's treating the attack as if it were a "cone" as viewed from above, but the real term for that wouldn't be 'cone', that's an 'arc'. That's not even me just being pedantic either, because a cone's a lot simpler to calculate what area it'd cover based on, again, the length of that cone (range), and what radius that cone has at the end of that length ("angle" or coverage). There also straight-up just isn't an angle on a cone that can ever become that wide without the cone's shape imploding in on itself.
In the case of large stuff, then ok yeah there'd also be the radius at its starting point. Maybe that's a fixed size based on how big the thing using the power is. That wouldn't surprise me, as there has to be some kind of logic that helps handle exactly how range of stuff like melee attacks is calculated on giant monsters. If we were to just measure from the center of a giant monster to the center of a player - well, most targets that size have a hit volume that vastly expands beyond the 10 feet of a melee attack.
Also the arc still doesn't account for exactly how this thing operates in 3D space, like how far up or down it reaches, or how that hit area is shaped. The best I can figure if this is actually what happening with a 'cone' is that the volume looks like a slice of orange. Alternatives to that could be that it looks like a slice of cake. Or a cake with a slice missing if the angle is over 180 deg. Maybe that cylinder shape extends up and down the range of the attack, or maybe it extends endlessly vertically, or it angles based on where the cone's being aimed, but a lot of that would be way more complicated than necessary... Of course, this is cryptic math we're dealing with here so
While we're at it, the game decides whether or not you can use a cylinder attack based on the distance to the edge of the target, but determines hitting based on the center, so if you use a cylinder attack at max range on a large creature you fail to hit it.
Epic Stronghold
Block timing explained