- Home /
Area of Damage for a Blink of an Eye
The Topic sums it up. I need to create a spell which damages everything inside of a box Trigger Collider.
In theory, the spell instantiates the Trigger, which in one frame (optimally) detects all targets inside of it, deals damage to them and as soon as it finished dealing damage - it destroys itself. (the process has to take as little time as possible).
In practice, the OnTriggerEnter bugs out, because the Trigger is there for a fraction of a second and it barely can catch any movement. Yet, it also can't detect if any targets are already inside of it in the moment of it's spawning.
What am I missing? I searched the internets and all I could find were just splinters of informations, useless in this particular context.
Help...?
Answer by phxvyper · May 11, 2015 at 01:01 AM
I Googled "trigger hitbox unity activates frame after instantiation," and found this as the first result:
Adding a rigidbody to the explosion prefab has fixed the problem.
Apparently without a rigidbody, a trigger can only detect moving objects.
Source: http://answers.unity3d.com/questions/783803/trigger-instantiated-with-objects-already-inside-o.html
I found that earlier too and added the $$anonymous$$inematoc Rigidbodies to the Trigger and a normal rigidbodies to Targets - still it does not work properly.
After more testingit appears that Targets which are "entirely" inside the Trigger are totally missed - the collisions are only registered, when the Target touches the Trigger's boundaries.
Should OnTriggerStay solve the problem, or will it crunch my entire CPU if there are like 50 Targets inside of a trigger? (a swarm of small targets flying around)
Sorry, I was at school.
Heres another technique you could try, without the usage of any hitboxes, in this regard!
In the update function: You can use FindObjectsOfType: http://docs.unity3d.com/ScriptReference/Object.FindObjectsOfType.html to get a list of all of the game objects that are of a specific type (in unity, that means an object that has a certain component script attached).
Search through that list, check to see if your projectile is within a certain distance of one of those players (this is a pseudo-hitbox) then execute whatever code that would normally be executed when that statement is true.
If this technique doesn't fit your requirements, then I'm not sure how to solve your problem.
Hmm, this looks reasonable, but it would always be a sphere (a distance to any target, checked in any direction - pretty much OvercastSphere :) ) while we need a box to be the boundaries of the spell (The visual effect's restrictions).
Oh well, guess I'll look around more. Thanks anyway for deep reasearch! :)
Answer by CaKeMeaT · May 10, 2015 at 11:54 PM
Maybe you should keep your colliders active for more than one frame, like two.. And add the the stuff you hit to a list, after just a few frames you can remove the collided components, and resolve your list so everything that was hit can be handled as a group.
Ha, good point! I'm already using a list for storing my Targets which were already hit, but that does not solve the problem with collisions not detecting TriggerEnter event, described in a comment to phxvyper message. :]
Answer by Eno-Khaon · May 13, 2015 at 02:08 AM
I might be mistaken, but this sounds to me like the scenario where you'd need to be able to read data for nearby applicable targets, which means either having a huge processing overhead (test all targets in the world for range) or having having a larger memory requirement and constant lesser processing requirements (divide your world into regions and keep track of targets in each region).
Dividing up a world can be done in numerous ways, including (but not limited to) Quadtrees (2-D) and Octrees (3-D), where you have an index for your entire world, divide it in half on each axis, index each of those and note their neighboring regions, divide all of those regions in half, index each of those and note their neighboring regions... and so on down to a minimum physical size and maximum data usage you'd want to utilize.
Then, from there, you'll have subsets in sizes relative to your objectives. For instance, you have that spell blast, which you know the radius of, check against the region's (and neighboring regions') targets to see what's in range.
Granted, all of this is intended for larger-scale game environments, but it's still simply one of the ways of keeping track of potential targets when other options are unreliable.