代码改变世界

如何调试快节奏的动作游戏

2010-01-30 23:01  宝宝合凤凰  阅读(254)  评论(0编辑  收藏  举报

How to debug fast-paced action games

April 19, 2007 on 3:10 pm | In Actionscript, Games |

During the development of my last game I took a different approach of debugging it which is especially useful for real time games. Because it’s so simple I’m wondering why I haven’t used this method before (perhaps too lazy ? ;-)) Usually you include a bunch of trace statements everywhere or create a logger system which prints out the information you need. But this is useless in games where many simultaneous events occur. Your logger will be flooded with messages so it’s hard to keep track of everything.

The idea is to include a simple playback control by using keys or invoking a custom breakpoint() method, so you can stop and resume the game at any time and trace out additional information with it. Here is how it’s done (again, basic stuff here):

var updateGame:Boolean = true;
var useBreakpoints:Boolean = false;

//main loop: update game logic, render scene..
function tick():Void
{
       
if (!updateGame) return;

        update
();
        render
();
}

function update():Void
{
       
//...
       
if (player.collides(wall)) breakpoint("player-wall collision");
       
//...
}

So whenever the player collides with the wall, the game stops and prints out the passed string. The breakpoint function itself can look like this:

function breakpoint(message:String, forced:Boolean):Void
{
   
//just quit if breakpoints are disabled
   
//this can be overridden by setting forced=true
   
if (!useBreakpoints && !forced) return;

   
//print out message and stop game
    trace
("breakpoint:" + message);
    updateGame
= false;
}

Obviously, when breakpoint() is called, ‘updateGame’ is set to false so the main loop stops doing anything. The function also checks if breakpoints are enabled so you can globally turn them on or off. Furthermore, you have the option to call breakpoint() with a forced flag, so even if breakpoints are entirely disabled, your game will stop at that point. This is useful to keep some breakpoints active for very rare events or stuff you aren’t sure is working at all and at the same time you can test the game without being constantly bothered by existing regular breakpoints. I have also defined some keys:

function onKeyDown()
{
   
switch (String.fromCharCode(Key.getAscii()))
   
{
       
//stop/resume game
       
case "u":

            updateGame
= !updateGame;
           
break;

       
//toggle breakpoints
       
case "b":

            useBreakpoints
= !useBreakPoints;
            trace
("breakpoints " + (useBreakpoints ? "on" : "off"));
           
break;

       
//step through game
       
case "s":

           
if (!updateGame)
           
{
                update
();
                render
();
           
}
           
break;
   
}
}

Game playback is toggled with ‘u’, and when the game is frozen by a breakpoint call, you can advance frame-by-frame by pressing the ’s’ key or resume playing by pressing ‘u’. This makes debugging much easier because you actually now have the time to think about what’s going on when something goes wrong ;-).