[JAVA][Beginning Java 8 Games Development]

Chapter 4 ■ An Introduction to JavaFX 8: Exploring the Capabilities of the Java 8 Multimedia Engine
JavaFX Input Control for Games: Using javafx.event Classes
Because games are interactive by their very nature, let’s take a look at the javafx.event package next; it provides us
with the Event superclass and its ActionEvent subclass, for handling ACTION events, such as UI element use and
animation KeyFrame processing. Because you are going to be using ActionEvent in your JavaFX games (applications),
I am describing its class inheritance hierarchy here, as this will show you the origins of the Event class as well:
Java.lang.Object
> java.util.EventObject
> javafx.event.Event
> javafx.event.ActionEvent
Your InvinciBagel game application is already using this ActionEvent class (object), with the EventHandler
interface and its .handle() method, which you code yourself to tell your application what to do to “handle” the Event
(ActionEvent) once it has occurred (fired). The .handle() method catches this fired event and then processes it,
according to the Java programming logic inside the body of the .handle() method.
A Java interface is a class that furnishes empty methods, which are declared for use but which do not yet
contain any Java programming constructs. The unimplemented methods will, at the time of their use, have to be
implemented by you, the Java programmer. This Java interface defines only the methods to be implemented (in this
case, a method for handling the ActionEvent so that the event gets processed in some fashion). It is important to note
that the Java interface defines the method that needs to be coded but does not write the method code for you, so it is a
road map of what you must do to complete, or interface with, the programming structure that is in place (in this case,
the Java programming structure for handling ActionEvent objects, that is, fired action events.
Now, let’s take a look at multithreading in JavaFX, which is another important concept for advanced games, to
conclude this exploration of everything 2D- and 3D- (game) related in the JavaFX API and package hierarchy.
JavaFX Thread Control for Games: javafx.concurrent Package
Games require background, or asynchronous, processing. This can be done using additional threads besides
the JavaFX application thread, Prism rendering thread, and media playback thread, which are all automatically
created for you, based on which classes (objects) you are using in your scene graph. Your application programming
logic can spawn its own Worker threads for processing so that you do not overload the primary JavaFX application
thread. Let’s take a look at the javafx.concurrent package next, as it provides us with the Service superclass and its
ScheduledService subclass, for creating Worker objects, as well as a Task class, used for one-off task processing.
Because you are going to be using Service and ScheduledService in your JavaFX games (applications), I am
demonstrating the ScheduledService class inheritance hierarchy here, as this will show you the java.lang.Object
origins of the Service classes as well:
Java.lang.Object
> javafx.concurrent.Service
> javafx.concurrent.ScheduledService
Whereas Task (class) objects are used only one time, to accomplish a given task, a service is ongoing, and a
Service object and a ScheduledService (class) object can be reused, that is, they are ready to perform their service
at any time. This is more appropriate for game play processing, as game play continues for long periods of time, and
the assumption here is that the types of game logic processing involved will also need to be calculated as time goes on
during game play, and not just one single time, as with the Task class (object).
The Worker Java construct is actually an interface, and the Task, Service, and ScheduledService classes have
been created for you, based on this Worker interface (which is more than can be said for the EventHandler interface,
which you have to implement yourself!).
www.it-ebooks.info
97