Two interfaces in Smoothie that are borrowed from Slick are the GameContainer and Game. There are some similarities, but quite some differences. In Smoothie, as in Slick, the GameContainer is an abstract class intended to be extended by windowing-system specific subclasses. It allows creation and management of the display, including changing between fullscreen and windowed mode (for implementations that allow it). It also controls the flow of the game update/render loop and the processing and dispatch of system events. This is handled quite a bit differently in Smoothie. Input events are passed to the GUIManager and if not consumed are then handed off to delegates registered by the game.
Game is also an abstract class. The only base functionality it currently provides is access to the container. It contains two abstract methods that must be implemented by subclasses: update and render. Both of these are called on each iteration through the game loop. The steps to create a new game: implement a subclass of Game; in the main method, create an instance of a GameContainer implementation and pass an instance of your game object to its constructor; call the start method on the GameContainer instance. Game logic is handled in the update method of the Game subclass, and drawing is handled in its render method.
Internally, there are three other classes involved in the core: GUIManager, Canvas and Renderer. When a new GameContainer is created, if no Canvas object has been passed in its constructor it creates a new, default Canvas instance. The Canvas internally maintains a Renderer instance. The default Renderer provides functionality for 2D rendering. It is not intended to hide the graphics API from the user (I have no plans to implement a D3D renderer — this is an OpenGL-only library), but is meant more to ease state management. In the future, I will implement a 3D renderer and a Canvas that supports it.
The GameContainer initializes the GUIManager with the Canvas, which becomes the root GUI object. On each iteration of the game loop, the GameContainer calls update and then render on the GUIManager, which in turn calls the same methods on each active GUI object. GUI components are designed such that their content rendering methods can be replaced with a delegate. The GameContainer does this to its Canvas object — it turns off the background and border rendering of the Canvas and replaces its content renderer with the render method of the Game instance. I haven’t implemented it yet, but the same will happen with the update method.
Tying the rendering and updating of the game object to the GUI system, without actually requiring the Game object to be a subclass of a GUI component, opens the door for some interesting interactions. Also, it should be possible to run multiple game instances in the same application window, using different GUI objects to render them. I haven’t quite worked out the details yet, but most likely it will be done using texture rendering with multiple renderer objects.
I’ve got all of this implemented and working so far, with the exception of the multiple canvases bit. I’ve also whipped up a generic state stack utility that will be useful for, among other things, managing game state transitions. It’s based on the code provided by James Boer in his GPG 5 article.
I had a bit of fun implementing the core GUI functionality (focus, mouse entering/leaving, dragging components, background & border rendering). The little app I created to test it was fun to toy with on the point of being distracting (but only because it was my creation I was testing, I’m sure). I’ve implemented one-off GUIs before, using fixed images to represent components, but never anything more than that. So this was something new and enjoyable. I’m only implementing the generic Component and Canvas classes for milestone 1, but in milestone 2 I will add support for labels, buttons, and some other simple components.
Currently, I’m working on the resource loading system and will describe that later.
Technorati Tags: Devlog, D Programming Language, Smoothie, GUI, game programming, game development
Post a Comment