Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm in the process of building a new 2D game out of some code I wrote a while ago.

The object hierarchy for entities is like this:

  • Scene (e.g. MainMenu): Contains multiple entities and delegates update()/draw() to each
  • Entity: Base class for all things in a scene (e.g. MenuItem or Alien)
  • Sprite: Base class for all entities that just draw a texture, i.e. don't have their own drawing logic

Does it make sense to split up entities and sprites up like that? I think in a 2D game, the terms entity and sprite are somewhat synonymous, right?

But I do believe that I need some base class for entities that just draw a texture, as opposed to drawing themselves, to avoid duplication. Most entities are like that.

One weird case is my Text class: It derives from Sprite, which accepts either the path of an image or an already loaded texture in its constructor. Text loads a texture in its constructor and passes that to Sprite.

Can you outline a design that makes more sense? Or point me to a good object-oriented reference code base for a 2D game? I could only find 3D engine code bases of decent code quality, e.g. Doom 3 and HPL1Engine.

share|improve this question
add comment

3 Answers

up vote 6 down vote accepted

In general, it's not a bad idea to separate the game mechanics from their visual representation. When you have a game logic which is completely oblivious to how it is displayed on the one hand, and a graphic engine which creates a visual presentation of the current game state but doesn't care about how this state is created on the other, your code will be much more flexible. You could, for example, easily create an alternative visual game state representation, like a minimap, overview map, or an entirely different perspective. You could even switch from a 2d engine to a 3d engine without even touching the game mechanics code. Your visual representations would be equally flexible. When your graphic engine is gameplay-agnostic, you can easily reuse it for a completely different game (just look at how many games make use of the Unreal engine - many of them are not even first person shooters).

So I wouldn't recommend to use Sprite as a base class.

Another reason is because there might be entities in your game scene which don't have a visual representation (event trigger areas, for example). Or you could have objects which have more than one sprite. In a 2d RPG project I took part in, we had characters with a nude base sprite and multiple cloth sprites which were layered over the base sprite. So each entity had 0..n sprites. I could also imagine other genres where it could make sense to have objects which are represented by multiple images blitted on top of each other.

How to build your object hierarchy is very application-specific and depends a lot on your gameplay. So it's hard to provide a definite guideline.

share|improve this answer
Wow, I think you convinced me to separate drawing logic from game logic, many good points. But: Isn't stuff like the position or rotation of my entities part of the game logic? I will either have to sync these properties between entity and drawable of have a bi-directional connection. Neither of that sounds desirable to me. –  futlib Oct 19 '12 at 14:25
The rotation and the position in the game world are part of your game logic. But the position on the screen is not (your screen could scroll and only show a part of the game world). It's the job of your drawing logic to read the world coordinates provided by the game logic, translate it to screen coordinates, and draw the visual representation at these coordinates. –  Philipp Oct 19 '12 at 14:30
I wanted to give this approach a go, but ran into problems immediately. I've got a convenience method for centering entities on the screen that I use in a few places - it doesn't make sense to have that on Entity anymore, but the scene doesn't get access to the Drawable. Also, Entity still controls how it is displayed, because it choses an appropriate Drawable. It just doesn't do the details anymore. Can you give me a quick example of the system you have in mind, or point me to a code base using it? –  futlib Oct 20 '12 at 5:52
Or are you suggesting I pass the whole scene to my renderer and it decides how to render each individual entity? –  futlib Oct 20 '12 at 8:04
Yes, that's what I would suggest you to do. –  Philipp Oct 20 '12 at 10:03
show 3 more comments

Generally you should prefer composition over inheritance where possible. In this example I would not have Sprite as a base class that game objects derive from. Whether to draw a sprite or not would just be a property of the Entity object. I might have Sprite and Text following a Drawable interface, and just associate them with Entities as appropriate.

share|improve this answer
So you're suggesting I remove the drawing logic from entity and have each entity use an appropriate implementation of a Drawable interface by composition? If that's the case - how could the scene tell the entities to draw() themselves if it's not in their interface? And shouldn't I prefer composition only for "has-a" relationships? I think it's "is-a" in this case. –  futlib Oct 19 '12 at 11:51
@futlib No he means that you have a "Component" ( RenderComponent in this case ) which you add to your entity. Your components are objects on their own ( and sometimes just data with no functions ), parts that you can " plug n play" in to your Entities. Edit: I think I went a head of myself. Perhaps Kylotan did mean what you just said. –  Sidar Oct 19 '12 at 11:55
Thinking more about it, I guess the relationship could be explained as "has-a": The text entity has a text, a font style and a drawable representing it on the screen. Still, I need to sync position, rotation, size and font style between text entity and its drawable, so it smells a bit like "is-a". The question is: If I can possibly describe a relationship in terms of "has-a", could I go for composition? Or go for the more natural/convincing description of the relationship? –  futlib Oct 19 '12 at 12:08
+1 for "prefer composition over inheritance". It is classic recommendation in OOP programming. –  topright Oct 19 '12 at 14:02
I didn't necessarily mean an explicit 'Component', but just to have the visual representation as a separate object to the logical representation. The visual representation might be a Sprite object contained within an Entity object, or linked in some other way. –  Kylotan Oct 22 '12 at 16:36
show 1 more comment

Consider to use component-based game object system:

It is very flexible and modern approach which is good for middle- and big-sized games.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.