Player Manager progress report & Frame Rate Locking

Progress has been slow these last 3 weeks, due to work (the start of the academic year is always a strain…). However a few things have happened.

One thing is that we ditched Allegro and switched to SDL, as Allegro was becoming a pain. I wanted a 3D Ball instead of a sprite ball, it just got messy. It turned out that David was pretty familiar with SDL, so he ported the OS X development version of the game to it.

So now there’s a 3D ball. I want to work on the ball physics next, for which I will be using a proper ball simulation with rigid body mechanics to make sure the ball spins and rolls correctly. I am hoping we can make the player sprites and the 3D ball work together; sorting may be an issue, but it’s not that hard to deal with (I had to deal with it in the original games too, it was just a cheesy Y axis position comparison between the player dribbling with the ball and the ball: sorting was not done in other cases: did anyone ever notice?  No.  That’s an example of only doing what you actually need to do.  You don’t always have to solve all the problems to make a game work!).

Aftertouch (the feature of being able to bend the ball by changing the direction of the input controller immediately after the kick) is one of my trademarks (I came up with it for Kick Off 2) so I have to include it in the game.  Of course, the question is the controls.  That is going to be difficult to figure out, we don’t have 8 way joysticks anymore.  But  I have some (top secret) ideas, and figuring out input control systems is a speciality of mine.  After all, I figured out how to squeeze passing, trapping, shooting, heading, scissor kicking, tacking, chipping and bending the ball on an 8 way joystick with 1 button.  It’s got to be possible to figure something out with a multi touch screen.  No, it won’t be the same, but I have faith that I can make it work and be fun.  It’s a non-negotiable constraint🙂.

Now for the programmers out there, frame rate lock down is a common problem, and often I end up needed a cheap and cheerful solution at least temporarily while developing gameplay.  It is very important for my method of game development that the game code runs at a fixed rate, independent of the rendering.  I never try to use frame rate compensation using a delta time as this makes the behavior of the game dependent on frame rate, which is not a good idea for a few reasons (and many are those who learn this the hard way).  An unstable frame rate will make the game impossible to tune, and very unpleasant to work with.

So here is the cheap and cheerful solution.  The idea is that the AI is in an inner loop  which is called after every render.  The rendering is allowed to update as fast as it can.  Using a timer, it is then possible to keep track of how far ahead or behind the AI is, and either skip it if the rendering is going faster, or execute the AI multiple times to catch up if necessary.  However, each AI execution is always with the same fixed time step so the game remains deterministic.
Disclaimer: This code is as it comes. It has not been dressed up or santized and has a bit of code duplication that annoys me.  But I have more important things to worry about so I’m leaving it as it is.

int elapsedTicks=0;
int prevTicks=SDL_GetTicks();
int aiFrames=0;
do {
// input
processEvents();
int ticks=SDL_GetTicks();
elapsedTicks += (ticks - prevTicks);
prevTicks=ticks;
while(aiFrames*20<elapsedTicks) {
// the threading system
proc::Thread::execAll();
aiFrames++;
int ticks=SDL_GetTicks();
elapsedTicks += (ticks - prevTicks);
prevTicks=ticks;
}
graphics->drawAll2D();
graphics->drawAll3D();
graphics->flip();
} while (!pressed);

4 Responses to “Player Manager progress report & Frame Rate Locking”

  1. Daniele Says:

    Now you made me curious about the control system…🙂
    Would love to be able to play as a goalkeeper, maybe swiping to move and using accelerometer to dive?🙂

  2. Quinten Lansu Says:

    Have you read this article?

    http://gafferongames.com/game-physics/fix-your-timestep/

    • Dino Dini Says:

      Thanks for the link. It is a good article, although it does not tell me anything I don’t already know, it covers the subject reasonably well.

      The code I presented is, as I said, a really cheap and cheerful solution, which in the native English means cheap but not necessarily of the highest quality. It suffers from the problem that you will get some slight “jerking” in the animation. (it will not be completely smooth unless the rendering is clamped to the AI rate *and* synced t the screen display rate). However, when you want something quick that helps you get started in developing a game it works well and is implemented quickly.

      I may do an article on this very interesting subject at a future date.

  3. Erhan Says:

    Hi Dino,

    I am a little bit late catching up with you but I am really glad to see this🙂

    cheers,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: