Actor and Sprite, who should own these properties?

Question

I'm writing sort of a 2D game engine for making the process of creating games easier. It has two classes, Actor and Sprite. Actor is used for interactive elements (the player, enemies, bullets, a menu, an invisible instance that controls score, etc) and Sprite is used for animated (or not) images with transparency (or not).

The actor may have an assigned sprite that represents it on the screen, which may change during the game. E.g. in a top-down action game you may have an actor with a sprite of a little guy that changes when attacking, walking, and facing different directions, etc.

Currently the actor has x and y properties (its coordinates in the screen), while the sprite has an index property (the number of the frame currently being shown by the sprite).
Since the sprite doesn't know which actor it belongs to (or if it belongs to an actor at all), the actor must pass its x and y coordinates when drawing the sprite.
Also, since a actors may reset its sprite each frame (and usually do), the sprite's index property must be passed from the old to the new sprite like so (pseudocode):

function change_sprite(new_sprite)
    old_index = my.sprite.index
    my.sprite = new_sprite()
    my.sprite.index = old_index % my.sprite.frames
end

I always thought this was kind of cumbersome, but it never was a big problem.

Now I decided to add support for more properties. Namely a property to draw the sprite rotated, a property to draw it flipped, it a property draw it stretched, etc. These should probably belong to the sprite and not the actor, but if they do, the actor would have to pass them from the old to the new sprite each time it changes... On the other hand, if they belonged to the actor, the actor would have to pass each property to the sprite when drawing it (since the sprite doesn't know which actor it belongs to, and it shouldn't, since sprites aren't just meant to be used by actors, really). Another option I thought of would be having an extra class that owns all these properties (plus index, x and y) and links an actor with a sprite, but that doesn't come without drawbacks.

So, what should I do with all these properties?

Answer 1

A common way to deal with the problem you're describing is to do this:

class Transform
{
   public int x;
   public int y;
   public float rotation;
}
class Actor
{
   public Sprite s;
   public Transform t;
}
class Sprite
{
   public Transform t;
}

Now your data is encapsulated in one class ref'd by both Actor and Sprite. As for that separation, yes I think that's a good idea as the actor is essentially game logic, and the sprite is a view -- they are in this sense completely decoupled for cleaner code.

So you can take that as a more general, "yes" to your final suggestion. Push things out into intermediary classes where appropriate.

Answer 2

Each object should own its own properties. If other objects need to know those properties, let them query for them.

Your sprites probably don't have an intrinsic position, and they don't know how to get a position to be rendered because they may have to get that information from more than just Actors. So, you need a class that mediates between them. You might have an ActorView that holds a reference to the Actor and contains an instance of Sprite. When the Actor moves, ActorView is notified, and knows where to draw the sprite. The ActorView could also hold the current frame of animation, etc.

Answer 3

Classes and objects are just bundled functionality, nothing more. And that way you should work with them.
Ideally you should build your classes around composition. The more advanced object should consist out of multiple smaller objects, and do all the communication needed between the smaller objects. The smaller objects should do nothing on their own and should know nothing about their parent. They just should do what is wanted from them.
In the case of this question that would look like this:

class Actor
{
  Sprite sprite;
  int x, y;
  float rotation;
  [...]
  void draw()
  {
    sprite.draw(x, y, rotation);
  };
  void update(dTime)
  {
    sprite.advanceAnimation(dTime);
    [...]
  };
  [...]
}

Answer 4

Whenever you encounter a situation like this, there are a couple of questions you can ask yourself to determine the what the best structure is going forward:

• Is one class a more complex version of the other class?
• Should one class know about the other?
• What overall purpose is the class supposed to serve?
• Is one class a utility to be used by more complex class?

If you answer yes to the first question, then inheritance is what you're looking for. For example, a regular sprite, or a sprite that supports multitexturing. In the case you're describing, the answer is probably no, an Actor is not a more complex Sprite. I think you are right that the Sprite class should not know about the Actor class, because, tying into the fourth question, the Sprite class is really a rendering utility for the Actor class; the Actor class relies on the Sprite class to draw itself on screen.

So, the Actor class should contain an instance of the Sprite class, in the same way that a GameObject in a 3D engine would have a Model to represent itself in the world.

To get to the specifics of your question, it seems like the root of your problem is your concern in how much maintenance the Actor class is going to have to handle for its Sprite. You mentioned that the Sprite instance often changes every frame, and the Actor would have to be responsible for updating it (I'm guessing this is for 2D animation?). I think this is where your structure goes wrong. What I would suggest is to create an AnimatedSprite class, which is responsible for the update of it's current on-screen sprite, and would store the 'index' of its animation. It's API could include functions such as animate, stop, etc; everything you might want an animated sprite to do. For position, your Sprite class' draw-call should take in the position where it is to be drawn.

What's most important is that a whole class instance inside of your Actor class should not have to be reconstructed every frame. If that becomes necessary, you should probably look for areas of improvement in your architecture.