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.

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 !)

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).

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.

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/game-physics/fix-your-timestep/

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.

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.

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.