2
\$\begingroup\$

After reading a lot about entity-component based engines, I feel like there is no real definition for this kind of engine. Reading this question, and the linked articles, made me think a lot. I do not feel that comfortable using the system concept, so I'll write something else that is inspired by this pattern. I'd like to know if it is a good way to organize game code, and what improvements can be made.

Regarding a more strict implementation of the 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, but no systems, since the game logic is handled by components. I also think the main difference is the fact that my engine will use inheritance and object-orientated programming concepts, in general. I don't try to minimize them.

  • Entity: an entity is an abstract class. It holds a position, width, height, scale and a list of linked components. 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 the components collection. Components are updated when the owning entity is updated, or for only one specific component (render component), rendered.
\$\endgroup\$
9
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ 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) \$\endgroup\$ – Luke B. Sep 4 '12 at 16:44
  • 1
    \$\begingroup\$ @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. \$\endgroup\$ – MichaelHouse Sep 4 '12 at 17:10
1
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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