MotoGP: run slow, step, step, stop!

One use of tweakables in MotoGP was to alter the flow of time. We had the following controls:

  • run/go - if false, skip all calls to Update (but keep on calling Draw)

  • run/speed - changes the rate at which Update is called, to speed up or slow down the simulation

  • run/step - if greater than zero, temporarily overrides go being set to false, but this setting is decremented each time Update is called. If you set it to 1, you get a single Update. If you set it to 10, the game runs for exactly 10 frames, then stops.

These controls we useful for many things. To see exactly what is going on during a complex transition effect:

    speed = 0.01

When optimizing rendering code, I would set the game to start in demo mode (where AI bikes race against each other) with these tweaks:

    go = false
    step = 240

This would run for four seconds, then stop in the exact same place every time, so I could be sure my blu-tack measurements were validly comparing apples to apples.

To debug a rendering problem that only occurs when a bike is pulling a wheelie:

    // drive fast, get that wheel up in the air, then:
    go = false
    // argh, that's not quite the frame I was looking for
    step = 1
    // still not quite right
    step = 1
    // got it! now we fire up PIX to debug the problem...

When working on AI code:

    speed = 6
    num_bikes = 1
    show_racing_line = true
    track/draw = false
    sky/draw = false
    riders/draw = false
    shadows/draw = false

This made the game run 6x faster than normal, so a full lap would take just 15 seconds rather than the usual minute and a half, which saved a lot of time when testing AI changes. Speeding up the clock obviously requires more processing power for the extra Update calls, so we had to remove the other bikes and turn off most of the rendering to make this possible. It looked a lot like Tron: a single bike racing at crazy speeds with only some debug text and the wireframe racing line visible on an otherwise black screen.

Comments (2)

  1. says:

    Hi Shawn!

    run/grab was my favourite while working on the animation.  Turn on the debugging displays, type "run/go=false" into telnet and press enter as soon as something interesting is about to happen.

    Then "run/grab=60" behaves like run/step except that it takes a screenshot after each frame.  It was great for finding what was going on during the one frame where the animation blending messed up.

    – Damyan.

  2. blog_derekh says:

    I love these tip posts of yours. Just implemented the above with some preprocessor code. I think I’ll eventually have to make a template project with this kind of stuff set up from the very start for any new project I create. Sicne I’m on a debug kick for the moment, I’ll look into implementing that Kensei debug console thing up on the Pandemonium blog.

Skip to main content