Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

After reading a lot about entity/component based engines. I feel like there is no real definition for this kind of engine. Reading this thread: Implementing features in an Entity System and the linked article made me think a lot.

I did not feel that comfortable using System concept so I'll write something else, inspired by this pattern. I'd like to know if you think it's a good way to organize game code and what improvements can be made.

Regarding a more strict implementation of entity/component based engine, is my solution viable? Do I risk getting stuck at any point due to the lack of flexibility of this implementation (or anything else)?

My engine, as for entity/component patterns has entities and components, no systems since the game logic is handled by components. Also, I think the main difference is the fact that my engine will use inherence and OOP concepts in general, I mean, I don't try to minimize them.

  • Entity: an entity is an abstract class. It holds his position, width and height, scale and a list of linked components. The current implementation can be found here (java). Every frame, the entity will be updated (i.e all the components linked to this entity will be updated), and rendered, if a render component is specified.
  • Component: like for entity, a component is an abstract class that must be extended to create new components. The behavior of an entity is created through his components collection. The component implementation can be found here. Components are updated when the owning entity is updated or for only one specific component (render component), rendered. Here is an example of a logic component (i.e not a renderable component, a component that's updated each frame) in charge of listening for keyboard events and a render component in charge of display a plain sprite (i.e not animated).
share|improve this question
up vote 8 down vote accepted

Regarding a more strict implementation of entity/component based engine, is my solution viable?

Will it work? Sure, you can make it work. But I wouldn't recommend it.

Do I risk to get stuck at any point due to the lack of flexibility of this implementation (or anything else)?

You're straying pretty far away from the entity/component concept. Without the systems, the components have to know about each other for things to get done. That means they can no longer happily do their work in isolation and they get very complex the deeper into the project you get. The more complex the components are the more issues you'll have creating new types of entities. Some entities will have loads of code and data in their components that they don't use. Eventually you'll run into all the same problems as an inheritance structure.

share|improve this answer
What is the reason for systems? I get that they suposed to be logic and components are suposed to be data, but why can't a component do both and decrease the amount of code? You could even use the entity as a way to pass messages around (instead of having a pointer to another component) – Luke B. Sep 4 '12 at 16:44
@LukeB. They're the part the joins the pieces together. Systems are the processors, components are the data. Check out this answer. Stuffing the systems into the components makes the components far less flexible and could result in code duplication or lots of data that's unnecessary in components. – Byte56 Sep 4 '12 at 17:10

I love Component based frameworks. For a long while I looked for a way to uncouple the logic from the data from the graphic. I tried to apply MVVM patterns to game entities but really it did not work. Eventually I wrote my entity based framework and everything became simple and smooth! The main rule is too keep it simple. The second rule is to reduce the flexibility as much as you can. Giving more options to the user is confusing. You should design the as perfect as possible way to solve problems and assume that that way is enough.

Component based frameworks promote composition over inheritance by definition. Initially I thought to let the user inherit from Entity and define his own Entity, eventually I realized that that was a redundant option. Now the user can only define components.

My last advice is to let the user inject dependencies through component constructor. In this way it will be also simple let entities communicate each other.

The definition of the behaviors of the component through interface is more or less what I have done as well and I find it a very good idea.

Edit: About the system, yeah I called them Engines in my framework. They are a good idea as well, solve part of the communication problems, so no, they should not be removed.

share|improve this answer

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.