[JAVA][Beginning Java 8 Games Development]

Chapter 8 ■ Creating Your Actor Engine: Design the Characters for Your Game and Define Their Capabilities
Game Actor Design: Defining the Attributes Up Front
The foundation of any popular game is the characters – the Hero and his Arch Enemies – as well as the game’s
obstacles, armory (projectiles), and treasures. Each of these “actors” need to have attributes, defined using variables in
Java, that keep track of what is going on with each of these actors during game play in real time, using areas of system
memory. I am going to try to do this right the first time, in the same sense that you want to define a database record
structure to hold the data you will need out into the future correctly the first time that you define your database.
This can be a challenging stage of your game development, as you need to look out into the future and ascertain what
features you want your game and its actors to have, and then put those into your actor’s capabilities (variables and
methods) up front. Figure 8-1 gives you an idea of some of the two dozen attributes that we will be installing for the
game actors over the course of the chapter as we create over a hundred lines of code to implement our actor engine
for the game.
Figure 8-1. Design a public abstract Actor superclass and a public abstract Hero subclass to use to create sprite classes
As you can see, I’m trying to get a balanced number of variables; in this case it’s about a dozen each, between the
fixed sprite Actor class and the motion sprite Hero class. As you know from Chapter 3, because the Hero subclass we’ll
be creating extends the Actor superclass, it actually has two dozen attributes or characteristics, as it assumes all of the
superclass variables, in addition to having its own. A design challenge will be to put as many of these attributes in the
Actor superclass as possible, so that fixed sprites have as much flexibility as possible. A good example of this is that in
the first rounds of design I had the pivot point (pX and pY variables) in the Hero class, but then I thought about it and
thought “what if I want to rotate fixed sprites (obstacles and treasure) later on for more level design efficiency” so I
placed these variables in the Actor superclass, giving this pivot (rotate) capability to both fixed and motion sprites.
Another variable that I had in the Hero class that I moved “up” into the Actor superclass is the List
property. I thought to myself during this design process, “What if for some reason I want my fixed sprites to have
more than one image state?” I also upgraded the Actor class from using a simple Rectangle Shape object to using a
SVGPath Shape subclass, so that I can define collision geometry (which is what a spriteBounds variable is) using
more complex shapes than a Rectangle to support advanced obstacle constructs in later levels of the game that are
more complex.
Also note that I have the spriteFrame ImageView, which holds the sprite image assets, in the Actor class, as
both fixed and motion sprites use images, so I can put the ImageView into the Actor superclass. I use the imageStates
List in the Actor superclass, so that fixed sprites have access to different “visual states” just like the motion
sprites do. As you may have guessed, List is a Java List object filled with JavaFX Image objects. The iX and iY
variables in the Actor class are image (or initial) placement X and Y locations, which place a fixed sprite on your game
level layout, but will also hold current sprite position for motion sprites, when assumed by the Hero subclass. Other
variables hold Boolean states (alive/dead, etc.) and lifespan, damage, offset, collision, or physics data we’ll need later.
166
www.it-ebooks.info