Object updates, internal vs external?

Question

The title is a bit confusing, but I couln't think of how to explain my question in a short phrase. So here it is:

Whenever I'm writing game engines, wheter it's physics/tilebased etc, I always get to the point where I'm not sure how I should manage things. Should entities in the world handle on their own, or should there be some global system managing them?

Here's an easy example: Moving things. Should each object see the world around him (check for collisions) and move based on that.

[note, this is a tile based game where object move per tile, so I'm not using physics to move from tile to tile]

public class Actor : GameObject
    {
        private void MoveTo(Vector2 location)
        {
            if (world.getTile(location) != solid && world.objAtTile(location) == null)
            {
                Tweener.addTween(this, location);
            }
          }
        }

---

Or should the movement of each object be handeled in the world, where the world checks everything?

public class Actor : GameObject
    {
        private void MoveTo(Vector2 location)
        {
            world.moveTo(location);
          }
        }

public class World
{

    public void moveObject(GameObject obj, Vector2 location)
    {
      //called from object

      if (getTile(location) != solid && objAtTile(location) == null)
         {
                Tweener.addTween(obj, location);
         }
    }
}

It doesn't really matter that much for this example I suppose, but I can see myself getting into trouble later on. Thanks in advance.

Answer 1

I see your examples are in Java, but your tags don't specify any language. In C++, the answer is neither - you should not be using a member function for this!

void move_to(actor *a, world *w, vec2 location);

Answer 2

There is no simple answer.

As with most things in programming, it's a trade off. Giving more power to individual objects makes them larger-and therefore slower-but makes the engine easier to understand and extend. Having a mega-class that can handle everything together might be faster, but at the cost of having a mega-class; that is, it's generally considered bad form to make supermassive classes.

I've read some articles about component and data driven design, where you have a single class which represents all objects of a certain type, storing their data in lists, and passing around only indexes to get properties of an individual object. Though I can see this as a viable type of architecture, I feel it rather screws with the whole point of object orientation, which has gotten its fair share of criticism too.

I personally recommend giving more power to the objects. It makes more sense in an object oriented language, and (I would imagine) easier to understand and maintain over time.

Answer 3

I'm updating my answer because a lot of things weren't clear before the comments. Please bare with me while I explain my thoughts.

In general, two key aspects to consider in any design is cohesion and coupling. We all know that we need high cohesion and low coupling to be able to make a more reusable and extensible design.

So, if the world has to manage everything, that means that it has low cohesion and tight coupling (because it needs to know and do everything). However, this is also the case when a game entity has to do everything. Update his location, render his texture, etc. etc.

What you are really interested in is to create systems that focus on one aspect of the entity. For example, a game entity could have a Texture, but a Renderer would be responsible to render that texture on screen. The Renderer doesn't care what other properties the entity has.

Taking it a little further, a game entity is simply a bag of properties. These properties are manipulated by systems that are focused on specific properties. And this is where Component-based Entity Systems (CBES) come in, where properties = components.

Specifically, CBES with Systems (or SubSystems). This design tends to have a few Systems that are focused on specific components of an entity while not caring about what other components the entity has. Also, the Systems are coupled only with the information they need to process these components.

Let's take your example. Since the input of where to move the entity is based on the player's controller, you would probably have a PlayerControllerSystem. This system, would control, apart from many other things, the entity's PositionComponent. In this case, the PlayerControllerSystem would need to know about the Level and the PositionComponent. If later on you decide to add collision detection, you would create a CollisionSystem that would again use the position of the entities, but this time to calculate bounding boxes (or you could have a BoundingBoxComponent, your call). The fact is, you can easily switch on or off behavior (even on the fly) by simply adding/removing components. So, more behavior means more systems are manipulating the components of an entity, but they are all in a well defined class with low coupling. Want scripting? Add a ScriptComponent. BAM! You just added scripting capabilities with 2 classes. Physics? Sound? Same again.

So, the reason I am advocating CBES with SubSystems is that it is perfectly OO and an overall easy maintainable/extensible system. Adding a behavior to an entity is as simple as deciding what data that behavior needs and which entities need it.

For more information about Component-based Entity Systems with SubSystems, there is an excellent series of blog posts by T=Machine at Entity Systems are the future of MMOG development. The author even went as far as creating a wiki for collecting various implementations named Entity Systems Project

A general (and well-known) post about Component-based Entity Systems in general is the Evolve your hierarchy who created the system for Tony Hawk Pro.

Finally, if you are looking for a library with example code, don't go any further than the Artemis library. Artemis is primarily in Java but here is a port in C# (which I am currently using in my XNA project).

Answer 4

I usually go with a design where objects handle themselves (that's what methods are for, after all) but the base World has lists of all the objects and it uses those lists to coordinate them. So something like:

class World {
  var walls = [];
  var actors = [];
  function update() {
    for each (actor in actors) {
      actor.update(walls);
    }
  }
}

class Actor {
  function update(walls) {
    this.move();
    for each (wall in walls) {
      this.collide(wall);
    }
  }
}

Answer 5

Keep it DRY, shy and tell the other guy.

It's better to ask the world to move your actor than it is to ask the world if you can move to where you want to go. This way you can change pathfinding algorithm easily in the world class and such. Of course, you could just leave this up to a baseclass for the actor, but that's the direction I would take and the reason why.

Answer 6

EDIT: Rewritten due to feedback stating I had not drawn the line clear enough for this answer to the original question.

I would like to clarify the question a bit more if possible. Should the logic that acts upon an object be internal or external to that object. The last part of the post specifically mentions about the longevity of the design as the basis for asking the question, to avoid trouble later on.

My simple high level answer is to keep all logic that acts upon an object within that object.

You do not need the world to move an object, all you need is the object to be moved and the vector representing the location to move to it. The world may come into play when a destination is being chosen or when a reaction to the environment is required due to collision, but those are outside of the example given to work upon.

To address the underlying part of the question and achieve longevity of the design I would suggest a component oriented architecture. Component architectures break down an object into discrete sets of data and functionality (assuming you go with my answer above which states to keep the logic with the data). If your structure looks like CEntity->CHuman->CSoldier->CPlayerCharacter then you will invariably get into issues where you need to alter some logic and depending where it goes in that tree (How many other types of humans are there for instance?) it can have sweeping affects on multiple object types.

A component system would instead have a set of interfaces that define what the CEntity object is made up of like ICompRenderable, ICompMoveable, ICompHealth, ICompInventory and so on. Where you would have CCompMoveableHuman and possibly a CCompMoveableSoldier and CCompMoveablePlayer to keep their individual movement patterns separate. So say the Soldier is altered to run in formations. This change will only affect entities built using that component.

So, to sum up I suggest you contain the logic with the data the logic applies to. I also recommend breaking up objects into discrete components to cut down the 'Where do I put this?' questions and provide stability into the future with ease of maintenance and its extensible.

Hope this helps.

Answer 7

I recommend you try to read up on component based architectures. There are quite a few blog posts, presentations and write ups out there about them that can do a better job than I ever could.

AltDevBlogADay has quite a few posts about it, a very good one being this series about game entities: http://altdevblogaday.com/2011/07/10/the-game-entity-–-part-i-a-retrospect/ There are multiple parts that focus on the issue you're trying to solve.