Jump to content

View more

Image of the Day

Inventory ! Va falloir trouver une autre couleur pour le cadre D: #AzTroScreenshot #screenshotsaturday https://t.co/PvxhGL7cOH
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Sign up now

How to debug a game more efficiently?

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 kiss_lawrence   Members   


Posted 22 April 2014 - 01:33 AM

Hi everyone,


Currently I'm developing a game with many stages, and I found it's very inconvenient to debug. For example, if I find a bug in the middle stage of the game, then I have to exit game and change codes, and run the game until it's in the right stage. And if that change doesn't work, I have to do that again, which really consumes a lot of time. (I can change to code so that the game can jump into the right stage as soon as the game starts, yet still it costs much work)


So I'm wondering if there's a way to speed up this procedure? Recently, I've heard about scripting languages, and it is said it's possible to change scripts at runtime?? If so, that would save a lot of time. But I'm not sure if my understanding on that is correct, so please offer some introductions(or examples) on that if possible.


More basically, my question is:

Is it possible to use script languages to debug a game more efficiently? If possible, how? If not, are there any other ways?


I would be very grateful if you can offer your ideas and thoughts.


PS:I hope my English is not confusing...since I'm still an English learner.


#2 Ashaman73   Members   


Posted 22 April 2014 - 01:56 AM


So I'm wondering if there's a way to speed up this procedure?

First of all, you should be able to save and load your game at any time, even if it is not part of the game design. This way you can prepare a game situation, save it, and reload it for debugging purpose on demand.


Further on, changing code while continuing the program, often called hot-deployment, depends on the language and tools you use. It is possible to do it with scripting languages more easily, because many scripting languages like lua have the ability to compile a text string at runtime and add it to your running environment (or replace existing functions). But this is only half the truth, because changing the code base will not help you in all cases. Often bugs change the state of the game (corrupting gameplay data). In this case changing the code will not help you.


Here is a quick list of tools/features which helps you, top is most important in my opinion:

1. Debugger !

2. Logfile !

3. Save/Load

4. Ingame console and/or web interface to check the game state and change parameters.

5. Quick start: start the game and load the current game level immetiadly

6. Hotdeployment (be aware of chaninging game state !)



Gnoblins: Website - Facebook - Twitter - Youtube - Steam Greenlit - IndieDB - Gamedev Log

#3 DiegoSLTS   Members   


Posted 22 April 2014 - 06:21 AM

The option of save/load looks like the fastest way to test it, but it depends on what you're trying to fix.


In the company I was working they had a cheat menu that was left out of the build in the final release. You can add cheats for everything you want like skip a level, earn more coins, create some unit, etc.


Anyway, with these methods you have to make sure that the save feature has no issues (it may be complex depending on your game) and that the cheats make valid changes (i.e. if you skip a level where a certain building should be placed, you should place the building while triggering the cheat).

#4 catslap   Members   


Posted 22 April 2014 - 12:11 PM

What language and environment are you using?


Debuggers generally let you change variables that allow for primitive test cases. Writing a debug interface that gives you full control in a swifter way is probably helpful.


It helps to have lots and lots of debug output that is conditionally compiled in, showing you paths through execution, state machine information etc and so on, with freezeframes of important variables, then you can compare these to get insight into the problem. Lots and lots of error and boundary checking in your code generally reduces dev time too. So does good practice coding technique, make your language's inbuilt tools work for you rather than work around them.

#5 Matias Goldberg   Members   


Posted 22 April 2014 - 12:12 PM


From the beginning of designing my game engine, I've decided it would work deterministically. This approach is best if coded like that from start, but could still be possible to implement later in the process:

Being the game deterministic, the engine saves and journals all sources of undeterminism (player keystrokes, random number generator seeds, etc) and saves them to a file. The file is a mere KBs big even after an hour of playing. It's size depends on the amount of undeterminism sources you need to track and the framerate you're running at (i.e. simulating at 60hz needs double the space of a 30hz simulation)


When the game is closed or crashes (I use SEH to catch the crash and save the journal) I can later replay the whole session (I can even fast forward, but how fast I can fast forward depends on how powerful my system is, as it must simulate all frames until the crash without rendering waiting for vsync).


This has proven to be an invaluable tool. I've caught so many crashes in no time (specially those hard-to-reproduce ones), also experimented, and even see through the debugger how a variable's value evolves through every frame.


There are a few caveats:

  1. A few rare bugs may corrupt the journal, but this is extremely obvious and often blatantly obvious.
  2. If the bug is caused by an untracked source of undeterminism (i.e. an uninitialized variable is the most common one), the replay will be different on every run. However you can still use this to try to understand when is the moment that your simulation starts to diverge and nail down the source of undeterminism. You can also start removing stuff until the replay is simple enough.
  3. Sometimes the SEH fails to save the journal, and the replay session is lost.
  4. Changing code to fix one or more bugs may cause your replay session to diverge before the crash, thus it's no longer useful in seeing if the fix actually works.


I can't tell you how to write your journal, as it is specific to each game engine. However, I point you a few starts:


http://gafferongames.com/networking-for-game-programmers/debugging-multiplayer-games/ -> Keeps a journal for debugging networked games, but it's basically the same thing except for single player, and you're not journaling network packets, but rather key strokes.

Edited by Matias Goldberg, 22 April 2014 - 12:13 PM.

#6 frob   Moderators   


Posted 22 April 2014 - 04:39 PM

Some tools allow you to edit the code while it is running.


Visual Studio supports "Edit and Continue", potentially allowing you to modify your code where it is recompiled, patched, and continues running without interference. 


Some tools support similar "hot-patch" or "hot swap" debugging. Eclipse supports it for some languages, Emacs supports it for some languages. JavaScript allows live changes in some browsers. When it is supported, it is just a matter of getting the configurations correct. Some tools and languages will replace a function entirely and make you start it over, others will apply changes mid-function. The details are up to the tools.



It is worth investing the time to get it working if your environment supports it. For a long project it can save thousands of hours of time spent debugging.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff.

#7 3Ddreamer   Members   


Posted 22 April 2014 - 09:23 PM

More modular coding generally makes debugging easier and quicker. "Modules" of code may be permanently or temporarily (for the purpose of development) tied to interfaces which are specifically designed to aid the debugging tool (or tools) by turning sections of coding ON or OFF or SWAP the suspected buggy coding with your revision attempt. While we are on the issue of preventative structure to aid debugging, class files ( or jar ), dlls, a organized bin folder, and other modular forms of coding have some advantages in the debugging.  You should be able to better isolate where the bug might be if your modules of coding are well labeled.  For example, you would expect that a bug in the implementation of a particular entity would not be in seemingly unrelated class files nearby.


There are a few applications available (actually integrated into the source code) which track suspected bugs, but I have never used them. A C# programmer friend of mine loves them. 


Probably you just need to look for a better debugger for the time being.

Edited by 3Ddreamer, 22 April 2014 - 09:27 PM.

Personal life and your private thoughts always effect your career. Research is the intellectual backbone of game development and the first order. Version Control is crucial for full management of applications and software.  The better the workflow pipeline, then the greater the potential output for a quality game.  Completing projects is the last but finest order.


by Clinton, 3Ddreamer

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.