Question

I am working on a CoffeeScript game engine for Html5 canvas. I came up with the “cool” idea to utilize mixins after I checked a very neat CoffeeScript implementation. I thought, it may be a very cool idea to reduce the various hierarchy of objects that game objects usually provide, by developing a set of mixin-based components, each of which has a very specific functionality. Then, when developing an actual game, one could build unique game objects on the fly by basically starting from one component and mixing it with a bunch of other components. This reduces the hierarchies and allows for frequent changes.

Then I thought about the possible collisions that might come up, for example having a few components define a method with the same signature. Now, I am not as excited as before.

What should I do? Is this a good way? I still like it, especially because of JS’ underlying prototype mechanism, which allows for such an easy way to combine stuff on the fly.

Answer 1

You’re talking about an entity component system. There are a couple written in JS; the most popular is Crafty, which is big but worth looking at. I recently wrote one in CoffeeScript (just for funsies; will probably never release it).

A few notes about collisions:

So first, the problem may be worse than you think: collisions will happen if two methods have the same name; JS doesn’t differentiate function signatures. It also might not be so bad: why don’t you just create a namespacing convention, where each behavior (meaning method) is named after the component it belongs to, like burnable_burn?

To take a step back though, mixins aren’t the only way to build this – behaviors (i.e. things a component can do) don’t have to be methods at all. The motivating question I ask is, how do you trigger a behavior? For example, you might do:

if entity.hasComponent "burnable" #hasComponent provided by your framework
  entity.burn()

But that doesn’t sound right to me; it creates a weird coupling between what’s happening in your game and what components you have, and it’s awkward to check if your entities implement the relevant component. Instead, I’d like behaviors to be listeners on events:

entity.send("applySeriousHeat") #triggers whatever behaviors are there

And then have your component do whatever it needs to do. So when you add a component to an entity, it registers listeners to events. Maybe it looks like (just sketching):

register: (entity) -> #called when you add a component to an entity
  entity.listen "applySeriousHeat", -> #thing I do when this event is sent to me
    #do burnination here

To bring that point home, if you do that, you don’t care about collisions, because your behaviors don’t have names. In fact, you want “collisions”; you want the ability to have more than one component respond to the same event. Maybe it burns and melts at the same time?

In practice, I used both setups together. I made entity.addComponent mix in the component’s functions, since it’s occasionally convenient to just call a behavior as a method. But mostly, the components declare listeners that call those methods, which helped with decoupling and reduced the awkwardness of having to use scoped names, since I don’t call them directly in most cases.