BoxCast, CircleCast, and More Debugging

Extending on previous RayCast2D Article…

Because I will never have done enough of it, today I’d like again to stress the importance of slow, simple, and attentive debugging. Fortunately, I can stress the importance of this by illustrating the use of a few new and useful features.

If you’ve grasped RayCast2D from the referenced article above, you might notice there are some limitations to detecting colliders via casting a single straight line. Eventually you’ll realize there are situations in which it’s more beneficial to detect colliders in an entire area, and not just a line.

Enter ShapeCasting.

Instead of measuring colliders in a straight line, it’s often more useful to measure in an area

ShapeCasting is just like it sounds; instead of a Ray measuring colliders, you can choose from a few useful shapes. The shape will take reference of any Collider that interacts with it. Let’s start with the basics: BoxCast and CircleCast.

Start from the bottom. Unity Manual & Unity/VS Tooltips. The casting of both boxes and circles acts virtually the same. They take an argument for the Origin point, an argument for Size, and then they offer to take arguments to travel in a specified direction for a specified distance. Ignore the latter two for now.

Just like we measured a Ray downward from the Orb in the scene, so will we do with the other shapes. Since we want to measure the space downward from the Orb, we’ll offset our Origin point by a few units. The only other thing we need to decide is the Size. Duration, direction, and angle are set to 0, because I don’t want the Cast to move at all.

Virtually the same code as in RayCasting, extended for Circle/Box Casts

Something important that I didn’t highlight in the last article: RayCasts are invisible. There’s no built in logic to illustrate where you’re RayCasting. You have to visualize this on your own, you have to be careful to make sure your your visualization is an accurate representation of the Cast, and you have to verify that it’s detecting what you want it to. At lines 33–38 in the above script, I’ve declared the variables for Circle & Box Size, and Origin Offset. It’s important to keep these centrally stored, because we’ll reference them again when visualizing our Casts and making sure they work. Whether it’s variables or methods, if you’re repeating the same information, you should store it in once place. It’s less confusing and helps to avoid errors by allowing consistent and central access.

In the last article, I used DrawRay to visualize the length of my RayCast, and DrawLine to verify that proper contact was being made with a Collider. I’ll keep DrawLine, the red line, since it helps to visually confirm to me what it’s detecting. The new visualization methods are Gizmos.DrawWireCube and Gizmos.DrawWireSphere, which need to be called in the OnDrawGizmos method. You can imagine what each of those do. The word Wire indicates that we don’t want a solid shape drawn, we only want the outline there. Notice, whether it’s for our Box or our Circle, we’re passing through to Gizmos the exact same variables with which we implemented the corresponding ShapeCasts.

The red DrawLine only shows when the Collider meets with the ShapeCast. None of this is inherently shown to us; it’s up to us to visualize it accurately for ourselves.

Toggling Gizmos and selecting Player will allow you to see the proper components in Game View, in addition to already seeing them in the smaller Scene View above.

If you aren’t yet convinced of the value of good debugging and visualizing, fear not. I will be sure to shoehorn its importance into many conversations and demonstrations to come.