Difference between revisions of "Game Containers"

Latest revision as of 10:25, 9 May 2018

The concept of containers isn't a particularly new one, the container provides environment in which your application (in this case a game) can run. It provides that game with a set of facilities and expects the game to comply to a certain interface. This allows the container (sometimes called the framework) to handle most of the bits of code common between all games for you - leaving you to focus on the important game logic bits and pieces.

Basic Functionality[edit]

In the case of Slick, the container holds a Game - that is the class that is contained must comply to the Game interface. To make things even easier Slick provides a basic abstract implementation of Game which you can simply extend, called BasicGame. When extending BasicGame you'll need to implement 3 methods:

init() - This is called when the game starts and should be used to load resources and initialise the game state.

render() - This method is passed a graphics content which can be used to draw to the screen. All of your game's rendering should take place in this method (or in methods called from this method)

update() - The method is called each game loop to cause your game to update it's logic. So if you have a little guy flying across the screen this is where you should make him move. This is also where you should check input and change the state of the game.

The GameContainer itself provides methods to control the properties of the game rendering and update. For instance, the game container is where you look for controlling what resolution the game runs at and whether it's in fullscreen mode. It's also responsible for maintaining the game timer and loop. There are a couple of implementations of GameContainer currently available (discussed below), however where possible you should rely on the GameContainer interface - apart from of course when constructing your container where you are making an explicit decision about how your game is to be displayed.

While the Slick game container framework is useful it doesn't suit everyone. It is intended that the features of Slick can be used outside of the framework as part of a generic LWJGL game.

Application Game Container[edit]

The application game container is the most used, it's intended to run your game stand alone or as a webstart. It uses a simple window to display the game and allows you to configure the display mode directly. It's generally constructed in main and started with the following lines:

try { 
    AppGameContainer container = new AppGameContainer(new MyGame()); 
    container.setDisplayMode(800,600,false); 
    container.start(); 
} catch (SlickException e) { 
    e.printStackTrace(); 
}

Where the 800 and 600 specify the window resolution and the false (or true) specify whether the game should be run in fullscreen mode. Note how the container is created with an instance of the game implementation. In this way when you change containers the game itself does not need to be changed at all. This makes it very easy to make a demo version of your game available via a webpage while mainitaining the full version as a standalone application.

Applet Game Container[edit]

The applet game container uses the recently added LWJGL Applet support to present the game as a Java Applet embedded into a webpage. This functionality is currently still being tested and developed. It is known to have issues running within Opera and on low end machines. Supporting an OpenGL context within a browser window is proving to be difficult to be make stable in all cases.

However, for most people this is a great option and allows you deploy your game as an applet with the minimal of fuss. The Slick distribution provides the files required for applet distribution in the “applet” directory. To use your game in the applet you need to specify something similar to the following in the applet tag in the HTML:

    <applet code="org.newdawn.slick.AppletGameContainer" archive="slick.jar,testdata.jar,lwjgl_applet.jar,lwjgl.jar,lwjgl_util_applet.jar,natives.jar,jinput.jar" 
            width="640" height="480"> 
        <param name="game" value="org.newdawn.slick.tests.InputTest"> 
    </applet>

Where the game parameters is replaced with the fully qualified name of your Game class and the archive list contains all the jars you require signed with an appropriate certificate. See the webstart tutorial for details on how to produce a certificate and sign the the JARs correctly.

Future Game Containers[edit]

There are currently no other containers in development, although there are plans for a container that uses a AWT Canvas to display the game. This would allow tools developers the ability to embedded the games (and application displays) into other GUIs, much like the Pedigree Particle Editor.

Developing a game container is resonably simple by extending the standard GameContainer class and adding the part specific to the particular rendering context. If something about the game containers provided doesn't fit with the way you usually write games it's often easiest to simply create a new game container that does exactly what you want rather than attempt to fit in with existing implementations.