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

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

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

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 */

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?