Everything you never wanted to know about Jon Watte

Thanks for your comments!

First -- the code is probably more like pseudo-code than a ready-to-go library you can paste-and-use. It's used to illustrate the concept; you are intended to learn from this and implement it yourself in whatever way suits your engine.

That being said, I don't see where the type problem comes from. The World calls OnAttach() on Entity, passing in the World. The Entity calls OnAttach() on the Component, passing in the Entity. In each case, the function in question seems to be taking the right type argument.

Second, there is no standard SceneGraphNode class -- it just suggests how you can integrate a separate scene graph with a component-based entity system. Specifically, you do *not* want a system where each Entity (or, worse, Component) gets a callback to render each frame, whether they want it or not.

Finally, I believe delegate types can be members of classes as well as members of name spaces. To use them, qualify them like any other class scoped type, with the class name.

Just pass a Type object, and use Type.IsAssignableFrom() on component.GetType() to test for compatibility. This allows you to ask for specific interfaces, too.

One way of doing this is with generics. If memory serves:

  T FindComponent<T>() {
    Type t = typeof(T);
    foreach (Component c in components_) [
      if (t.IsAssignableFrom(c.GetType())) {
        return (T)c;
      }
    }
    return null;
  }

The integer iterators mean that you can mutate the lists while iterating without throwing. That might be useful in the case of, for example, updating all the components letting a component add another component, but might also be quite dangerous, so don't feel any particular need to emulate that style :-)

Sorry I'm late to reply.

The problem with "the health subsystem" and "the pizza-making subsystem" is that you have to know what the subsystems are beforehand. Yes, I've also heard of this -- there are game engines that have 50 different pointers in their "struct Entity," and a pointer is either NULL, or points to a known species of subsystem (particle system, collision generator, or whatnot). It's a more pragmatic way to get something done as long as you control the entire code base, but if you want to support plug-ins, or use the code base across parallel projects, it might get in the way.

When it comes to pointers vs messages, in either case, if the recipient isn't there, whatever you intended to happen won't happen. Testing for NULL can happen in the caller of a function, or in a message dispatcher finding nobody is subscribed. The difference is not earth-shattering (although function calls allow function return values).

To add two mutually co-dependent components (I've actually done this), I would suspend the entity, add both components, and then resume the component; suspending detaches components and resuming re-attaches components. Thus, they will find each other in the onattach callback.
Although mutual dependence is generally a design problem -- perhaps you should merge them, or find a third common component to both depend on, or break the cycle some other way.

What is a "game state"? A different level? A different game mode? (multiplayer deathmatch vs capture-the-flag vs singleplayer story)?

For a different level, I would dispose all the content (in the XNA content manager), throw away the current world (let GC take care of it), and load a new world fresh with new data.

For a different game mode, when it's networked vs not, that typically goes into another abstraction (like input, say), although I can see how you could allow modes to affect all object creation. For example, the network manager could add a networking component to any object that gets added to the world, if it's an object it cares about.

One option would be to have an AIBehaviorComponent that you add to entities. If the MovementBehaviorComponent asks for an IMovementCommands interface from other components on the entity, then a user-controlled entity can have a UserMovementCommands that exposes that interface, so the MovementBehaviorComponent doesn't need to know whether it's driven by AI or a user.

For higher-level thinking, like "I need to control this area of the map," that would either be an entity in and of itself, or it would be a totally separate system. Either way, it would have to query the map and the world for information that it can use for its decision making somehow. The runtime cost would be the same in both ways, so whether you make "AI thinking" an entity or not is more up to how it would fit into your particular game.

Well, Component could be an interface (IComponent), or SceneGraphNode could be an interface (ISceneGraphNode), or the RenderableComponent would simply own a SceneGraphNode that it configures accordingly. It all depends on how specifically you want to implement it. Personally, I make ISceneGraphNode an interface, but if you have heavy-weight nodes in your scene graph, delegation (ownership) would probably be better for you.

You could just add a "Parent" property to the Entity if that's what you wanted. The Entity does contain some very common properties, like Position etc -- in a hierarchical system, "Parent" could very well be one of those.

An alternative is to add an IParented interface, which has a Parent property, and when you need to parent something, you add a component that implements that interface. That would be the ultimate in componentizing, but probably too complex for most simple situations :-)

For my games, I haven't needed parenting, though, because my entities are fairly coarse (entire characters, etc), and for animation hierarchies, I treat an entire skeleton as a component, which exposes "attachment points" that other things can slave their position off of (rather than "attach to").

If you post anonymously, the comments need to be approved before they're shown. If you register and log in, that's not needed.

When I started out, I had an entity system that went up to three deep (entity -> vehicle -> car), but I've since actually just flattened it down to a single level. There's just Entity.
For components, there's now just two levels: Component, and the concrete component kinds (EnginePropulsion, LaserWeapon, etc), using interfaces for the commonalities of being Propulsion or Weapon.

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/
According to this guy who was a developer on one of the early Tony Hawk games, they used it there, not sure which game in the series, my guess would be 1 or 2? I'm not sure if they still use it in the current versions.