Actors with multiple Textures - class Hierarchy?

Question

In my 2D side-scroller game I have a bunch of actors being drawn, each of which has a single, non-animated Texture (a png image). These actors all inherit from a base GameActor class.

I want to add some more NPC's (e.g. tanks or cannons) that have one texture that doesn't move (the base) and another that rotates to shoot at things (the gun / barrel). How should I structure my Actor class hierarchy so as to allow for this? Should I refactor my base Actor class to allow for N textures? Or should I create a brand new sort of Actor for things that need > 1 texture (and then have to manage these actors separately from 'regular' actors)? Or is there a better approach I can't see?

Thus far I've been opting to keep things as simple as possible (KISS, right?), but am not sure how to proceed.

Any pointers greatly appreciated.

Answer 1

I've actually read a good article on this (Deep hierarchies vs composition in game coding), unfortunately I can't find it. At any rate, the guy there advocated composition over inheritance whenever in doubt. I'll try to give you the gist of it as applied to your situation.

I honestly think that composition is the way to go (and not inheritance) when it comes to game coding. Usually, the case is you have some basic thing on which you want to put various behaviors in various combinations, rather than make it have one behavior and ALL other behaviors derived from that. I.E. your GameObject base class might support translation and rotation as all game elements should be able to do that. Further more only SOME of your game objects also need collision detection, and more-over some of them might need to emit particles. Now obviously, collision detection ability doesn't automatically imply "ability to emmit particles as well" nor does the other way around make sense. So rather than having CollidingGameObject extends GameObject and then ParticleEmittingGameObject extends CollidingGameObject (in order to be able to also have game objects that support collisions and particle emissions), it's much better to make a base Component class, extend from it a CollisionDetectionComponent (which can work with a GameObejct instance) and a ParticleEmitting component, then have your base GameObject class support multiple components (via composition, like a list of components field), and adding and removing of components. Sure, at the beginning it will be more tedious to code, but once you have all your major components implemented and the component-applying mechanism in place for the GameObejct class, it will be a lot easier to modify/refactor things later, plus your code will be more performant. This is how Unity have coded their engine.

So in your case, I'd make two Texture components, one for static and one for animated one, and then add them as needed on the GameObject base class (i.e. some GameObjects will only have 1 Static texture component, some will have 1 Static and 1 animated, and then later on if your fancy strikes you to make a dual turret tank, you can just add 1 Static and 2 Animated and you're good to go).

Answer 2

For your situation, it would probably be better to avoid modifying your Actor class hierarchy for this problem. Re-factoring your base Actor class to accommodate multiple textures will probably cause a ripple effect that will require you to re-code how your derived Actor classes use textures (which could be a hassle if you have a lot of derived Actor classes). On the other hand, creating a new kind of Actor class in your hierarchy just for multiple textures will make your code less flexible and more difficult to change if you decide to change how your textures are used or displayed. It's better to use inheritance for "is-a" relationships rather than "has-a" relationships.

Therefore, I suggest you instead use a hierarchy for your textures. You could create a DualTexture class that inherits from your Texture class. Then, you could have this class contain two separate images. Any Actor that uses this kind of texture can modify the rotation of one or both of the images through the public methods of DualTexture. Thus, your NPCs could use this kind of texture and handle the game logic to rotate the "cannon" part of the texture without modifying the "base" part of the texture.

Alternatively, if you might be later adding actors made up of more than 2 textures, you can instead make a MultiTexture class for your texture hierarchy. This texture class could contain N images in a list. As a result, any actor using this texture class would be able to have as many textures as it needs.

Answer 3

I think the best design to add some sort of constraints or parenting to your Actors, and make the Turret another Actor which is a child (or location constrained to) the base. That way the rest of the engine can still treat Actors as simple, single part objects but you can build up more complicated structures like a tank.