The latest issue of Making Games features an article I wrote about the challenges of adventure game development. It summarizes the lessons learned by Daedalic Entertainment who have been working with the Visionaire Adventure Game Engine for many years now – just check it out!
“As important as debugging is, especially in game development, techniques in debugging are rarely taught.” – Mike McShaffry
Luckily, Norman Matloff wrote a nice article about how to properly debug software and find even the nastiest bugs using the gdb. The introduction of the text applies to all programming environments and might be helpful for everyone, so here’s a short summary.
Matloff understands the process of hunting a bug as follows:
“Finding your bug is a process of confirming the many things you believe are true, until you find one which is not true.”
An example might be that you assume a certain variable value at some point of execution. Then, the task of finding the bug boils down to the verification of this variable value. Matloff proposes some kind of binary search strategy: For the sake of simplicity, we assume our program is composed of 100 lines of code without any jumps or function calls. Then, check the value of the variable at line 50 – if it isn’t correct, you just narrowed down your search space to lines 1-49. Next, check the value at line 25, and so on.
This easily extends to most programs which contain jumps and function calls, of course. In the case of a game, you just need to fully understand the nature of your game loop, that is, the order of update and draw calls and the order your game components are ticked.
Things get a little hairy for distributed or multi-threaded applications… If you don’t have a proper debugger at hand, you’ll have to use log output in order to ensure that all variable values are properly sent and received between machines and/or threads, and that all function calls are properly passed along with their parameter values.
Take a look at the original article and let me close with a quote by one of my supervisors at Kiel University that’s been on my mind for years now: “If the bug can’t be found where you expect it to be, you’d better start looking where you don’t.”
Every programmer knows these moments. You come across those few lines of code that make you think: “Whoops…”. Or better: “Wat.” Most often this code is the result of crazy deadlines or massive refactoring of other parts of the application – or just simple stupidity.
Sometimes this code is your own.
In order to share these great moments with you, I decided to start a series I’d like to call Crappy Code. Should you ever run into any code that you think could fit this category, feel free to send me a mail to crappycode(at)npruehs(dot)de.
Let’s start right away with this little jewel: The first part of this series is about a piece of Python code that is ought to adapt the size of some buttons to the current display resolution.
if Globals.CurrentImageResolutionWidth == 1024:
g_game_button_frameScale = ( 0.352, 1, 0.429 * float(Globals.CurrentImageResolutionHeight) / float(Globals.CurrentImageResolutionWidth) )
g_game_button_scale = ( 0.1683, 1, 0.1705 * float(Globals.CurrentImageResolutionHeight) / float(Globals.CurrentImageResolutionWidth) )
g_game_button_frameScale = ( 0.352 * 0.95, 1, 0.429 * float(Globals.DefaultImageResolutionHeight) / float(Globals.DefaultImageResolutionWidth) )
g_game_button_scale = ( 0.1683, 1, 0.1705 * float(Globals.DefaultImageResolutionHeight) / float(Globals.DefaultImageResolutionWidth) )
This is the pure opposite of a resolution-independent UI. In fact this code has been taken from a game that was originally designed to be played with two resolutions, only: 1024×768 and 1280×800. Unfortunately, I got honored by the task to make the game look somehow good on laptops now, which – who’d have thought – includes other resolutions as well.
Second point: Where do all these strange numbers come from? What the frack is 0.352 * 0.95?
Ah. Yes. It’s 0.3344. I see 😉