If you’re a human on Planet Earth, there are dozens if not hundreds and thousands of features in Unity and C# that you do not understand.
That includes every professional full-time software developer, every person who’s never even made an attempt at coding, and every person in between. As Jonathan Weinberger has said many times, a good software developer is just good at Googling things. It’s for this reason I want to highlight good practice when learning (or relearning!) any feature in Unity.
There are two invaluable resources to help you understand every small part of any new process in Unity:
- Combined use of Unity Manual & Unity/Visual Studio tooltips
- Debug, Debug, Debug, Debug… you get the point
Today, I wanted to showcase how basic Raycasting can be used to communicate useful information between objects. Well, I needed to learn Raycasting again, and I hadn’t learned it yet in a 2D environment. So I jumped on the Manual, broke it down step by step, made at least a dozen different Debug commands throughout the process, and came out the other end having a demonstration with which I could showcase the basic capabilities of Raycasting. Let’s begin the learning process with Raycasting as an example.
Start with the Unity Manual. It tells you the gist of every method and feature. See if it makes any sense to you, and see if you can copy their script logic and get going some semblance of implementation for your intended feature.
Second, while attempting to bring your own feature to life, reference the Unity Manual with VS+Unity’s amazing tool-tip system. If you truly want to understand it, read everything. Notice Physics2D.Raycast() has 8 different sets of arguments it can take!!
Boiled down simply, RayCasting is an extension of Collision Detection. If you’ve made it even a short way into the 2-D Game Development Course, you’ll have encountered Collision Detection in OnTriggerEnter2D, when the player, enemies, and lasers all need to react a certain way when they hit each other. So I’m casting a Ray in a certain direction, and detecting whether or not it’s hitting any Colliders. We’ll call the logic in Update right now, since we want to know each frame if there’s a new object being detected.
If I hit a Collider, I have a reference to it, and with that I can access all sorts of information. We’re staying basic here and using the first overload of Physics2D.Raycast(), so all we need is the origin position and the direction in which we’re headed. Vector2.down is the direction, but remember, Vector2.down only goes down for 1 unit so I’ve multiplied it by 10 to extend it. Many examples will have you extending the direction by infinity. This is fine.
So I’ve got a working Raycast, right? How do I know? Debugging; look below. In the first method, I have the script visualize the length of the Ray that I’ve cast (green), and therefore what it could possibly detect. In the second, if an object is detected, I have the script visualize a line between the origin position and the target’s position (red). In the third, the script tells me the name of the object I’ve hit; the fourth, the distance between the origin’s collider and the object’s collider.
We use Debug to confirm that every little part of the process is working, and correctly. Debugging is useful for confirming every step of the process, for isolating where your scripts aren’t working as intended, and for simply learning what methods return which results. I spend a lot of time debugging just to learn.
I knew nothing of 2-D Raycasting to start the day. I went slow, implemented the basics, and debugged the entire way. Basic, careful implementation and consistent debugging taught it to me relatively quickly.
Start slow, gain a grasp, and then build upon it. The process of patient debugging and learning is bar-none your most valuable asset as a software developer.