For several weeks, I was having a problem with my camera. It would work perfectly on my test level but would behave differently when I bought it into other levels. It wasn’t until I was explaining to a team mate, how the camera was working that I realised that I wasn’t using a base.y variable for the Y axis. I had the .x and .z axis covered, but I had forgotten to do the .y. The camera worked on my level because it was close to the .y equaling 0, but, obviously failed on levels that were built higher that the .y being 0. In hind sight, the cause of this problem was screaming at me from all sides, but I couldn’t see it because I was focused on the end behavior of the camera.
I tend to approach troubleshooting from the view of the end result, and why my objects aren’t behaving like they are supposed to.
I think that I should be looking from the starting point of the problem and look at why they are doing what they are doing. I know this doesn’t sound like much of a shift in thinking patterns, but this subtle shift has resulted in me finding the source of my problems easily and thereby implementing a solution.
For example, a team mate wrote a function to slerp look at an object and I tried to use it in another script that controls the target for the camera to look at when not in free roam mode. I couldn’t get it working for a week. With this new mind set, I could see what was happening. I was transforming the rotation of the entire trigger box that the script was attached to. I saw that the transform that was going into the function wasn’t what was being transformed. It would work if the transform you are rotating is attached the the game object that you are trying to rotate. The weird thing is, I new this code worked in other scripts but still couldn’t work out why it wouldn’t work in this piece of code.
Maybe someone tried to tell me this in previous Trimesters, but it really should be the first point to drive home when writing code.