Creating Your Actor Engine: Design the Characters for Your Game and Define Their Capabilities - Beginning Java 8 Games Development - page 249

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 ex-
tends 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 chal-
lenge 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 su-
perclass is the List<Image> 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 ad-
vanced 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<Image> in the Actor
superclass, so that fixed sprites have access to different “visual states” just like the mo-