It ended up being a mildly good idea, because we spent a bit too much time writing some physics logic instead of working on the game itself. However, the Entity System engine worked like a charm: only one issue was found, and it was not even a blocker! I suppose that proves, once again, the value of unit tests.

So, in the lights of this successful use of the Entity System library, I released its first official version: 1.0.0! It is now accessible from npm and bower, with the following commands:

npm install ensy

bower install ensy

ensy stands for entity system, as you might have guessed. I realized while looking for a free name in the npm and bower repos that there where a lot of Entity System implementations out there, but most of them are either using a very different approach (something like Crafty.js does) or not maintained. I'd like to get some traction on ensy, but I know that it will hardly be used by anyone other than me. If you would like to use it but think it lacks something or does something incorrectly in your opinion, please contact me and we can see what could be done. I am happy to maintain ensy and I plan on using it for most of my jam games going forward. (I'll probably end up writing some kind of basic 2d game engine, with generic rendering and physics, to get started more quickly in jams. )

What is this Entity thing anyway?

I wrote about my Entity System library a while ago, but it has changed a lot in the meantime. This version has been entirely rewritten and is nothing like the previous one. The key concepts are still the same, but their implementations changed wildly. Let me give you a quick tour of the new concepts, and of what you can do with it.


An entity is a mere identifier, like a string or a number. It has to be unique in the system, of course. Entities represent the various objects of your game, but they do not hold any data nor logic. Their sole purpose is to serve as an evolving collection of components. That's why they are simple identifiers: the system is able to associate an entity to a list of components.


Components contain the data of your game. They only exist in the context of an entity, and do no kind of logic: they are simple containers for simple data. Here's a rule that helps understanding what you can or cannot put in a component: components have to be serializable. They shouldn't contain objects either, because if you want to put an object in a component, that almost always means you actually want to create another component.


Processors are responsible for the logic of your game. They access lists of components and apply operations on them. For example, a simple Display processor would go over all the Sprite components and show them on the screen. A Physics processor would take all Falling components and apply some gravity to them. Processors should always be independent of each others, communicating data through components only.

There is documentation available on readthedocs, and if you want to understand the concepts and implementation better, I recommend you read this excellent post by Adam Martin: Entity Systems are the future of MMOs.

What does it look like?

Here is a very basic example of how to use this library:

// Create a manager for your game.
var EntityManager = require('ensy');
manager = new EntityManager();

// Create some components.
var Falling = {
    name: 'Falling',
    state: {
        x: 0,
        y: 0
manager.addComponent(, Falling);

// Create some processors.
var PhysicsProcessor = function (manager) {
    this.manager = manager;

PhysicsProcessor.prototype.update = function (dt) {
    var fallings = this.manager.getComponentsData('Falling');

    // Make them fall.
    for (var f in fallings) {
        var falling = fallings[f];
        falling.y -= 5;

manager.addProcessor(new PhysicsProcessor(manager));

// And get your main loop starting.
function mainLoop() {
    var dt = 10; // Compute elapsed time since last frame here.


There are more complex examples available: a Concentration game, quite simple, and the game I worked on during the last GDP Jam, Total Madness Arena. This last one is more substantial, though I learned a lot while working on it and would very probably code it a bit differently if I were to do it again. (Notably, I would try to keep only one manager through all scenes, instead of having one per scene. That means the Entity System manager needs a way to remove a bunch of entities at once, which is not a feature yet. )

I hope you like ensy! Let me know if you have questions, or if you are using it.