A JavaFX based Game Authoring System

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 keypressed 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, updateposition 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 keypressed 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.

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): www.mirkosertic.de/games/dukeplatform

The Duke example game can be played here(Only HTML5 Canvas): www.mirkosertic.de/games/dukeplatform_canvas