Entity Systems: what makes good Components? good Entities?

@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.

@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.

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 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.

@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.