First, the questions:

  1. Should each Entity (which are classes like Character, Tree, Enemy) have its own update() and render() methods?

  2. If that's the case, then should I use Interfaces like "Renderable" and "Updatable"?

I ask you this because most of the tutorials I followed "told" me to include all Input Handling and Updates inside the Game's main update() method, and all the Rendering inside the Game's main render() method.

I know these tutorials are very simple but even a few more complex ones still had all the Entities' actions inside the same block of code, which made me doubt the ideas I previously had (separating updates and renders per each object).

To clarify, I feel like I should have something like this:

update() {
    for each active Entity in the game right now {

Then, the same thing for rendering (except the input part). Am I following the right path here or should I rethink the current architecture ideas I have? Thank you.

  • \$\begingroup\$ seems reasonable \$\endgroup\$ – Eric B Jan 2 '13 at 18:48
  • 2
    \$\begingroup\$ Is this an entity / component system? If yes, generally you are going to have components that are updated by a "system". The best example I can remember of how systems work is here \$\endgroup\$ – SpartanDonut Jan 2 '13 at 19:29
  • \$\begingroup\$ @ToddersLegrande Yes, I'm studying/implementing the Entity-Component system and that link will be very helpful. Thanks! \$\endgroup\$ – Lucas Tulio Jan 3 '13 at 0:29
  • \$\begingroup\$ If you want to use an existing framework for an entity system (developed in java) you can use the quite famous framework: Artemis, or you can use the source code to learn about ways to implement one. \$\endgroup\$ – miguel.martin Jan 3 '13 at 9:11

My opinion is that an entity should have its own Update method, but not its own Render method.

The entity contains most of the information necessary to update itself. It may require a bit of information about the context, such as the world, other entities nearby, etc., but most of the information is contained within the entity. Therefore it is the natural place to put the updating logic.

The entity usually does not have most of the information necessary to render itself, however. Rendering details for an entity might depend on the viewer's distance from the entity, the viewer's settings, whether the program is running in client mode or server mode, etc. Therefore it usually makes sense for an external rendering object to query the entity for whatever information it needs to render it.

In general, your game logic should not know about your presentation logic, because presentation is usually irrelevant to the underlying gameplay. However, the reverse is not true, because the presentation needs to know about the game state in order to render it. This is consistent with the Model View Controller paradigm, where the entity handles the model and the renderer handles the view.

  • \$\begingroup\$ I used to give my entities both an update and a render method -- but you convince me. How would you structure your render system in classes? Would you have one render class for each entity class? \$\endgroup\$ – opatut Jan 3 '13 at 15:28
  • 1
    \$\begingroup\$ Yes, but generally I only ever need 1 entity class, because the differences between entities can be defined by data (or components, if you like that approach). \$\endgroup\$ – Kylotan Jan 3 '13 at 16:01
  • \$\begingroup\$ Thank you for your input, Kylotan. Things are getting clearer for me now. \$\endgroup\$ – Lucas Tulio Jan 7 '13 at 20:40

If your game consists of a few entity types, this approach will most likely suffice without little problems; however as the game's entity toolbox grows and more logic is needed to make various game entities, you'll find that inheritance trees are not ideal for entities. In such a situation, you'd want to favor composition rather than inheritance.

In a composition-focused game entity system, entities hold a list of features called components that comprise their overall functionality. You may have a TransformComponent that holds the position and orientation of an entity. You may have a RenderComponent that holds mesh information about how to render an entity to the screen. You may have a PhysicsComponent that holds rigid body information about how the entity will react to collisions in the game world.

class IComponent {
virtual void Update(elapsedTimeMS) = 0;

class Entity {
   std::vector<IComponent*> mComponents;
/* other stuff */

At initial glance, you may think now to update entities, you would write something like:

foreach(EntityList::value_type& entity, mEntities) {
  foreach(ComponentList::value_type& component, entity->GetComponents()) {

This may work until dependencies exist between entities, such as a character holding a weapon or dependencies exist between components such as updating position before drawing the render component.

The way I approach that problem is to use systems to update like components across all entities rather than the update approach above. As a side note, this also will prove helpful when you consider supporting multiple thread updates as the system approach can easily be morphed into a ParallelFor() update.

void UpdateRenderablePosition::Update(long elapsedTimeMS) 
  // map<entityId,vector<IComponent*>> of entity/components
  EntityComponentMap entities = 
  EntityComponentMap::iterator i = entities.begin();
  EntityComponentMap::const_iterator iend = entities.end();
  for(; i != iend; ++i) {
    PositionComponent* position = reinterpret_cast<PositionComponent*>(i->second[0]);
    RenderableComponent* renderable = reinterpret_cast<RenderableComponent*>(i->second[1]);

void RenderSystem::Update(long elapsedTimeMS) 
  ComponentList& components = mEntitySystem.GetComponents<RenderableComponent>();
  foreach(ComponentList::value_type& component, components) 
    SceneNode* node = component->GetSceneNode();

While the code is meant to illustrate an example, the two systems have update methods which are called during the game loop. Each update method performs certain transformations to the components. These system updates are strategically ordered in the game loop based upon dependencies introduced by game logic.

The benefit to such an approach is that its highly modular. One can introduce a new component and matching subsystem without affecting the behavior of the rest of the game entity's behaviors. Additionally, it allows an entity to truly be composed of any feature-set you wish without the need to place that within the confines of inheritance. And finally, you can control how you update entities and manage their dependencies much cleaner than you would within inheritance.

The code presented is merely a means to illustrate alternatives. Look up entity component design and even data-driven design if you want to dig deeper into the subject.

  • \$\begingroup\$ Why are you assuming an inheritance tree? The absence of a component-driven design doesn't imply a rigid overuse of inheritance. Besides, simply packaging functionality up in 2 contained components doesn't really improve anything because the entity still essentially owns all the same data. \$\endgroup\$ – Kylotan Jan 3 '13 at 0:26

What you want to do is exactly what XNA does, as you can see in this diagram from DigitalRune, they have a GameComponent, a DrawableGameComponent, and yes, IUpdateable and IDrawable Interfaces.

And just as you have pointed it may work like this:

Every 1/60 seconds {
    for every (IGameComponent) component on componentsList {
        //Input system:
        //Update System:
        if(component is intance of IUpdateable) component.Update(...)
        //Draw System:
        if(component is intance of IDrawable) component.Draw(...)

This is based on entity/component/system architecture, XNA is very malleable so you can do whatever you want with it, but this question is not about XNA, so you can see an IGameComponent as an Entity, and the way to check which entity fits on what system may be asking the entity to implements a certain Interface.

If the complexity of the code grows to much, you can extract the systems functionalities to their own classes.

Following the entity/component/system as you have pointed you can encapsulate the code outside the main Game Class and inside the Entities and Systems classes.

Some tips:

  • If a set of functionality of an entity needs to access various others entities then you should consider to put that code outside the entity and inside of a system, because the system is supposed to have access to those others entities; while the entity not.

  • Check if an entity is instance of something may be slow in some languages, so instead you can have a flag of bits to handle this, other way may be to have different lists, one for each system, and then you classify each entity only once.


I'm going to assume all your entities are subclasses of an Entity class.

Entity has the following properties:

  • states - a hashtable of animations/images with associated string names
  • activeState - name of the entity's current state
  • children - a hashtable of other entities, whose position is relative to this entity
  • position - x and y position. I don't like Slick's Vectors class, so I wrote my own and use that for all coordinates

Besides getters and setters, it has the following behaviors:

  • render - draws the entity at its position, then loops through all children, calling their render methods
  • update - calls callback method "onUpdate" and then calls the update method on all children
  • onUpdate - empty callback method designed to be overridden by children

With this system, you can set up a certain kind of entity by creating a subclass and setting it up in the constructor (attaching states and children). You can also update in the onUpdate() method.


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.