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.
Primary Goals
Create a simple platform game with the Java Duke
Enhance my knowledge in JavaFX
Have fun doing some cool stuff
Secondary Goals
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
The web renderer is a different beast. The game engine is coded in Java, and there are also some very cool physics engines like JBox2D available which can be embedded as a game system. I really want to avoid Applets or other browser plugins, so do we really need to recode everything in plain JavaScript to make it runnable as a website? Short answer: no. There are different options available. For instance the bck2brwsr(Back to Browser) project, which implements a complete Java Virtual Machine in JavaScript.
Another option is a Java-to-JavaScript compiler. And luckily, there is a very common compiler available, called GWT(Google Web Toolkit). GWT also supports HTML5 features like the Canvas element or even WebGL. For my project, I decided to go the GWT way and code a renderer using the HTML5 canvas technology. The amazing result was that the code of the GWT renderer is almost the same as the JavaFX Canvas renderer! Cool, different framework, almost the same API. Really nice! There is also a WebGL renderer available. It is used if the Browser supports WebGL. Modern Browsers do this for a long time, but Internet Explorer still does not. So the Web Renderer will by default use WebGL and fallback to Canvas if the Browser does not support WebGL. WebGL is based on OpenGL ES, so we can do a lot of cool stuff on the GPU with the programmable shader technology, but for my small game i will just draw some sprites:-)
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.
Update 02/2015 : In the meanwhile there are different Java2JavaScript transpiler frameworks such as Dragome or TeaVM available. You can see a comparison in the context of a this game engine here: GWT vs. TeaVM vs. Dragome.
Conclusion
Cross platform games are doable with JavaFX and Java-to-JavaScript cross compilation using GWT. Domain-driven Design, CDI and domain events greatly fit together with game engine architecture, and compiling Java-to-JavaScript saves a lot of time and enables us to deploy games on different platforms. I really love JavaFX and game coding!
Links:
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: 63a36b0