Game logic update loop uncoupled from the frame rate?

Hello everyone!

First I’m going to say sorry in advance for commencing a topic that supposedly has been already discussed many times. I searched some time with the keywords I associate with the challenge I want to solve, but could not find anything appropriate in these and other forums, as well as on other tutorial websites. So in case my concern already has an (optimal) solution, I would be very greatful for just some links to tutorials, examples or similar material.

So here goes my conceived concept: I need a program structure that has a fixed game logic update loop that absolutely does not depend on any graphics. The game logic loop calculates objects with coordinates, velocities, collisions, physics, et cetera, but does not do anything graphics related. Another update loop, the graphics (and possibly sounds) update loop, should be called completely independent from the game logic loop. The graphics update loop only reads the game status and displays the world objects respectively without altering them.

It is as well desired (but not required) that the graphics update loop, in case it is invoked more often than the game logic loop (which would supposedly be almost always), renders fictional game states in between the logical game states which are simulated by the game logic loop tself. I read somewhere, that some update methods may have the automatic functionality to interpolate coordinates between two logical states to make some fast movement look smoother.

The main reason for this is that I want the game to be playable without any speed variation. As I plan to run a dedicated server without rendering graphics but certainly calculating game logic such as physics simulation, I don’t want the server to be overloaded with unnecessary computations. To reduce redundant network communication and therefore to reduce network flow (that is, to maximize the connection stability to ensure natural felt action) I plan to run seperate game logic instances both on the server and on all connected clients at once. As I understand, to prevent desynchonization, a consistent, fixed game logic loop frequency is required. I also understand that no deterministic configuration can guarantee 100% consitency when several separate instances of one complex structure exist, with every instance can be affected by any member at any time due to different computing powers, network flows, potential errors et cetera - for that there are concepts for checking for desyncs and restoring synchronization.

Maybe that is too much information from me for one particular question, but I believe that some of the experienced users here may think of a more suitable solution with knowing more precisely about my concept, or may even point out some bad ideas of mine before I start to put some serious afford into their implementation.

Tanks in advance!

No, you don’t need any update loop to be fixed or synced. To do what you want to do just have the normal jME update loop as your “graphics loop” and in your logic update loop, enqueue the changes to the visuals to the jME update loop using app.enqueue. Pretty common and also pretty simple if you already have your game logic detached from the visuals.

Thanks a lot for the fast response!

There are still some unclear points:

  • How and where do I implement my game logics loop?
  • How do I define its frequency? (Based on milliseconds, or updates per second)
  • How and where do I use enqueue()? (To be honest, I don’t really get what exactly enqueue does…)
  • And another important point that I did not mention before is: how do I simulate physics without using any visuals?

Some links to tutorials/examples or a few lines of simple sample code would be great!

  1. In code… I don’t know exactly what your question is here, you would just have a thread repeatedly call your update method if that helps…
  2. You define the frequency by what you do each update call and you could wait the rest of the time if e.g. you only want to update the logic every x milliseconds
  3. Read the javadoc of Application.enqueue() and the multithreading docs (see sidebar)
  4. You use the base physics objects (PhysicsRigidBody etc.) and transfer the location/rotation yourself