[JAVA][Beginning Java 8 Games Development]

Chapter 8 ■ Creating Your Actor Engine: Design the Characters for Your Game and Define Their Capabilities
It’s important to note that since we’re setting this up in this way that the Hero class has access to everything
that the Actor class has (thirteen powerful attributes). Actually, it may be more “salient” to look at this the other
way around, that the Actor (fixed sprites) class has every capability that the Hero (motion sprites) class. This
power should be leveraged for level design wow factor, including multi-image states (List Array), custom
SVGPath collision shape capability, custom pivot point placements, and the ability to flip (mirror) sprite imagery
around either the X axis (FlipV = true) or the Y axis (FlipH = true) or both axes (FlipH = FlipV = true). Putting these
capabilities into place in your Actor Engine (Actor and Hero abstract superclasses) is only the first step; using them
brilliantly for your game’s design and programming, as time goes on and you continue to build and refine the game,
is the ultimate goal for putting this foundation into place during this chapter. As you can see in Figure 8-10 our basic
(core) constructor code is error free.
Figure 8-10. Create a public abstract class Hero extends Actor and add a constructor method and a super() constructor
Adding Update and Collision Methods: .update() and .collide()
Now that we have a basic constructor method, which we’ll be adding to a bit later, let’s add the required abstract
.update() method, as well as a .collide() method, as motion sprites are moving, and therefore can collide with things!
First let’s add in the public abstract void .update(); method, as it is required by our Actor superclass. Doing this
essentially passes down (or up, if you prefer) the implementation requirement for this .update() method, from Actor
superclass to Hero subclass, and on to any future subclasses of Hero (which will make Hero into a superclass, and
more reflective of its name). Future non-abstract (functioning) classes will implement this .update() method, which
will be utilized to do all the heavy lifting for the game programming logic. As you can see in Figure 8-11, motion sprites
(Hero subclasses) will also need to have a collision detection method, which I will call .collide(), as that is a shorter
name, and that, at least for now, will remain unimplemented except for returning a boolean false (no collision here,
Boss!) boolean data value. Your Java code for the .collide() method structure will take an Actor object as its parameter,
since that is what your Hero object will be colliding with, and should look like the following:
public boolean collide(Actor object) {
return false;
}
178