As with any game in production, we at GravTech Games have encountered our share of bugs. Some going from having the wrong value being plugged in all the way to needing to look into the Unreal Engine 4 source code to find the one thing that messes up the code and keeps us from compiling. And like any other game these can take time to fix, it’s unavoidable. However the real topic I want to touch on is the importance of fixing your own bugs and issues before asking for outside help, even if you aren’t the one who made the bug. Doing so can make you into a stronger programmer, less dependent on others, but also (and this part is probably most important) the issue becomes less of a time sink for the team. While this is a good practice in any work environment it is especially important while working on NORA because our team works remotely.
In most normal work environments I could lean over and talk to a fellow teammate about an issue I’m finding with their code and get a more immediate answer to the problem. However, when working with different people all living in different places and even time zones this becomes difficult. Instead of being able to lean over to my teammate I instead have to write a message with the problem in Skype, and then wait for what can be hours and hope I get an answer to the question, which might not even happen. Even worse, this can take up the other person’s time when helping. One person spending 1 hour on a bug is 1 hour of dev time spent. But two people both spending 1 hour on a bug is 2 hours of dev time spent. This slows down the productivity of the team and the turnover rate for getting tasks done. This is where fixing your own issues comes into play; with it our productivity can increase by not wasting time waiting on an answer. With that in mind here is my debugging process for when these situations arise:
Talk it through:
Talk it out with yourself, try to envision the problem, know what’s going on, and then find where it’s messing up. Sometimes just reviewing the code you have written can give you the “Oh that’s what it is, of course” moment and then you move on. When you explain something to someone you go in detail about whatever you’re explaining and sometimes when programming going into every little detail can show you what the issue is.
Knowing how to read code:
 |
| Credit |
This goes beyond being able to read your own code but just to all code in general. Imagine a scenario where you write a function and it works fine for every application you have for it. Now imagine that it’s months later and you’re finding issues with it and you’ve completely forgotten what it is that you did in the function and said “My code is perfect, there’s no need to comment it”. Knowing how to read code comes in here to help even with your own code, because I for one will admit that I have had this happen to me and I was very thankfully I could read the very poorly written code so I could see the issue. This also works well when debugging other people’s code because other people think differently and therefore code differently, so being able to understand what they’re doing is the first step to finding the issue.
Don’t be afraid to learn:
 |
| Credit |
Knowing what the issue is and knowing how to fix it are two different things. And with a new engine like the Unreal Engine 4 there are bound to be issues with implementing your own functionality. Thankfully for us there is a plethora of forums with people attempting similar things to us who have found different solutions. Several months ago we were having an issue with the project only building from Visual Studio on certain machines. The issue being that to build the project the project was looking for a build.bat file in the install folder for the engine and we had it installed in different locations. Since the engine is still moderately new and not many people have worked on big team projects with it while using source control there wasn’t an easy solution to this problem. However after about an hour of searching on the internet for people who had similar problems I finally found one person who said he fixed the issue by using environment variables to store the file path for the install folder. From there I had to learn how to use environment variables in Visual Studio for how we needed it and then the problem was fixed. This would have been very problematic to the team had it remained an issue.
Ask for help:
 |
| Credit |
Yes, I started this as a do it yourself, but some problems you just can’t solve alone. However this should be the second to last thing you do. And if you’ve done your research, you’ve stared at a screen for hours and still nothing then sometimes a fresh pair of eyes is just what you need. You need a different perspective and someone to talk things through with. Even if it takes up their time as well as yours if it’s a problem you can’t fix on your own then it’s a problem you can’t fix on your own and you need help. And if after getting help and you still haven’t made progress on the issue then you might have to go to the last resort, rewriting the code. I had an issue on a past project where the entire collision system was broken and the person who wrote it was no longer on the team. We spent a full day looking at his uncommented and very confusing code and it got us nowhere. We eventually had to rewrite the entire system to fix everything.
In the end problem solving is a time consuming and not-always-fun mini-game we have to play. But if you can learn how to play it correctly then it becomes less of a hassle and it makes you all the stronger for doing it.
No comments:
Post a Comment