5

I'm trying to create a simple 2D sprite game. The problem I'm having now is how to design my game. I was thinking of using a Sprite class that will be my base class for all the different types of Sprites I will use. The problem in my design is wheter to let every Inherited Sprite class draw itself, having a Draw method or should I have a centralized DrawEngine that handles all the drawing for me. Which method is the preferred one to use?

If I use the DrawEngine method how do I go about sending Textures to it? All the different Sprites will have different textures and the DrawEngine doesn't really know about the sprites. Could someone please help me out how to solve this problem how to handle textures in a DrawEngine class?

PrettyPrincessKitty FS
  • 10,315
  • 8
  • 43
  • 68
Hachaso
  • 51
  • 2

3 Answers3

8

The very first question you need to ask yourself about the "class" Sprite is this: what is a sprite?

Is it the image? Is it an entity in the game world that has gameplay properties on it? Is it a collision box? Etc.

If a "Sprite" represents only the position and orientation of an image (possibly selected from a sheet of images), then you don't really have different "kinds" of sprites. You have a Sprite, which can be rendered. There's no need for inheritance here. You can have sprites that have different images and so forth, but that's just the data stored in the sprite.

Let's call the class for this "SpriteImage."

If a "Sprite" is fundamentally a gameplay entity, then this entity would contain an object that represents how it gets drawn. You don't draw entities; entities don't draw themselves either. Entities contain one or more objects that they will give a position and orientation to, which represents how the visual representation of the entity is presented.

Let us call this class "SpriteEntity". This class might contain one or more of the SpriteImage objects, and it would be responsible for providing the position and orientation of these objects. It would also handle animating them (selecting which image to show). However, it would not draw them; the drawing of these images would be handled by an object that also holds a reference to these SpriteImage objects. Here, you should employ smart pointer usage; SpiteEntitys would contain shared_ptr's to their SpriteImages, while the SpriteImageDrawer would have a list of weak_ptrs to every SpriteImage that is created.

Of course, this is just one way of structuring things. You can choose your own, but the separation of "entity" from "image" is a very good idea. For example, the above architecture would allow some "SpriteEntity" objects to have no visual representation at all. This is useful to create collision areas (since entities would have collision areas, even if you don't see them), so that you can detect when another entity touches that area and do something based on that. It would also allow some "SpriteEntity" objects to have multiple sprites, possibly hierarchically layered. This would be for doing things like drawing weapons on characters, etc.

Nicol Bolas
  • 26,068
  • 3
  • 76
  • 104
  • 1
    My idea is that a Sprite has different properties. So your idea of having a SpriteEntity is really interesting. Do you mean that the SpriteEntity class will be a base class for other classes to inherit from or should I maybe have different types of SpriteEntity classes for the different SpriteImage objects ? – Hachaso Jul 15 '11 at 02:49
  • 1
    @Hachaso: What purpose would be served by deriving from SpriteEntity? It contains SpriteImages; why derive from it? What would subclassing accomplish? If you want entities to have different behaviors, then create a Behavior class that you can attach to a SpriteEntity. You can subclass that Behavior class. – Nicol Bolas Jul 15 '11 at 02:51
  • 2
    +1 for separating sprites and the actual entity logic. There's no reason for the graphics to know about its HP or its weapon. – PrettyPrincessKitty FS Jul 15 '11 at 09:30
  • @The Communist Duck If you need to be able click on an object, somewhere along the line this like has to be made. But in general I agree it's a good idea. – Jonathan Connell Jul 15 '11 at 12:28
  • @3nixios: If you want that clicking to be 100% perfectly pixel accurate, then yes. However, a bounding-box test is usually good enough. And even then, you wouldn't use the image directly; you use a bitmask created from the image. – Nicol Bolas Jul 15 '11 at 18:13
  • @Nicol Bolas Agreed. – Jonathan Connell Jul 15 '11 at 18:20
2

It really depends on a couple of factors such as

  • how much functionality you want to put into your sprite class
  • how complicated it is to actually draw the sprites on screen
  • how many sprites you're drawing at once using the same texture

Letting each Sprite draw itself is nice from an object oriented design perspective but then it's hard to optimize your rendering code. In general it's always good to put rendering/drawing code in a separate module (such as the DrawEngine you proposed). So if you're drawing lots and lots of Sprites with the same texture you can batch draw those together.

Concerning the actual implementation, you could create a special drawing interface which the Sprite class implements, that supplies the DrawEngine with everything needed to draw the Sprite (bounding box, texture, alpha, etc.). You then hold a list (or scene graph for more complex games) with all your Sprites and let the DrawEngine iterate over it, either drawing the Sprites immediately or sort them by texture and draw afterwards.

Alexander Benz
  • 141
  • 2
  • 1
    At this point you could learn from XNA's SpriteBatch, which combines both. A sprite takes charge of drawing itself - but it only figures out what will go to the screen, then registers that with the XNA pipeline. Unless I'm mistaken, the pipeline doesn't actually draw anything until after all the draw calls. It's a well-executed separation of concerns. – doppelgreener Jul 15 '11 at 02:04
  • 1
    Do you know if there are any good toturials on this approach using a DrawEngine ? – Hachaso Jul 15 '11 at 02:51
2

Currently the way I'm implementing the process of drawing is to have a Sprite class that is just an image, where it needs to be drawn (incl. rotation and Z-depth), alpha levels, and which frame to draw. Then I have a separate SpriteHandler class that contains all of the methods as static methods that perform all of the actual drawing. The user can then either use the methods individually or register it with the handler and it will sort by z-depth and draw in the correct order.

Casey
  • 2,025
  • 2
  • 17
  • 26