A few weeks ago I decided to enhance my knowledge in game coding, so I bought two very interesting books: “Real-Time Rendering, Third Edition by Thomas Akenine-Möller, Eric Haines and Nety Hoffmann” and “Game Coding Complete, Fourth Edition by Mike McShaffry and David “Rez” Graham”. After some insightful moments, hundreds of pages read and sleepless nights, I wanted to create my own game. So this project was born.
Create a simple platform game with the Java Duke
Enhance my knowledge in JavaFX
Have fun doing some cool stuff
Create a game engine and a user friendly game authoring tool with JavaFX
Make the game engine runnable on more than one device type(Desktop and Web)
Check what would be the best way to create complex UIs with JavaFX
Create a rich domain model for computer games
Apply domain-driven design to game engine architecture
Well, I have to say that I achieved all of these goals. Here is a screenshot of the JavaFX based authoring tool:
And the running game in Firefox deployed as a plain HTML website:
and the game also running in Internet Explorer:
Nice! Of course the game engine has some very cool features, like a flexible rule engine, physics support and sound!
The Game Authoring System
The authoring system is a JavaFX application. I used Java CDI(Context and Dependency Injection) for the UI(yes, CDI can also be used on UI side!). CDI has also a very cool feature, the CDI Events. Using CDI events, complex UI logic can be completely decoupled, and it greatly fits together with the Model-View-Presenter Pattern. Using this style of architecture, it is quite easy to split a complex user interface into separate modules, like the property browser, and project structure view and the game scene preview. When a user selects an object in the project structure, an event is fired using CDI. This event is observed by the property browser, the game scene preview and other components, so they can react by highlighting an object, showing its properties or even updating its game engine state. I really learned to love JavaFX and CDI!
The Core Game Engine
The game engine is the heart of the system. Basically it is structured the following way:
There are different game systems and game views. A game system for instance is the sound system or the physics system. A game view is the presentation of the game state for a user. The game systems and the game views are tied together in the game loop. For every frame rendered, the game loop is executed, every game system gets a chance to do something and finally the presentation is rendered by a game view.
The different game systems are decoupled by an event dispatching system. Every object or game system can create or consume events. So pressing a key by a user creates a key pressed event, which is consumed by the duke object, knowing that it must jump now(This behavior is defined by a rule engine). So another event is created to inform the physics engine that a force must be applied to a given object. Now the physics system is called during the main loop, and it can run the physics simulation for a given amount of time. After that, update position events are fired by the physics game system informing the game domain model to update an object. Now the game view are called to render the game state to a device. All this happens during one step of the main game loop. What I have learned is that computer games are also a great appliance for event driven architecture!
The game engine also defines a set of infrastructure services. These services are implemented by the renderers as described in the following chapters. Basically the core engine defines an abstract sound system API and gives the renderer an interface to the current game state as a kind of camera. The renderer can now implement the sound playing using the device dependent APIs and also use the camera to retrieve visible objects and render them to screen using any kind of graphics API.
The JavaFX Renderer/Game View
The JavaFX renderer is a game view implementation. It renders the current game state with a JavaFX Canvas element. It also couples the main game loop with the JavaFX pulse event. A pulse is throttled at 60 frames per second maximum, and this frequency fits well together with the main game loop. Using the pulse event we can avoid different threads for the game loop and the rendering system, and the maximum of 60 frames per second is more than enough for most games.
The JavaFX Renderer uses plain JaxaFX key events and passes them to the core event dispatching system. It also uses the Java Sound API to play music or other sound effects. The JavaFX renderer is basically used by the game authoring system as a preview for the game. The user interface for the web game view is a little bit more complicated as you will see in the following chapter.
The Web Renderer/Game View
Reacting on user input can be tricky on the web. We can of course use plain old key pressed events and react on them the same way as seen in the JavaFX renderer. This is also implemented this way as GWT code. But what shall we do on touch devices?
Well, we can use APIs like PhoneGap/Apache Cordova to react on touch events, or we can even use the device accelerometer as a kind of user feedback. This is something I will implement in a future version of the renderer. For now, I will just react on plain old key events.
The source code is available for free on GitHub: github.com/mirkosertic/GameComposer
The Duke example game can be played here(WebGL with HTML5 Canvas fallback): http://mirkosertic.github.io/GameComposer/games/gwt/platformer/index.html
The GameComposer project website: mirkosertic.github.io/GameComposer
Git revision: 4b10027