Categories
entity systems games design programming

Entity Systems: what makes good Components? good Entities?

In the ongoing, epic comments (300+ and counting!) for my Entity Systems posts, one of the recurring questions is:

What makes a good Component?
How should I split my conceptual model into Entities and Components?
How should I split my algorithms and methods into Systems?

It’s often difficult to answer these questions without concrete examples, which are thin on the ground.

Good news, then…

Paul Gestwicki runs a CS315: Game Programming course, and last year his students used an Entity System to implement their game – Morgan’s Raid. In a recent email conversation, he mentioned he’d been monitoring the actual number – and nature – of the Components and Systems that the teams developed and used on the project.

He’s now posted this list, along with some brief analysis.

All systems and Components

Read Paul’s post – there are some caveats he mentions, and there’s a useful diagram showing roughly how many systems were using each component.

I strongly recommend you play the game too (it’s free, and quick to play) so you can get an idea straight away – just from the names – what data and code some of these contain.

To recap, here’s the list:

“For your reading convenience, here’s a simple tabular view of the systems and components

Systems Components
BackgroundTileSystem
CityNameSystem
DestinationSystem
FadingSystem
GPSToScreenSystem
HoverableSystem
ImageRenderingSystem
IntInterpolationSystem
MinimumSleepTimeSystem
MorganLocationSystem
NightRenderingSystem
OnClickMoveHereSystem
OnScreenBoundingBoxSystem
RaidSoundSystem
RailwaySystem
ReputationSystem
RevealingTextSystem
SpeedSystem
StepwisePositionInterpolationSystem
SunSystem
TimePassingSystem
TimeTriggeredSystem
TownArrivalSystem
TownArrowSystem
TownUnderSiegeSystem
AnimationRenderable
ArrivesAtTownIndex
BackgroundTile
BeenRaided
CentersOnGPS
CityData
CityImages
CityName
CityPopulation
CityTargets
CommandPoint
Destination
DoesCityHaveMilitia
DoesCityLoseGame
DoesCityWinGame
GPSPosition
GPSPositionList
HasMorganGPS
Hoverable
ImageRenderable
ImageRenderLayer
InGameTime
IntInterpolated
MinimumSleepTimeOverride
Morgan
MorganLocation
MovesOnClick
OnClickMoveHere
OnScreenBoundingBox
OnScreenBoundingBoxList
PositionInterpolated
Raidable
Raider
Railway
Reputation
ReputationValue
RevealingText
Road
RoadsToCity
RouteTaken
Speed
Sun
Terrain
TimeToRaid
TimeTriggeredEvent
TownAdjacency
TownArrow
TownUnderSeige

Things I noticed straight away:

  1. There’s approximately 2:1 ratio of “components” to “systems”
  2. In Paul’s post, all the Systems are accessing *something*
  3. In Paul’s post, quite a few Components are NOT accessed
  4. A couple of components are used by almost every System
  5. The names of some Systems suggest they’re very trivial – perhaps only a dozen lines of effective code
  6. The names of some Components suggest they’re being designed in an OOP hierarchy

NB: I haven’t had time to look at the source code, but it’s freely downloadable here, so I’d recommend having a look if you have time.

How many Components per System?

I’ve generally started people off with: “aim for 1:1 ratio”. This is mainly to kick them out of the traditional class-based OOP mindset. In practice, there’s really no need to stick to that religiously – once you get the hang of ES design, you should be freely adding and subtracting components all over the place.

In reality, the pressures on “number of systems” and “number of components” are independent. Ideally, you add a new system when you have a major new concept to add to your game – e.g. “previously I was using hand-made jumping, now I want to add a complete physics-driven approach. This will mean changing collision-detection, changing the core game-loop, etc”.

Ideally, you add a new component when you have a new “dimension” to the game objects. For instance, if you’re adding a physics System, you may not need to add any new Components – it might be that all you need is Location (containing x,y,x position and dx,dy,dz velocity) and RenderState (containing screen-pixels x,y) – and that you already have those components.

Zero systems per component

One of the advantages of an ES is that old code can just fall off the radar and disappear. So I’m not surprised at all to see some components that appear to be unused – and it’s MUCH easier to simply delete this code from your project than it would be on a traditional OOP project. Does anything reference that data? If so, it’s a set of particular systems. For each system, you can look at MERELY the system and the component, and make a very quick decision about whether you still need this access – or if you can refactor to move (some of) it somewhere else. The amount of code you need to read to make such decisions safely is typically very small – i.e. easy, quick, and less error-prone.

Many systems per component

This is fine. However, it can also be an early-warning sign of a design or code-architecture bug. Sometimes, there are components that – innately – are just needed all over the place. For instance, in a team-based game, the component saying which “team” a given object/player/item/building belongs to is likely to affect almost every piece of algorithm code across the board. It’ll be referenced by many systems.

On the flip-side, it may be a sign that you’ve put too much data into one component. There are two usual versions of this:

  1. You have – say – 8 variables in the struct where you should instead have two structs (components), one with 5 variables, the other with 3.
  2. You have – say – 4 variables in the struct, but different systems are using those variables to mean different things. It works OK for now, but it’s very fragile – as soon as the different meanings diverge even a little, your code is going to start breaking

Of course, you get this exact problem in traditional OOP setups, but with an ES it’s trivial to fix. Split – or duplicate – the Component, change a few references in the Systems, and you’re done. If it turns out a week later that the split wasn’t necessary – or worse, was a step backwards (e.g. you find yourself frequently synching the data between those components) – it’s extremely cheap to swap it back.

By contrast, with OOP, this is a nightmare scenario, because you have to worry about every method on the original class. Does that method:

  1. Need to exist on both the new classes, or just one?
  2. Work correctly for the new class it will be on – or does it currently rely on some of the data (and shoudln’t) and will need to be re-written?
  3. Get used by other parts of the codebase in ways that will break if/when you split the class?

Thoughts, Suggestions?

…this is just a lightning quick analysis, but I strongly invite you to do you own digging into the classes – and the codebase – and come up with your own thoughts and feedback. We have here a convenient, real-life, list of components/systems – something to dig our teeth into, and debate the rights and wrongs of each decision. And I’m sure the students involved on the project would be interested in your feedback on their approaches :)

Did this post help you?

Support me on Patreon, writing about Entity Systems and sharing tech demos and code examples

64 replies on “Entity Systems: what makes good Components? good Entities?”

Synching component sounds very much like a Bad Code Smell, but – it depends on the kind of “synching”.

One kind that is common is aggregators. The equivalent of “recursive algorithms implemented using tail recursion”. These are where your component by its nature cant be directly updated – but you can write an algorithm that updates it at the end of each frame (using lots of input data).

So … one system does all the work of updating all the entities at the end of the frame, sticks the result into a component, and … at start of next frame, all the other systems make use of the resulting data.

e.g. it’s one way to deal with collision detection: do the CD calculation, stick the provisional results into a component, and allow other systems to process the collided-objects and decide whether to allow the collision (maybe destroying an object in the process), or whether to forbid it (by reversing the position of one o the objects).

@Luke

I’ll take a stab here…

> Is there a design process you follow when thinking about them, certain questions you ask yourself about each aspect of the game?

In regard to components a good idea at times is to stuff as much data into a single component that covers the complete purpose. This cuts down referencing multiple components over and over and there is definitely a speed up in a tight loop. A good example of this is physics where in my efforts I provide a default “KinematicsParams” component that has velocity, position, rotation, angular velocity, angular rotation, etc. etc. all stuffed into one data component. The reason being is that instead of referencing a single component for each parameter it’s much easier / quicker to reference one.

So, in general it makes sense to try and combine as much data into a single component for a given game subsystem or group of systems that may process it.

Regarding designing systems. Well, this is where particular quirks or design decisions of the various entity system (ES) frameworks out there may differ on what is possible. For instance I recently checked out Artemis again and I’m not too thrilled about the “Aspect” implementation. It really forces one particular style and way of writing systems and interfacing with entities. IE it bakes what I consider higher level functionality into the core framework. It forces access to entities in a serial fashion as well. If you are using Artemis then you’d kind of have to play along to this particular framing.

With Adam’s reference ES implementation things are pretty simple. (Adam) You’ll have to correct me, but I believe things still work by only being able to retrieve / set single components right? The same is the case w/ Artemis, again I could stand corrected. If this is still the case if one wants to hold a collection of components then one has to make a data component which explicitly has a collection. If I recall there is no way to store multiple components by type or implicitly retrieve a collection or iterator over a generically stored collection of components in an entity.

These essential ES framework design decisions majorly affect how one creates and works with system components. So, one must consider that in designing systems the given ES framework may impose some design constraints.

In my efforts with my own ES framework implementation one can generically store a collection of components by type and retrieve an iterator generically as well. This opens up a very powerful system oriented design pattern which is “extension by iteration”. I’m pretty sure given the length of comments in Adam’s ES posts I have brought this up before. It seems some other posts touch on it and will be more detailed via the two top links from Google for:
“extension by iteration” entity system

The basic old OOP example of say major subsystems having an “update()” method can be applied with entity systems… The “brain dead” example follows below and as things go uses some of the API methods from my efforts:

for (Iterator iter = entity.getAsIterator(SYSTEM, IRuntimeSystem.class); iter.hasNext();)
{
iter.next().update();
}

One can directly store systems by direct type (say CollisionSystem.class), but also add the same systems that implement IRuntimeSystem interface to that typed collection, IE MovementSystem, “LifeOrDeathSystem”, etc.

Again this is more of a “brain dead” example as ideally you don’t want to process each entity running a series of systems that update in order to completion for each entity. Instead you want to run systems across all data components of a collection of entities which is more of a data oriented design approach. This gets more detailed for this blog comment, but one of those links above from the Google search should land on a page where I chat about this approach.

Consider a component manager though that is implementing or extending an abstract or defined base class. Instead of overwriting / extending functionality via inheritance a similar basic for loop can iterate over a set of system components that implement a given methods extended logic. Yah.. sucks w/ no code example, but check the links from above Google search.

>I had a system that was simply syncing data between certain (like two) components. Is the idea of a component sync system a bad idea

As Adam mentioned this does seem like a bad code smell of sorts. Simple syncing shouldn’t be necessary for single threaded use cases or when all the systems have visibility to the particular data component. Adam, mentioned per frame aggregate processing of data then storing the results for processing by systems the next frame, but that also is different than simple syncing.

Quite likely it’s not necessary or you’d have to describe the problem you are trying to solve in more detail.

Thankyou both Adam and Mike.

I have been working on here and there when I can and feel like im getting my head around things. I no longer have a syncing of data between two of my components :D.

I would like to ask your thoughts on another item. What are the thoughts about having components that dont have any data, but instead exists to label a entity in a way. like having an empty Player component and any entity that has that component is the player controlled character??

Thanks again..

_L

@Adam: Saw you had some server / DB problems.. Looks like my last post got dropped unless for some reason it’s waiting mod.. Just delete this if a dupe.

@Luke
>What are the thoughts about having components that dont have any data, but instead exists to label a entity in a way.

I’m all for it. If you are using Java there is a great trick for this and it has many other uses too.. Extensible enums are the bomb. I’ve mentioned them before in the copious comments on Adam’s blog.

Essentially you can create an extensible enum data component. An extensible enum is an Enum class that extends an interface. In my entity system implementation I define an interface IEntityType that also extends the data component interface. You can then easily store an enum as a data component.

I actually yap a bit about the component oriented refactor I’m doing regarding entity management with my efforts at this G+ post below:
https://plus.google.com/u/0/117904596907381647757/posts/1Mv94QeFCU3

Here is a snippet from the 2nd comment which has a little code showing how I store an extensible enum data component that is an “IEntityType” marker:
—————-

The marker extensible enum data component set in an Entity, which is a ComponentManager, is just a quick way to index entities. It’s super simple…

// IEntityType below extends other specific extensible enums making
// it also a data component

public enum MonsterTypes implements IEntityType
{
CYCLOPS, TROLL, TROGLODYTE;

// plus a little more boiler plate code to fulfill component interface
// implementation.
}

// setting just like any component instead we can set an enum
entity.set(DATA, IEntityType.class, MonsterTypes.CYCLOPS);

// retrieving the marker data component
IEntityType type = entity.getAs(DATA, IEntityType.class);

type is MonsterTypes.CYCLOPS.. IE you can do this:

if (type == MonsterTypes.CYCLOPS) {}

—————-

You can create many more Enum classes that simply extend “IEntityType” even across source code modules and be able to generically retrieve a type marker as a data component in my efforts.

I haven’t tried this in say C#, but for Java I highly recommend checking out extensible enums. There is a little bit mentioned in one of Josh Bloch’s books titled Effective Java, but he stops short in realizing the true power of extensible enums.

Server upgrade that went slightly wrong – I picked up the “this morning” backups instead of the “right now” ones, sorry.

Hi Guys, I posted this on another ES related post (the one announcing the new RBMS Beta I think, I will also post it here in the hope someone sees it)

==========================================

Hi again..

firstly, if this question has already been asked/answered in one of the thousands of other comments across the 9 or so articles pertaining to this topic, I do apologise. I did my best to scan through the comments to find something sounding like my question below but nothing jumped out…

secondly, thanks again everyone for answering my queries on the other forum posts, the information was very helpful. I have been continuing my efforts in developing a simple ES in between work, wedding prep and the other random small projects I was somehow drawn into.. I am still using asteroids as my target (just want to make a simple clone of the classic game).

My question today comes out of my thoughts/concerns about how to handle changing game states, as well as changes in key meaning for each state..

for example, I want my Asteroids game to have 3 states:
– Start Screen (with asteroids flying around behind text), can start a game by pressing ‘Enter/Return’
– Game Proper/In Game (self explanatory, w,a,d movement, space shoot, shift to ‘hyperjump’ esc to pause game)
– Pause Screen (stop simulation updates, render the game proper in background, darken the screen, esc to return to game, q to quit).

Once I knew what I wanted I found I was at a loss for how to implement it.. (Full disclosure, this is my first ever attempt at making a game). My first reaction was too:
– Have one EntityManager
– Have a GameStateManager which would manage a stack of game states
– Have a GameState class, each game state would hold a ref to the EntityManager for the game, and have a collection of Systems to execute when that game state is active..
– Have different types of InputSystem (GameProperInputSystem, GamePausedInputSystem) and add them to the correct GameState, this way each Input System would interpret the state of the keyboard the right way for the given state… When one of the input systems detects the user wished to change the state (such as Pause Game), return a special code back up to the game state manager so it can push/pop to the right game state..

Great I thought, lets make it happen, but then I started to wonder, should I have split the ‘GameState’ concept out into classes like I did, or should I:
– Add the ability to turn on and off systems so that the state the game is in be represented by a combination of the data in the components and which Systems are active at a given time??
– Stick to having one system that handles input for the game but have the keyboard input run through a filter/context for the current state of the game and turn keystates into intentions for interpretation…

Im sorry if that didn’t make much sense, this issue has got my wondering about the best way to handle game states / changes in input meaning within an ES.. I found myself questioning the purpose of the ES, was It just one part of the game code, existing alongside other OO constructs or am I attempting to implement the entire game (objects, UI, network etc) within the ES paradigm.

Peoples thoughts/ideas would be very much appreciated.

Thanks in advance

_L

I did read articles one through four (skimmed five) . My comments were not a critique of the information you were so gracious to share, rather of entity systems in general. Have you ever read 1984? Renaming something doesn’t change what it is. Crosscutting code is still spaghetti code; an entity system fits within the abstract notion of the client server model. I’m blown away by the absence of reference to such a longstanding, proven system and its research. I find it sad to see (what i interpret as) programmers being denied potentially helpful resources and techniques due to Orwellian newspeak.

Why don’t you explain WHY and HOW you believe the two things are the same?

Here’s my starting position:

1. I have several books that describe the Client/Server paradigm, and there’s nothing even vaguely similar to an ES in there
2. ES’s specifically solve problems to do with OOP; since Client/Server was invented 10-20 years before OOP was invented, it would be rather surprising if it included ES’s.

So far, all you’ve done is say “[absurd thing] is true because I say so”, and to cast insults. It’s very difficult to take you seriously if you won’t engage, and fail to provide anything remotely constructive or evidential.

What I am pushing for is flexibility in our view of entity systems in order to broaden implementation choices, and descriptors for subsystems that are more likely to lead newer programmers to existing solutions.

Object oriented programming has become increasingly dominant over the last few decades. You acknowledge the core entity system is not an object oriented solution, so it shouldn’t be suprising that one might need to go back a decade or two to find an analogue solution.

The following is my opinion on how an entity system should be considered, followed by a few reasons why, and a resource I believe is relevant.

Entity system:
The core system is comprised of a client server coupled with a memory abstraction layer. The major design goal is a high degree of modularity in the addition of services and composition of clients.

Client server:
The client server is conceptually a relationship that specifies a seperation of responsibilities, and is consistent with the client server model as outlined in the component object model. It is this framework that provides for the easy and unobtrusive addition of services.

Key ideas from the component object model:
1) A client is any entity that uses the services of a component object.
2) The location or layout of data within the system is irrelevant.

Memory abstraction layer:
The memory abstraction layer is responsible for virtualizing client objects. It accomplishes this by avoiding the direct use of memory references to clients and their constituent elements. A system may use multiple layers.

Data layout:
At one point in the article, you give five examples that demonstrate the differences in opinion on what exactly constitutes an entity system. The main argument is over data layout. When data layout is no longer used as a qualifier, suddenly they’re all entity systems.
(Yes, even the one whose client classes contain member functions – I would argue – since those methods are only invoked by the server, they are extensions of the server, and I can’t think of a good reason to disallow extendable servers.)
You may not agree that data layout is irrelevant, but I believe – the fact you were able to sidestep the question “where does the data live?” and still discuss entity systems in depth supports the claim.

Terms:
Why insist on the terms client server model and memory abstraction layer? The reason is, they lead to richer resources than the inconsistent and ad hoc names that are currently being used to describe these systems.
The core system is implemented using component oriented programming. A search for COP coupled with client server will quckly lead to COM. In this environment I can’t think of a better resource than COM (and by extension the .NET framework) to use as a model for providing dynamic services.
Memory abstraction leads to virtual memory managment, which covers exactly the kinds of techniques you’ll need to implement this system well. Think about what the use of identifiers (GUIDs) does at the lowest level. It virtualizes memory. It enables the system to hand a singular entity to the user, while behind the scenes its individual components (aspects) may be scattered all over the system. This isn’t any different than what your operating system’s virtual memory manager does when it hands memory to a process. To the process it looks like a contiguous block of memory, but the physical layout may be a patchwork of memory, even residing on the hard drive or somewhere offsite.

Supporting code:
This is where things get heavy. Questions being asked in this forum include – memory management, scheduling, inter-process (module) communication, event handling, streams, optimization issues.
If only there were an existing layered, client server architecture with similar design goals and systems…
Good news, there is.
In fact if we eliminate purpose (game development), what we are describing is very similar to micro-kernel operating system architecture.

MINIX:
The MINIX operating system is an open source project that has been used in academia forever. The source code is up to date and free to download. Documentation is plentiful. A full treatment of all systems, design decisions, advice, and ideas for future research may be found in books by the original author of MINIX, Andrew S. Tanenbaum.

I hope this resource keeps at least one person from shooting in the dark and reinventing wheels.

>I hope this resource keeps at least one person from shooting in the dark and reinventing wheels.

Except what you brought up really has not much to do with Entity Systems (ES) in the context of these blog posts or at least in my efforts with my own ES / Java work. First off ES is an _in process_ mechanism and has nothing to do with client / server associations. Technically an ES as implemented in Java is still OOP, but not traditional OOP ala a focus on inheritance / explicit composition and strong encapsulation mixing data / logic with an unchecked amount of mutator methods. ES focus on the _implicit has-a_ relationship by providing an API vs built in language constructs at least for Java. A second pillar that may or may not be adopted is supporting indirect message passing vs more traditional OOP methods such as the Observer / Listener pattern. Indirect messaging is not mandatory for an ES, but solves a lot of general problems over direct indexing of components / systems / tight coupling.

In many ways indirect message passing and the implicit has-a relationship are much closer to what language pioneers like Alan Kay had in mind for OOP, before it got derailed toward what we call “traditional OOP”. The distinction against traditional OOP in regarding to ES is enough for us to generally call it “COP – component oriented programming”.

One can of course still apply client / server development with an ES like API on each side potentially, but that doesn’t mean an ES has anything to do with client / server programming in general. It also has little to do with COM / DCOM of years past except that there is a query mechanism, but it functions drastically differently at least the Java implementations of ES concepts do. Also not all ES rely on a GUID approach as a central implementation detail. Adam’s demo code does, but my efforts don’t.

The MINIX OS also has little relevance to ES proper.

I suppose of minor note that Adam and I don’t always agree on terminology or implementation and such, but as things go I can chime in and say you are barking up the wrong tree.

>… Adam and I don’t always agree on terminology and implementation…

The point is to focus on similarities across ES definitions and implementations (not necessarily agree with my synopsis). What do you and Adam agree on? What – in most basic terms – qualifies as an entity system in your opinion?

I personally feel the language issues are distracting. Of course a Java implementation is object oriented, Java enforces an OOP framework. This is unfortunate (in the context of ES), because it seems to require a good deal of creativity to circumvent language restrictions.

It also seems that (many, not all) Java programmers view OOP as something more concrete than it actually is. OOP, COP are nothing more than methods used to establish order in a system, and are concepts that transcend language. One could use COP to impose a “traditional OOP” inheritance hierarchy. In my view, the client/server relationship isn’t any different than child/parent or sub/super class relationships. The difference is, client/server relationships aren’t enforced (so you have more freedom to create a tangled mess if you like).

The mention of GUID’s was given with respect to Adam’s article. The key concept is abstraction – “Avoiding the direct use of memory references.” is intentionally vague – how exactly this is accomplished doesn’t matter.

If anyone is expecting to “cut & paste” MINIX source code (or even repurpose most of it), they will be disappointed. What they will find are implementation ideas for a “similar” substantial system (that will at least set them on a path for further research).

The use of “similar” is imprecise. To clarify – the usage here is inline with that of George Polya in his book, How to solve It: A New Aspect of Mathematical Method.
According to Polya, one of the first things someone should do once the problem is understood, is look for existing solutions to similar or related problems. This may involve viewing the problem differently, breaking a problem into sub-problems, even modifying the problem to fit an existing solution.

So no, MINIX is not an ES, but I believe it’s architecture and systems are sufficently similar to make it a useful reference.

@SugarRichard
*”What – in most basic terms – qualifies as an entity system in your opinion?”

A focus on implicit composition / the implicit has-a relationship as the central organization method is the key to component oriented programming and an ES may be considered an implementation of such an approach.

*”Of course a Java implementation is object oriented, Java enforces an OOP framework. This is unfortunate (in the context of ES), because it seems to require a good deal of creativity to circumvent language restrictions.”

*”OOP, COP are nothing more than methods used to establish order in a system, and are concepts that transcend language.”

While Java is traditionally OOP aligned in what the language allows in regard to architecture it was Java 1.5 / 5 that opened the door with generics. In particular generic methods. Advanced use of generics isn’t something that hit mainstream Java development per se outside of maybe adding typed collections to ones everyday usage.

Dynamic and functional languages are more suited out of the box for component oriented programming and even allow more exotic typing aspects like duck typing. However, the nice thing about Java is that it is strongly typed and one can get the best of a functional _like_ situation via COP techniques. I also prefer the superior IDE support which comes with a strongly typed language.

A specific API that is implemented by generic methods is how one creates a component architecture / ES with Java. While everything still is an Object the COP API allows one to break away from structuring ones code via traditional OOP.

*” One could use COP to impose a “traditional OOP” inheritance hierarchy.”

Except without the inheritance and explicit composition; the corner stones of traditional OOP.

The most common way of structuring an inheritance _like_ operation with COP is “(implicit) extension by iteration”. This however is not a 1:1 direct replacement or the same thing as inheritance.

*” In my view, the client/server relationship isn’t any different than child/parent or sub/super class relationships.”

Not really unless one is taking an extremely loose view as in a whatever goes mentality. IE these two different architecture models have relationships between each other therefore they are equal… Nope…

*”The key concept is abstraction – “Avoiding the direct use of memory references.” is intentionally vague – how exactly this is accomplished doesn’t matter.”

Yes, the key is implicit composition which is a particular type of abstraction usually involves a query interface of some sort whether a GUID or in the case of the COP API I’ve made and other ES implementations in Java a query interface that is strongly typed via Class references.

*”So no, MINIX is not an ES, but I believe it’s architecture and systems are sufficently similar to make it a useful reference.”

In a loose manner to some respect yes, but only insofar that MINIX is a microkernal architecture, IE based on component architecture techniques.

An ES as implemented in Adam’s efforts and other reference implementations such as Artemis do tightly tie the component architecture aspects to a specific more game-centric context.

You might have seen me advocate strongly to make the component architecture implementation a superset of an ES because it is very useful for many other purposes beyond a game context.

In that regard MINIX has more similarities to my larger work with TyphonRT which provides a stable middleware runtime across diverse hardware and OS versions. My efforts also do contain a specific ES implementation, but it is based on a generalized component architecture vs a game-centric implementation.

—–

I do believe the client / server comparison is where things got derailed in the discussion. Component architectures have been around for a while. They can be implemented in traditional OOP, but implicit composition or the preferred way of pulling them off in Java especially for ES requires generic methods.

Comments are closed.