Triggering triggers with a player viewbox


Since the last devlog update, I’ve adopted ootii’s Motion Controller (“MC”) for (and I hate using this word) a “turnkey” solution to what I was after with regard to player movement. One issue I was running into, however, was the lack of trigger calls when the player was approaching, say, a door computer. (Or I guess you could say one problem I wasn’t running into, since it wasn’t colliding! Hahaha I’m so funny)

The MC is designed to add sphere colliders all over your actor’s mesh space to give a more fluid collision presence in your game. Here’s how ootii describes it:

What you don’t see here is the several spheres generated over the actor, which I’ve rendered for you here:

If you’re familiar with Unity, you’ll know that having multiple colliders like this that overlap is a big no-no when it comes to precision collision detection. For example, a problem I was running in to before was OnTriggerEnter and OnTriggerExit firing off over and over again because the trigger volume for my door computer was triggering multiple spheres at the same time. The way I fixed it was to do a few things–which, of course, I’ll describe now.

The first thing I did was create a new game object as a child of my STG_Player prefab (which is the parent player prefab for my game) called PlayerLookAtCollider. This is nothing more than an empty game object with a collider box in front of the player’s face, which will serve as a sort of viewbox that we’ll use to trigger HUD instructions or interactable input readiness that are based on the direction the player is looking. This way, if we are looking at a console on the left, we’ll get HUD instructions for that console, and if we turn to a console on the right, our HUD instructions will switch to that console.

Here’s the LookAt box I made:

After creating this, I wanted to add  a check in my code to ensure that our HUD instructions for the door computer are only triggering if the door computer interact bounding box was colliding with the above player look at viewbox. Simple enough:

Unfortunately, the door computer was no longer triggering! After spending the morning pulling my hair out trying to figure out why, I remembered the old saying “90% of all coding problems are because you forgot something extremely basic” (okay, okay, I just made that up): I forgot to add a Rigid Body to my door computer to allow the collisions to be processed (yes, even the trigger collision checks).

Adding a Rigid Body component and selecting the Is Kinematic flag fixed the problem:

Now the player’s viewbox triggers the HUD instructions exactly the way I want:


P.S. If you wait until the end of the preview video, you’ll see that the camera zooms in for inspecting things. This is my custom ZoomInspect component for the camera, which, in its final version, will use custom shaders on objects to give interactables a little green glow. This is just a little preview of it, and I’m happy to see how it’s evolving. Stay tuned!


Jesse is the Director of Breakfast Food at Space Turkey Games. Homemade biscuits and gravy? You bet!

Leave a Reply

Your email address will not be published. Required fields are marked *