There are two broad categories of software systems – interruptible and non-interruptible. The interruptible system offers high-level capabilities such as dynamic event handling, but does so at the cost of performance due to an impedance mismatch with the underlying commodity hardware. The non-interruptible system eschews such high-level capabilities to avoid their associated impedance mismatches in order to offer greater quantitative scalability. Which approach the working programmer should choose depends on whether he is solving a problem that imposes requirements relating to its qualitative or quantitative aspects.
This choice is not disambiguated purely based on the model category our programmer is trying to working in, either. Consider a game simulation where there exists both space marines, who are of high consequence to the state and outcome of the simulation, and ants in a massive ant colony, which are not. Both of these abstractions fall into the model category of simulants in a simulation which they all share. Space marines, being armed with giant bazookas and able to pick up keys that afford entry to new areas, have the potential to affect the simulation in the most profound ways and, given the hectic nature of space marine combat, at unpredictable times. Our humble ant, on the other hand, has no profound effect on the simulation – potentially no observable effect at all. The only way in which the ant’s presence dwarfs that of the space marine’s is in his massive numbers. Even if our lowly any were able to affect the simulation in some small way, it would be in a very predictable fashion, bounded to only a small number of effects easily enumerated by the programmer up front. As you’ve probably guessed, the space marine best falls into the category of the interruptible system whereas the ant best falls into the category of non-interruptible system. Like the space marine and the ant, it is a classic disparity between quality and quantity. To the author, all the world seems a war between these two opposites, and software systems are not excluded.
As is now known by many game developers, the latest innovation in the war for scalability is the entity-component-system (ECS) programming model. Entities are little more than an identifier and a collection of razor-thin ECS components associated with it. The ECS offers not just a possible light-weight representation of a simulant, but also a memory-access- and vectorization-friendly means of organizing its components. The ECS therefore make a lovely home for our masses of ants. After all, ants have such a muted effect on the world that their implementation need know very little – nor affect much of – the outside world.
The space marine, however, is the complementary case. Whereas ants might number in the 10s or 100s of thousands, space marines are likely to number in the dozens. The advantages of quantitative scalability of the ECS isn’t nearly as meaningful here. What’s more, the space marine is the main force of causality in our simulation, meaning that living inside the myopic constraints of an ECS poses increasingly-hard problems at the level of programmability. Sure, our programmer could attempt to sit down a graph out all possible causal sequences involved with the marine in order to appropriately chain the systems together, but that will not be an easy or stable method throughout the lifetime of development. Given that the thing that marines like to affect most of all is other marines (via explosive munitions or hails of bullets), circularity in our hand-crafted causal sequence is difficult to avoid when possible, and difficult to sequence where unavoidable. So why should the space marine be force-fitted inside an ECS system when he would be much more comfortable in the more classic event-based one? Why not accommodate both of these simulants equally by exposing one API for the interruptible, event-based system and another API for the non-interruptible, ECS-based system? In short, why not both?
This is what both Unity and Nu does, and the author suspects that embracing this duality is better than forcing every possible simulant into the new and cool but very constraining ECS model.