Implementing a bubble shield

Everything I can find on the web is about drawing pretty bubbles shields, but not how to implement them! What seemed easy for a prototype is throwing up some tough challenges.

How would one go about creating a two-way shield that stops projectiles coming in but allows characters to pass and allows projectiles to pass out? It effectively needs a 'hollow' collider which doesn't seem to be possible. I've tried a mesh collider and when activated it pushes characters out of the bubble. It also counts as a hit when projectiles are spawned inside the bubble so they get cancelled out.

Using a trigger allows it to move over people and stop trigger-based projectiles, but that also stops them when they are spawned inside the trigger. Only thing I can think of at the moment is recording on a projectile where it was launched from and OnTriggerEnter() testing if this is inside the radius of the bubble sphere as to whether to record an impact or not. That or make the bubble quite complex in its evaluations.

To date I've only used 2D physics. Is there something more useful in 3D physics that'd help? Or an all-round more elegant solution?

 

You can either use Physics2D.IgnoreCollision between the bubble shield and projectiles when they spawn, or have a variable in the projectile and bubble shield components to track which team/player has spawned them.

Inside the OnTriggerEnter() of the bubble shield get the projectile component from the collider, then get the team/player variable. If it's the same as the team/player of the bubble shield, do nothing. If it's different you can bounce the projectile, destroy it, lower the shield hitpoints, etc.

 

Yeah, looks like manual tests are the only option. I've elected for a Physics.SphereCast every update and for each time inside the sphere, determine it's originator distance. If the originator is standing outside the sphere, terminate the projectile.

Despite the tags and layers, it seems the only way to really manage any even mildly complex interactions is to get plenty of detail and do manual filtering and responses. In my last game i ended up with reams of layers and tags representing different types of components and I think it just gets unwieldy.