Sign in to follow this  
lucky6969b

Structuring the game loop

Recommended Posts

There are 2 ways I think of to structure the game loop

The goal of this is to prevent one component, for example, the physics component to overwrite the AI outputs

1) FixedUpdate -> and this means the Physics component will have to be last in the game loop

    and I just add positions and rotations at the end of it, and the result will be aggregated at the renderer

 

2) Updating Velocities of game objects -> From the AI which should dominate the moves of the objects,

    when the AI found the next waypoint, I just calculate the displacement and divide it by its speed

   to get the velocity, and the physics will run freely in its own thread, what it will do is to

   add velocity to the game object and at the renderer, the instantaneous position is calculated by

   dissolving the current position with the instantaneous velocity...

    P(t) = P0 + v(t) * t

Which way is better?

Also, should I consider a multithreaded gameloop to improve frame rate and response times?

Thanks

Jack

Edited by lucky6969b

Share this post


Link to post
Share on other sites

This depends on the kind of game you are doing and the way you are providing the loop. I would recommend a multithreaded behavior when working with heavy loads like a massive AI (in a driving game for example) where for example a card game could run in a single loop.

Is the loop a fixed function call Update, call Render loop then you may need to sort your updates as you need them (for example doing the AI as last step) or do you have a message/event based system so a finished physics (maybe thread) would push an event to inform the AI that know is a great point to make an update

Share this post


Link to post
Share on other sites

Right at this point,

I just update all components in the game objects,

then update the physics (and other shared components last),

after all that done, I aggregate the transform at the renderer,

however, the physics and other shared components do run on their own.

 

I just give a free-run thread of them, and they spin around and sleep for a while

and update all the guys again.

 

The renderer is coupled to the main loop as well for the time being.

I would move them out with command-buffer technique...

But I am working on resolving the problem of components stepping into each other.

 

Thanks

Jack

Share this post


Link to post
Share on other sites

1) FixedUpdate -> and this means the Physics component will have to be last in the game loop

...

Also, should I consider a multithreaded gameloop to improve frame rate and response times?

Not necessarily the last in the game loop. A second can be used for physics. I don't mean spawning a thread every frame, but creating a thread at the beginning of the game and each thread has their own loop. The second thread is the physics, always running in parrallel. That's how I do in my game engine. Also is how Godot does. And Unity.


2) Updating Velocities of game objects -> From the AI which should dominate the moves of the objects,

If they are running in separate threads, changing the body velocity directly from the AI could be buggy, because you could change the velocity exactly when the physics engine was calculating a collision or moving the body. Instead, the AI should give a *hint* that the physics engine should read before all physics calculation. Example, in your AI thread:

/* PSEUDO-CODE */
if (keydown(KEY_LEFT)) {
    self->move_x = move_x - 1;
}
if (keydown(KEY_RIGHT)) {
    self->move_x = move_x + 1;
}

In your physics thread:

/* PSEUDO-CODE */
body.setVelocityX(obj.move_x * SPEED);
body.update() /* Using the hint, we avoided that the velocity was changed during this update */
Edited by felipefsdev

Share this post


Link to post
Share on other sites

How come in the physics component, we don't add velocity, instead we *set* velocity.

Actually when the AI give out a velocity, and physics will just add more forces to the object, should we just add them up together, shouldn't we?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this