At the core of every game is a loop - a portion of code that gets executed continuously throughout the life of the game. The image to the right depicts a very basic game loop that has many of the typical steps involved. The game loop is primarily responsible for making updates to scene data and passing geometry through the render pipeline to be drawn on the screen. It is critical the the game loop be fast, consistent, and continuous. If any part of the main loop executes slowly it can cause significant lag, jumps, or erratic behavior for the player or user.

To get an idea of the importance of an efficient and fast game loop, consider this: a good minimum target frame rate for your game may be 30 frames per second (fps). In order to achieve updates at that speed, a single game loop must run in 33ms or less. That means that you get 33ms to calculate any new states and update ALL of the objects in the game world, attach any new geometry, remove any old geometry, and pass everything to the graphics card for rendering. Further, every game loop must consistently run in less than 33ms. If 1 frame out of 50 takes 500ms to execute do to some process, players will experience disruptive lag that will potentially greatly reduce playability. This can be particularly difficult when a player turns a corner, opens a door, or does some other action that causes a large amount of additional geometry to suddenly be drawn. You should keep speed in mind throughout game development.

The first step performed by a typical game loop is initialization. This is where the basics for your game should be initialized. In very simple games, your initial geometry may be attached at this point. In more advanced games, core classes may be instantiated and additional threads may be spawned to perform loading tasks. At this point, no render pass has been made yet, so performing a lot of initialization can cause significant lag time where your player is looking at a blank screen.

At this step, updates to all the objects in the game world are calculated and performed. Usually, a time step value is passed to all of the update methods indicating how much time has passed since the last update (though this is not always the case). Typical tasks for this step include input handling, camera rotation/translation, updates to moving/rotating objects, attaching of new geometry, detaching no longer needed geometry, and so on.

This step handles the actual rendering of the current scene. In jME, this step is typically as simple as calling Renderer.draw(rootNode), but there is great flexibility afforded the developer due to the modular design of jME. More about this will be said later in the user's guide. Note that updates to geometry that depend on the current camera position (such as CLOD calculations - see AreaClodMesh) may be performed during the draw calls.

Most of the time, after the scene is drawn, the next update game step will be executed. However, if the game is finished (usually due to some input or menu selection) control will pass to the cleanup stage. At this point any open resources can be closed and any important game state data can be saved before the program exits.

There is not a single implementation of a game loop in jME. While jME provides two implementations that will be used most of the time (see SimpleGame and StandardGame), the developer can easily write there own custom game implementation that extends AbstractGame. A more detailed discussion of the specifics of each of the game loops can be found in the Application (AbstractGame and subclasses) section of the user's guide. If you want to write your own custom game loop, you will need to extend AbstractGame or BaseGame.

With the advent of multi-core machines, game loops and game architectures may vary dramatically. The game loop presented here is a single threaded game loop, which means that the initialization, update and render phase of the game occurs in the same thread. Using multiple threads in a game doesn't necessarily imply a multi-threaded game loop. Significant computation such as game AI, physics calculations, loading IO, and networking can be offloaded to other threads without a fully multi-threaded game loop. Further discussion can be found in Chapter 14 - Multiple Threads and in the forums. Also see the discussion about adding additional multi-threading support to jME 3.0.

<Introduction | User's Guide | Application (AbstractGame and subclasses)>