Take the 2-minute tour ×

I apologize if the question is a little vague, It was hard to explain it in a short sentence.

I'm currently writing a component based game, it's getting along great but I'm starting to wonder how tightly I should stick to "the rules". Actually, I'm not even sure what the rules are!

It's clear that every interactive gameobject should be an entity. But what about the level elements? I'm using a tile based system, should every tile be an entity? I do have a GraphicsComponent ready with all it's displaying goodness that I need to display them. But coming from inherritance, it just feels strange threating a "gameobject" the same as a level element.

It also feels like I'm dumping everything in a big empty space right now, there is no dedicated environment for different game elements. Where a tile normally is part of a map, and an object normally is part of a world. The tiles and objects are now thrown in the same place.

Same goes for interface components, I was in need of animated button, and that GraphicsComponent looked very tempting again.

How is this usually handled in component based games? Most articles online only mention the use of components for gameobjects, and looking into other component engine source code gives me a headache.

share|improve this question
You might want to consider accepting a few more of your questions - 11% accept rate doesn't encourage people to answer much. –  Kylotan Dec 15 '11 at 3:05
Pedantic note: you're not writing a component-based game. At best, you're writing a component-based game engine. The player certainly should neither know nor care about the structure of your game engine. –  Nicol Bolas Dec 15 '11 at 3:06
There are no "rules." –  Patrick Hughes Dec 15 '11 at 3:27
I indeed have alot of unaccepted questions, I always rush to my code and try the solution. Completely forgetting about my questions.there are indeed no rules, but I'm always very focused on doing things "the right way". –  omgnoseat Dec 15 '11 at 9:05
Note: giving it 24 hours before accepting an answer allows you to get suggestions from across the globe, not just USA. –  Den Dec 15 '11 at 9:25

2 Answers 2

up vote 3 down vote accepted

The main reason for choosing composition over inheritance is flexibility, as most languages allow you to vary the sub-objects of an object at run time easily and arbitrarily, whereas inheritance is fixed at compile time. However, other methods, such as using inheritance, or even just using compile-time composition, is usually less verbose and less error-prone. You just have to know when you need one and when you need the other.

Why should every interactive gameobject should be an entity? Partly because you have so many different permutations of entity properties that it's impractical to create a class for each one. Partly because you might want to define these permutations in data rather than in code. Perhaps it's partly because you want to be able to change them at runtime.

Does this apply to a tile in your game? Probably not. A tile's properties do change based on data, but it's the values that change, not the types of values you need. It's unlikely you need a large number of classes to represent your different types of tiles. I'd probably just have a single tile class, as I can't see the need for more.


If your GraphicsComponent already does the job, you may as well use it. Just be aware of the cost of doing so - is the code more complex than the alternative? Would you perhaps gain by factoring out the rendering code into something your interface can use directly instead of via a component? Is it perhaps easier to hold a hard reference to the component as a compromise between the 2 systems? Use what works for you, given your needs and your code.

How is this usually handled in component based games?

"Usually" is a dirty word when it comes to component based games because there's nothing resembling a consensus on how to make them this way yet. However the main system I'm familiar with, Unity 3D, tries to use components for pretty much everything. It works quite well, but at the price of some additional complexity in terms of making it hard to track interdependencies and the like. So some people bypass this and create their own traditionally coded system within 1 game object, and that works for them also.

share|improve this answer
That's a very clear and interesting awnser. I never thought about the values needing to change, and not the type of values. I can now imagine that making a tile an entity could be pretty dangerous, being able to give it all sort of components it should not be allowed to have. Only entities are able to use components though, but I think I will implement the option to set a restriction for the type of components an entity could have. So I can use the graphicscomponent and not worry about the tile being misused. –  omgnoseat Dec 15 '11 at 20:44

The answer depends entirely on what you mean by "entity". What makes something an entity?

The whole point of components is that you can give real substantive definitions to these concepts. That way, you don't have to use the "entity" class for everything that can move the way many engines do.

You talk about a "level element". What is that? What does it mean for something to be a "level element," and how is that different from the behavior of an "entity?" You are the only one who can answer that.

share|improve this answer
An entity is a class that holds components, it´s the "bag" for components. A level element is a part of the level enviroment, I'm not sure if it differs from an entity, that is the question I'm asking. Whenever I'm reading about the component pattern I only see people talking about entities in a "gameobject" role; An dynamic object in the game that can interact with other objects. A tile is pretty static, always in the same position as part of a level. I'm having a hard time explaining myself so I understand your confusion. –  omgnoseat Dec 15 '11 at 20:38

Your Answer


