There are seven game types provided by the jME library (as of version 2.0). Each of the types has their own description page, however, a brief overview of the unique characteristics of each is given here. Also, the features and methods provided in AbstractGame will be discussed here since they are common to all game times.

• BaseGame provides a very raw, non-complex game loop an. The loop is a pure high speed loop, each iteration is processing as fast as the CPU/GPU can handle it.

• SimpleGame provides almost all of the functionality needed to get a game running. SimpleGame is designed for quick usage and easy prototyping. It provides basic first-person look and move actions as well as many debug options including things like screenshots, render statistics monitoring, and bounding box drawing. There is an automatically rendered root scene node (rootNode) that all game data can be attached to. Most jME demos use the SimpleGame type.

• StandardGame is intended to be a foundation for production quality game development. It utilizes a GameState tree for scene updates, and provides a rootNode to attach geometry to. The standard game by default has no input handling of any kind. Ultimately, this game type is intended to easily support client/server division, alternative settings system, built-in multithreading (i.e. managed OpenGL thread), a task queue for adding additional work to the OpenGL thread, and shadow support.

• SimpleHeadlessGame is similar to SimpleGame except it is intended for headless renderering applications (useful for embedding in Swing/AWT).

• FixedFramerateGame allows the user to set the maximum framerate of the game. The game loop is guaranteed never to run faster than the limit, but nothing guarantees that it will not run slower. Limiting the framerate of the game is useful for playing nice with the underlying operating system. That is, if the game loop is left unchecked, it tends to use 100% of the CPU cycles. This is fine for fullscreen applications (as it will yield to important processes), but can cause issues with windowed applications.

• FixedLogicrateGame allows the renderer to render as fast as possible but only giving a defined amount of time to the update method. This ensures that the game state will be updated at a specified rate, while the rendering occurs as fast as the computer can handle it. This gives tighter control on how the game state is processed, including such things as AI and physics.

• VariableTimestepGame is very similar to BaseGame. However, instead of just calling the basic update/render methods, they are supplied with the time between frames. This saves the user from having to create and maintain a Timer object.

While each of the different game types have unique characteristics specific to their purpose, AbstractGame provides a set of functionality that is common across all game types. Note, the exact details of when each of the following are executed are dependent on the game type. Refer to the javadoc or the user's guide page describing each game type for more information about what is required for each.

This is the standard place to initialize the display system and other non-game components that must be loaded before starting up the game. Most of the game types handle this for you, and you will not need to override this unless customizing the display system setup.

This is where the game itself is initialized. This should be called after initSystem() completes. This is where you should initialize the opening screen for your game. This should not load a huge amount of geometry and textures or it will calls a large lag in startup time.

Typically called first on each loop through the main loop. The meaning of the float is game type dependent.

Typically called second on each loop through the main loop. The meaning of the float is game type dependent.

Typically called when the game is shutting down. This is where anything that needs to happen before the JVM exits should go.

<PropertiesDialog|User's Guide|BaseGame>