I’m pretty new to Unity still. Well under a year. But I was working on some code today, trying to troubleshoot some issues with saving and loading (mostly loading, really) from player prefs and before I knew it, I had fixed the bug.
This concerns me, as I don’t know what I did to fix it, precisely.
I had this issue a while back with some wacky collision detection (2D) that appeared to just fix itself. I just booted up my build one evening and everything was working as intended, without me doing anything that I can remember to fix it.
Is this a sign that I’m not taking careful enough track of my progress, or is this a sign that I’m getting better, or that my code is haunted (that would sound awesome on a resume), or?
Is this a common thing in development?
Thanks for your time. I didn’t know where to post this, so I hope it’s in the right forum.
It depnds, I would suggest to still take a look at your code, it may happen that sometime load order broken up so the first time something you referenced would fire too early or too late and the issue may reappear, had some troubles in the past with this problem.
Other times is just I don’t know, random. Just two days ago I was trying to clamp a float on two negatives values dor a camera movement, it started to gltich out all over the place. I ragequitted unity for 10 mins went back to it and was fixed somewhow. I call them mistery bugs.
Bugs that “fix themselves” are typically artifacts of not understanding something about the code or the systems you’re working with. Something changed to either break it or fix it, and if it “fixed itself” that tells me that you don’t know what the change was. That’s a bad thing because it means you don’t understand how it can be controlled to make sure it doesn’t happen again. So even if it appears to be “fixed”, it’s a good idea to try to reproduce it so that you can investigate it and find ways to reliably prevent it.
Depending on what the bug is I’d look for things like race conditions, different inputs/configurations, user interactions, and external factors.
It could mean that you’re not tracking what you’re doing with your code well enough. I find that it’s really important to do things one at a time, and to make sure that each is done reasonably well before moving on. It’s way easier to keep a nice code base if your self-testing is kept to one step at a time. The more you do between tests the harder it is to track down where an issue is arising - is it the code you just wrote, or something that supplies input, or a utility function that it calls, or…? The less new code between tests the more focused your search can be. Also, remember that you need to test not only the thing that you just did, but any functionality related to any code or data you touched while doing it. The more you do at once the harder it is to keep track of which bits you need to test. (Of course it will eventually reach a point where you can’t effectively self-test everything. That’s where a QA team comes in handy. And at any rate, keep in mind that self testing and QA testing are not the same thing!)
Also, one of the huge benefits of version control systems is that as long as you’re in good habits they help you manage this stuff. Each time you finish a task (eg: “implement first-pass jumping for the character”) and successfully self-test it, commit it to your version control with an appropriate description. This gives you a bunch of neat advantages:
You have documentation of when and how you did everything.
A diff tool can easily show you what code you changed in relation to a specific task.
Infinite undo.
Implicit backup! (Especially if you keep your repo online.)
Along with what these guys have said, it could also have been a bug in the editor. I’ve had times when I’ve spent hours trying to fix a bug only to discover after building and running it, that it didn’t happen in the build version.