Our multiplayer FPS game has a gas rifle which emits a particle which should damage players.
The issue is that we can’t find a way (in C++) to read/detect collision events from our gas particle and then use them to inflict damage to a player.
We are also using spheres as mesh colliders within our particle. Using “Collision” in our particle system, we are able to get the gas (and spheres) to collide with the meshes in our world, but still can’t use the information properly in order to damage a player and know who the “owner” of the damage is.
One way around this problem is to attach a collision box to the weapon and have it check if the weapon is firing. If so, then check for actor / pawns in the collision space.
That would only allow the weapon to deal the damage and have the particle as an after effect.
*
OR*
when the weapon fires, maybe spawn a collision box/ sphere, and then have it check.
Either way then you can use the weapon to check who is instigating the damage.
You can’t use Particle Collisions to do this since it’s not designed to work that way. The problem isn’t with collisions not working as such, since they work perfectly for their intended use.
In order to do this each individual particle would have to store tonnes of extra data, like it’s owner, instigator, damage etc. More often than not that’d overhead that nobody would ever want, making it pointless, memory consuming and hella-expensive. Additionally, any part of the simulation done on the GPU will not be able to update anything on the CPU. GPU particles are also bound to the GPU only, so they have no way to talk to the collision code running on the CPU.
Particle collisions are also expensive (CPU ones ((which yours are)) especially so), and they will get throttled if framerate drops too low, so it’s not reliable or scale-able either. Easy or not to do so in Unity, that’s a horrendously expensive way to deal damage to something regardless of whether the engine let’s you do it or not.
A better approach would be to create a simple sphere or capsule primitive (or a few if you must), that roughly covers the area of the particle system. Another way would also be to spawn several instanced ‘projectiles’ within that volume that are bound roughly to it’s shape. You’ll have to do some tweaking to get that to feel right, but that’s really the only way to do it.
Thanks for the information. I guess the best way to go about this would be to edit the gas particle to a single “puff” instead of an emitter which continuosly spawns many at once, and then apply a sphere collider to each individually spawned gas particle.
Since each gas particle would grow larger over time as it evaporates, the sphere collider should (if possible) be coded to grow over the particles lifetime.
You should be able to change the size of the sphere as you want, but just be careful using too many spheres since they’ll always be overlapping. Honestly one or two spheres should be enough, and whenever the player is inside that “volume” they’re being damaged by Damage * DeltaSeconds. That way you’ll also prevent the spamming of loads of collision events.
Here’s how the the flamethrower is done in TF2 as a reference.
What’s the estimated lifetime of your clouds? If the player is able to shoot multiple puffs to make a larger persistent cloud, one thing you could do is change the collision spheres on the fly. If there are small puffs that are close enough, their 2 collision spheres can then be combined into 1 bigger one. This can keep changing everytime a player adds a new puff.
Maybe you’re doing it backwards, have the weapon generate the projectile, grow a collision sphere from the projectiles, make sure the projectiles stick around, then generate particles from that. You might be able to generate particles from points on the collision sphere even.
The point I’m trying to make is the particles should conform to the ‘reality’ of the gameplay, not actually drive it, since the system is so opaque for particles.
