The Bug Collection: the look_at bug

Hinzugefügt: 2026-05-07

[00:00:00]Welcome to the bug collection, a video series where I tell you about bugs I'm encountering while developing my game.

[00:00:06]I'll describe what I was trying to accomplish, what is the bug that got in the way, and how I went about identifying and solving it. I'll finish with a few lessons I learned in the process. So, let's look at today's bug.

[00:00:29]Let me start by offering a very important bit of context. The game I'm working on is 2.5D, by which I mean that the gameplay is restricted to a single vertical plane, but the assets and the environment are fully 3D. So, what I'm currently working on is a new enemy type called the scout. The scout is meant to be cannon fod. You face relatively large numbers of them. They're easy to defeat, but they can still be overpowering in large numbers. More importantly though is that their behavior is simple and predictable. The scout should go to the player the minute it spawns and it can spawn from anywhere in 3D space. When it gets within a small distance from the player, it stops, assumes an aggressive posture, and starts orbiting the player still in 3D space. Eventually, it enters the gameplay plane and attacks the player. So, I have two behaviors I'm currently working on. go to player and orbit the player. In the code, I make use of the look at function to make the scout face the player and its motion is derived from the resulting orientation.

[00:01:36]When it goes to the player, it moves in the same direction it faces. And when it orbits the player, it moves in a perpendicular direction to where it's facing.

[00:01:49]When the scout begins to orbit the player, it suddenly starts reversing direction whenever it passes directly in front of the player or directly behind the player. Basically, this happens every time it crosses the player's position on the X-axis. If the player stops moving, the scout gets stuck at that position, constantly alternating its movement direction. You can also see its orientation flicker, like it's rotating 180° every time it passes the player's position.

[00:02:21]In the orbiting motion of the scout, I use its basis vectors to determine its motion. Since the scout's facing direction is minus Z, I can use basis X or basis Y to pick a perpendicular direction. I tried both and basis X gave me a polar orbit, meaning going over the head of the player and into the ground.

[00:02:42]and basis Y made the drone go around the player in a motion that's parallel to the ground, which is what I wanted. The first thing I did to debug then is to print out the basis vectors. I immediately saw that both basis X and basis Y were flipping. So that's why the motion was also flipping. So when my code was manipulating the scout's rotation, as far as I could tell, the only thing was the lookout function. But why would the look at function rotate a node around the direction it's looking at? It doesn't make sense for it to do that. It doesn't help tracking a target.

[00:03:16]I looked at the look at documentation again, but I didn't see anything obvious. So, I started googling. I searched around good forums, Reddit, YouTube, etc., but I didn't find anything that fit what I was looking for. I even tried Gemini, but it basically parited the same stuff I found searching the web. It showed me some potential problems and their corresponding solutions, none of which match what I was seeing, and all of which I had already stumbled upon searching the web. Not finding anything useful, I decided to put on my thinking cap. I first had to make sure that the lookout function was actually the culprit. There could be something else affecting the rotation of the scout.

[00:03:56]First, I had to make the rotation of the scout easier to see. I slapped together a big axis gizmo made out of primitive shapes. I put it under a scouts character body node so I could more easily see the rotation changing. Next, I simply commented out the lookout calls. And there you have it. Without the lookout calls, the rotation stays unchanged. You should never jump straight to there's a bug in GDAU, but I have to admit at this point I started to think this might be a possibility. So, the next step was going to reproduce the bug in the simplest scene possible to prepare for a potential bug report.

[00:04:31]Before I started doing this, however, I looked at the look at documentation one more time. And let's just say there's a very fine line between an aha moment and feeling incredibly stupid. Turns out I had been reading the documentation wrong the whole time.

[00:04:50]First, let's discuss how the look at function actually works. It has a special role for each of the three local axes of the node you're calling it on.

[00:05:00]There's the forward axis, the up axis, and a third unnamed axis. If you were to use look at on a head, the forward axis would point to what the head is looking at. By default, it's the minus Z direction. The up axis is where the top of the head is pointing if the head is in a neutral position. The up vector defines the first axis look will rotate around to try to point at the target. It will make our head turn left and right.

[00:05:28]By default, it's set to the plus Y direction. The third unnamed axis is the second axis of rotation lookout will use to point to the target. It will make our head look up and down. it will by default be the plus x direction. There's an existing terminology for how these axes are used. The forward axis is the roll, the upaxis is the yaw, and the unnamed third axis is the pitch. But roll shouldn't be allowed with look at.

[00:05:58]So how come I'm getting a rolling behavior?

[00:06:01]Well, I had misinterpreted what the second parameter of the look at function was. I thought it was the definition of the forward axis when in fact it is the definition of the upaxis. I hadn't even noticed the name of the parameter and I had only skimmed the text so the true meaning didn't sink in. So I was putting in what I thought should be the forward axis in the up parameter which I didn't even need to do because I had already oriented the scout to adhere to the default convention minus Z being forward and plus Y being up. Essentially, I was causing a gimbal lock by forcing the roll axis to be the same as the yaw axis. So, how did I fix this? I simply had to leave the up parameter alone, allowing it to be its default value. I also had to change the basis vector I was using for the orbiting motion using basis X instead of basis Y. That's it.

[00:06:55]Now I get the orbiting behavior I was expecting.

[00:07:03]Number one, reading documentation without intent and focus can be harmful.

[00:07:08]I like to think of myself as a thoughtful, focused person, but obviously I'm not consistently like that. I fell in the trap of thinking I had already read the documentation while in fact I had only skimmed it. So thinking I had already checked that box, I fell down a Googling rabbit hole that led me nowhere. The fact that the web search wasn't turning up anything should have been a dead giveaway that I was missing something obvious. Slowing down and taking the time to read even just the names of the lookout function parameters would have caught the bug right away. Number two, AI regurgitates the web or interpolates badly. I have a background in machine learning and I even got my first job in the tech industry on the back of a deep learning project that I did in 2016. So, I understand how LLMs work better than the average Joe. And AI only has any hope of being accurate if the answer to your question already exists. If your question doesn't have an existing answer, an LLM's only recourse is to start from existing questions and interpolate between them. But interpolation is not reasoning, and it can only arrive at an accurate answer by chance.

[00:08:26]So this is how we get hallucinations. By the way, for me, being sent down an elucinated goose chase is a very frustrating experience. So I tend to steer clear from AI in general. In the case of this bug, the answer to the question I had didn't exist, possibly because others who fell into the same trap were too embarrassed to admit that they didn't read the docs. I found other instances of people misinterpreting how look at works but what they were trying to achieve was different. So they saw different symptoms and they asked different questions. At the end of the day though Google isn't what it used to be. So finding answers using Gemini or Chad GPT might still work out better for you. I personally prefer using Google alternatives like Kaggi Search or Duck Go. I'd rather gather information straight from the source even if it takes a little bit longer. Lesson number three, working by elimination.

[00:09:23]Debugging is a process of coming up with hypothesis and then ruling out those hypothesis. Don't try to prove them, try to disprove them. For example, in my project, I had this hypothesis that maybe something other than the look at function was affecting the scouts orientation. So instead of trying to prove that by searching my project for other potential causes, I showed that the hypothesis was false by removing the lookout calls. So be on the lookout for this type of inversion of thinking while debugging. Disproving something can be a lot easier than proving it. Number four, visual debugging in goodo is easy.

[00:10:07]It's sometimes much clearer to use visuals for debugging rather than use print statements or even look at values in the debugger. The scout in my game has a lot of symmetry to it, so its orientation isn't exactly obvious. Now, I have this axis gizmo that I can put under any node to visualize its orientation in real time. I'm sure eventually I'll discover more useful visual debugging tools like this one.

[00:10:35]So that's it. Thank you so much for watching. If you enjoy this new kind of video from me, make sure to like and subscribe for more. I'll see you in the next one. Bye.