So I am just at the beginning of writing a game in Java and I am writing my game objects. Now I have read here in Evolve Your Hierarchy that you should build your games as compositions and not as a big class hierarchy. As this image from the previous link shows:
However, when actually getting down to the implementation I have one small question about where to apply the interfaces.
Lets say you have a class called Player and the interfaces Moveable and Renderable. Do you implement this using public interface variables:
class Player {
public Moveable moveable;
public Renderable renderable;
}
class GenericMoveable implements Moveable {
// Function implementations
}
class PlayerRenderable implements Renderable {
// Function implementations
}
Or do you try and do this by applying the interfaces directly to the object:
class Player implements Moveable, Renderable {
private GenericMoveable genericMoveable;
// Non-direct Implementation of Moveable
void someMoveFunc(double x, double y) {
genericMoveable.someMoveFunc(x, y);
}
// Direct implementation of Renderable
void someRenderableFunction() {
// Player class specific code
}
}
class GenericMoveable implements Moveable {
// Function implementations
}
Now currently I am feeling that the second method is better. The main reason for that is because I can create the following lists:
List<Renderable> renderObjects; // use this to draw all of the objects to the screen
List<Moveable> moveObjects; // use this to move all objects at once
I really just want confirmation that I am on the right track. I am pretty sure that when creating game objects by composition for games in Java you want to apply the interfaces directly to the Game Object in question and then use private interfaces if you need them and direct implementations of those functions for the rest. Is this correct? And what are the positives and negatives of what I am doing?
Though, while we are here, what else do I need to look out for in the implementation of Compositional Game Objects in Java? What should I do differently? Thanks for any responses in advance, I appreciate any and all help.
Simple Example of Aggregation op=new Operation(); int rsquare=op. square(radius);//code reusability (i.e. delegates the method call).
In Aggregation, if we delete the parent object, the child object will still exist in the system. For example, if we remove wheels from a car, the car can function adequately with another wheel. In Composition, if we delete a parent object, the child object also gets deleted.
Aggregation implies a relationship where the child can exist independently of the parent. For example, Bank and Employee, delete the Bank and the Employee still exist. whereas Composition implies a relationship where the child cannot exist independent of the parent.
Association relationship indicates how objects know each other and how they are using each other's functionality. It can be one-to-one, one-to-many, many-to-one and many-to-many. For example, a person can have only one passport. That is a “one-to-one” relationship.
I have created a few games using java and have also seen the source to a few very good games and it seems the most common way of doing this is with the second method. From what I can tell, the best reason to use the second method is because it becomes easier to keep track of your objects using Lists and allows you to draw using less lines. It seems you are on the right track and the Evolve Your Hierarchy article is a great read for new game developers.
That's an interesting link. I gather that what you have in mind for your Player
class is what that article calls a component container. For that, applying the interfaces to the class sounds to me like the way to go. It's the only route that will lead you to a pure aggregation structure (where there is no longer a Player
class per se in your system.
By the way, the structure you're proposing is basically an application of the delegation design pattern. A Player
relies delegates to a Movement
object all movement operations and it doesn't care what specific kind of Movement
object it has to work with.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With