The BasicGame class can get you a long way with simple game development. However, when games become more complicated it's often useful to separate out the different parts into separate classes with logic and rendering. These different parts are referred to states, as in the state a game is in.

In Slick this concept is supported via the Game implementation StateBasedGame . This game implementation proxies the render and logic methods to the “current” state. The states available and current are set externally by supplying implementations of the GameState interface. However, a convenience implementation of State is supplied, analogous to BasicGame, named BaseGameState.

The GameState is similar to the game interface, in that it has an init, render and update methods. However, the state based game can hold multiple of these state implementation which it can then switch between. In this way the render and logic associated with each facet of the game can be separated into different classes.

As an added bonus, when swapping between these game states a visual effect can be applied to make the swap seem more fluent. These visual effects are referred to and implemented as Transitions.

An example of how to use states and states based games can be found in the StateBasedTest

Every game as a logic flow between several parts. Everyone who played a game knows that after the splash screens dissipate, the game intro or the game menu will appear, also after the player clicks on the “Start Game” option of the Main Menu, he knows that he will be transported to the actual game.

This is why using GameStates is a must when games get complicated, lets say a game has a splash screen, a main menu, an options menu, the intro, the gameplay part a game over screen, a high-score screen and finally the game completed movie/splashscreen. It may seem a lot but is fairly standard even in a small game.

If one would create every one of these “states” inside Basic game the update and render methods would be enormous just to hold all the code for every “state”, besides resources loading could be a problem. Gamestates solve this kind of problem by separating different parts of the game, a MainMenuState can be created that only loads, updates and renders anything that is specific to the menu, all the menu logic is encapsulated inside this State, after that a GamePlayState can support all the logic behind the actual game, rendering only the game part.

For example, a game needs a in-game menu for changing game options, the action must stop and the player must be transported to the options menu. Without gamestates the basicgame would have to accommodate this code and stop the gameplay, render the menu, update the menu logic, etc. With gamestates the control of the game can be passed to a new state (call it OptionsMenuState) that has everything related to the menu, besides the “Options” in the main menu may call the same gamestate.

Another example is a game with two distinct types of gameplay (like the platform levels in sonic and the strange bonus levels), with only a basicGame this type of changes in gameplay may be very hard to manage, as with gamestates is very easy to implement a gameplay type inside a GameState class (platformGameplayState) and the bonus level inside another gameState class (BonusLevelGamePlayState).