General purpose Entity-Component System implemented in JavaScript.
Traditional Object Oriented Programming has the inherent problem of enforcing tree-like distribution of functionality among active entities, which are the instances of different classes. A class is a wrapper of certain functionality, which is then accessible via an "agent” in the memory, when an instance of this class, or any descendent, is created. This is quite limiting.
Let's investigate, an artificial, but illustrative example. If you need to have three types of instances:
Humanswhich are capable of walking;Planeswhich are capable of flying;Birdswhich are capable of both flying and walking;
You can inherit walking in Birds from Humans, but then you'll need to have separate implementation of flying for Planes. Alternatively, you can inherit flying in Birds from Planes, but then walking should be re-implemented in Humans. In either scenario one skill (a.k.a set of methods) should be implemented twice.
Multiple inheritance, found nowhere but in C++ is quite complicated solution, neither being recommended, nor actually solving many of the problems — sharing some state information between different classes, within the same entity.
Additionally, some languages, like JavaScript, are not designed in a traditional inheritance centric OOP manner. Rather, upon instantiation of an object, it is assigned a prototype, which defines the core (basic, fallback) functionality of this entity.
So, if one has implementations of different_skills_, he/she can assemble them into a single prototype and all objects (which we call agents) instantiated from this prototype, will have all the skills. This is exactly what asSys library is doing.
The shorthand for asSys is chosen to be a$, so this is going to be used from now on. Let’s have our Flying and Walking skills defined like this:
var Flying = function () { this.isFlying = false; }
Flying.prototype = {
takeOff: function () { this.isFlying = true; },
land: function() { this.isFlying = false; }
};
var Walking = function () { this.isWalking = false; }
Walking.prototype = {
go: function () { this.isWalking = true; },
stop: function() { this.isWalking = false; }
};It’s not the most meaningful implementation, but enough for the example. So, what will it take to have Humans type objects (entities, agents) defined using a$? Only this:
var Humans = a$(Walking);Pay attention, that Humans is not an instance in the normal OOP sense. To allocate one we must do:
var aGuy = new Humans();Of course, we haven't added too much functionality — because we could freely use standard JavaScript allocation, like this:
var aGuy = new Walking();It's the same. But, let's see how Birds are defined:
var Birds = a$(Walking, Flying);Now, that is different! Again, new actual birds are instantiated this way:
var aFalcon = new Birds();And, of course, creating and instantiating Planes is no more difficult:
var Planes = a$(Flying);
var aJumbo = new Planes();In this example Planes, Birds and Humans are dynamically constructed functions, which (upon instantiation) invoke all the passed skills's constructors (i.e. functions) in the same order, in which they are given. This function construction happens only once - during a$(<whatever skill>) invocation, not during each instantiation.
However, in its role as a constructor, this function does invoke all supplied skill-defining function on each invocation.For example Birds is a function, that invokes Walking() then Flying() each time a new bird entity is allocated, but Birds function itself, is constructed once.
The functionality presented so far, can easily be achieved with C++ multiple-inheritance as well. But, stay tuned...
Let's define the basic skills a bit differently:
var Flying = function () { this.isFlying = false; }
Flying.prototype = {
takeOff: function () { this.isFlying = this.isMoving = true; },
land: function() { this.isFlying = false; }
};
var Walking = function () { this.isWalking = false; }
Walking.prototype = {
go: function () { this.isWalking = this.isMoving = true; },
stop: function() { this.isWalking = false; }
};We've added isMoving property. Now we can check for it in all agents:
aGuy.go();
if (aGuy.isMoving) { alert("aGuy is moving!")}
aFalcon.takeOff();
if (aFalcon.isMoving) { alert("aFalcon is moving!")}This is quite convenient! Actually sharing of properties and methods is vital for effective combination of skills, and quite natural when one combines different sets of features.
If certain cooperation (between skills) is about to happen, there are some expectations arising. Let's say we want to wrap the isMoving setup into a separate method like this:
var Flying = function () { this.isFlying = false; }
Flying.prototype = {
takeOff: function () { this.wakeUp(); this.isFlying = true; },
land: function() { this.isFlying = false; }
};
var Walking = function () { this.isWalking = false; }
Walking.prototype = {
go: function () { this.wakeUp(); this.isWalking = true; },
stop: function() { this.isWalking = false; }
};That will fire an exception, because no skill is providing wakeUp() method. But, this error will occur on the first attempt to use it, which could be quite misleading. So, asSys allows each skill to list methods that it expects to be present already:
var Flying = function () { this.isFlying = false; }
Flying.prototype = {
__expects: ["wakeUp"],
takeOff: function () { this.wakeUp(); this.isFlying = true; },
land: function() { this.isFlying = false; }
};
var Walking = function () { this.isWalking = false; }
Walking.prototype = {
__expects: ["wakeUp"],
go: function () { this.wakeUp(); this.isWalking = true; },
stop: function() { this.isWalking = false; }
};Now, there will be an error again, but this time it'll happen in this line, i.e. - at the moment a new type of agent is defined:
var Humans = a$(Walking);asSys will report missing expectation, as an exception. Providing a skill that actually has this method defined, is what needs to be done. For exmple:
var Being = function () { }
Being.prototype.wakeUp = function () { this.isMoving = true; }
var Humans = a$(Being, Walking);
var aGuy = new Humans();
aGuy.go();As can be seen, this approach allows one to combine functionality from different places freely, in order to cover the features a certain type of object in the system is expected to have. This opens the gate for much more independent approach in developing libraries and combining them.
Bringing an analogy from chemistry—another way to look at this is like atoms and molecules. Atoms are the basic building blocks and they don’t have hierarchy among them—they have valence i.e. potential for combining. What we actually use and observe as characteristics, however, are the molecules. They are built from atoms, with different combinations, based on their valences. And, again, there is no hierarchy implied in the domain of molecules as well.
So, the Agent-Skills, (a.k.a Entity-Component) system’s paradigm follows the same principles—decomposing the set of features into atomic groups (skills in our terminology), and opening the possibility for free composition.
A crucial part of Entity-Component system is the ability to handle sets of similar entities. In our case they are called groups and this is how they are created, for example:
var birds = a$.group(everybody, (a) => a instanceof Birds); // birds only
var airborne = a$.group(everybody, true, (a) => a$.capable(a, Flying));Here, everybody is supposed to hold all entities of the system, and the predicate provided as a last argument to group() function is for filtering. The capable() function will described later, because the true found as a second argument in the second example is more interesting.
It tells the asSys construct the resulting group as an agent with invocable methods, i.e. it has non-enumerable properties, which are common for all filtered agents/entities, including functions. And here is the best part—those functions are constructed to invoke the corresponding method of all listed agents in the group. In other words, in the context of the above example, this:
airborne.takeOff();... is totally valid and it will invoke takeOff() method of all agents/entities inside airborne array (yes, it is an array).
A simpler set of convenient methods are capable(), can(), common(), etc. They are better explained in the Reference.
The last piece of trickery is managing the overlapping methods, i.e. those that are present in more than one provided skill. The most obvious case would be the very popular init() method. If we need to enrich our example case:
Flying.prototype.init = function (state) { this.isFlying = state; };
Walking.prototype.init = function (state) { this.isWalking = state; };
Being.prototype.init = function (state) { this.isMoving = state; };They all have it. One obvious consequence is that the function built with asSys will have the method, which comes form the last skill in the provided list:
var aFalcon = new (a$(Flying, Walking))();
aFalcon.init(false); // This will invoke `Waling.prototype.init()`.Which makes sense. What if, however, someone would like to invoke the methods that have been overridden? In the case of init(), it is quite natural to let other skills initialize the object as well. This is what a$.pass() function is for:
a$.pass(aFalcon, Flying, 'init', false);This method will invoke init() function of the first skill before Flying, that has it. Of course, with aFalcon as this. So, a skill doesn’t need to know where was it, in the initial call to a$(), nor need to be aware that other skills exist, or are part of this agent’s functionality—the only thing which is important is "Am I expected to let overridden with my name, still be executed?”.
A improved definition of the init() method would be:
Flying.prototype.init = function (state) {
this.isFlying = state;
a$.pass(this, Flying, 'init', state);
};
Walking.prototype.init = function (state) {
this.isWalking = state;
a$.pass(this, Walking, 'init', state);
};
Being.prototype.init = function (state) {
this.isMoving = state;
a$.pass(this, Being, 'init', state);
};Same type of functionality can be achieved manually using common extend functionality (found in jQuery, underscore, lodash, etc.), in a patter like this:
var a = _.extend({}, Flying.prototype, Walking.prototype);
Flying.call(a);
Walking.call(a);However, this routine need to be executed on each new entity allocation, which can be costly. Also, the memory usage will be higher, especially with large number of entities, because each of them will need to hold the references to the methods.
Therefore, asSys’s approach avoids assembling each agent on every instantiation, because the number of different combinations of skills is quite limited—it is (usually) manually coded as part of the system’s architecture. The number of agents, on the other side, could be quite large. Hence, the approach of constructing these dynamic functions and prototypes, which enables the actual object creation to be handled natively by the JavaScript engine.
The actual method invocation is no different, therefore I’ve conducted few types for entity allocation, and here are the results:
- The native, direct allocation from single function (i.e.
new SingleSkill()) is around 100 times faster than single-skill asSys-based allocation. There are good news here, however. - The manual allocation with two skills (as the example above) is ≈60% slower, than the corresponding asSys-based two-skill allocation.
- The manual allocation with four skills is nearly 4 times slower than the corresponding four skills asSys-based allocation.
- The number of skills in the asSys-based allocation doesn’t really influence the speed.
- In the browser, the results are almost the same, just that native, simple
newallocation is 10 times faster, than the single-skill asSys-allocation, not a 100.
First, it is important to note, that by allocation, I also mean invocation of the constructor, which in the case of many skills, means invocation of that many functions.
Second, it is important to clarify that all of the convenient methods of the library (group(), can(), capable(), etc.) work with natively built objects too, so it is not a problem to utilize the faster, native allocation for the cases of simple, single-skill agents/entities.
And third, the idea of this approach is to achieve higher granularity of feature-sets, and work on the ability to combine small, simple groups of features, rather than handling well behemoths. As a consequence, single-skill agents/entities are not very likely to be popular. At least, they shouldn’t.
Language changes... I think that this type of functionality will perfectly fit as part of the language itself, with very few changes, namely two:
- Ability to provide more than one constructor function the
newoperator, lilevar a = new [fnA, fnB, ...](). The syntax can be either array-like[], or custom (e.g.<>). - Altering
Object.prototype.instanceOf()function to be aware of that possibility and returntrueif any of the provided functions is given. - Introduction of
Object.prototype.getAllPrototypesOf()with the obvious behavior. - Introduction of new underlying class, with array-like behavior, which can handle entity grouping, and automatically provide the set method invocation.
And, such change will feel much more natural to JavaScript, than the continuous attempts to bring the class-ical, inheritance-based OOP paradigm in it.
Project image from icon8.
Copyright © 2016-2019, Ivan (Jonan) Georgiev
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.