My flippant comment was assuming that you chose a deterministic naming scheme for your components, so that e.g. for component “Position” you knew (without having to look it up) that the table name would be “CPosition” (or maybe “Component_Position” or whatever).

Component-class names are going to be unique anyway (whether you “name” them with strings, or with integers, or some other scheme) – so you should in theory be able to invent a DB schema that avoids looking up the table-name for each component.

I have a work in progress ES based off of what I learned from your article. I am trying to make a function that loads an entity from the database including all its component data. My question is, can you give an example of how to do this with the least number of queries?

I have a table for each component’s data, with the table name being in the “component” table. Right now I have it so it does one query to get a list of the component IDs and their table names, and then it does a query for each component table to get all the data.

and i have other more questions:
1.how to reuse the assemblage?
2.how to reuse the components as we want to make one new component with the old one?

Think of an entity as a dictionary of arrays (each array being a component). In most programming languages, implemented efficiently, that’s all it is.

A dictionary doesn’t “interact” with anything, it just sits there. You write other code that gets given refecnes to multiple dictionaries, and operates upon them. Your “other code” is the System(s). The entities just sit there, doing nothing.

These systems always look so elegant on paper, but I’ve always struggled with the implementation. I’ll take the simple approach and see what I come up with :)

“I’m thinking too much”

Don’t. There is no such difference. Entities are just data. Nothing more. There is no “do something” part to an entity. You are thinking of OOP. Stop thinking of OOP. ES’s want your life to be simpler … don’t complicate matters, just let them be as simple as they possibly can be :).

Off the top of my head, I’d start with:
– entity, made up of:
– position component
– one-use-special-action component, with an enum type with value of “HEAL_POTION”
– inventory component (as in: when it’s in your inventory, it has a component that gives a bitmap you can display, and says how much inventory space it takes up, is it stackable, etc)

Although, in some RPG’s, the potions design is quite complex, so you might well choose to split-out the “potion” bit into mulitple components, e.g. a single “item-use” component, speciying that it’s “one-use” and has “instant-effect” PLUS a set of “item-effect-component” instances:
– alter-stats component, with values “HEALTH” and “50″
– alter-stats componeont, with values “STAMINA-PERCENT” and “100″
– alter-stats-temporary componeont, with values “MAX-HEALTH” and “10″ and a variable “Fade-time” of value “60 seconds”
– …etc

(As much as is necessary to make the implementation of YOUR game’s particular potions-logic easier to manage…)

In an RPG, that split of components also starts to make it REALLY easy to create – say – a new magic sword that has a side effect of increaing your max-health; it’s actually re-using the componone from a heal potion.

In the scope of an RPG, how would things like items be handled? For example, if we have a potion that restores health, is this an entity, or an assemblage that is instantiated when a character picks it up? I think it’s the latter, but I’m still not sure.

I imagine when the game loads its content, it would load a list of definitions for various items, and then create them as required. So a character would have an InventoryComponent object that would just list the ID of any object entities.

Basically, I think I’m having difficulty visualing the line between entities that do something (monsters, treasure chests, event trigger zones) and entities that describe something (like potions, swords etc).

I think I answered my own question, but any advice would be very welcome.

Im not convinced ES and Event driven systems go.well together for”normal” situations.. e.g. They could work extremely parallel (both approaches are.inherently parallelisable), but few people have enough processors to make that worthwhile these days.

Out of interest, why are you doing both together? Where is it working? Where is it causing yiu headaches?

We’re also trying to work out efficient ways of messaging the entities as they need to react to changes. We have hundreds of thousands of objects so we need to be careful.

Thank you for your thoughts.
.

NEVER write-through live data to an SQL db, it’s generally far too slow. Instead, send it to an in-memory SQL db of some kind (there’s many available, from free to commercial). They work very well as an “intelligent cache that speaks SQL directly, and avoids you having to re-write you code to speak to the cache instead of speaknig SQL”.

If the in-memory DB”s you can afford are still too slow, get hold of an even more lightweight/minimal SQL implementation (or roil your own), and again run it purely in memory. Or try running it off a RAMDISK, and setup your “real” db as a replication slave or similar.

In general, the db features you need to run the data live are a small subset of the db features you need on the persistent copy of the data. There’s no reason why you have to run the same DB server (or even same DB vendor!) for the two different copies…

We are able to load all the entities and populate the objects in memory by using projections. This all works great and is fairly efficient in terms of the queries involved (one per component table).

The tricky part, and the area I need some help with, is how to persist the data as it changes during the running of the game loop. For example, we have about 100,000 location components with x, y, z coordinates that are being updated once every ten seconds. Trying to save this data back to SQL Server is painfully slow. Serializing to disk is fast but has problems when you want to change the structure or perform maintenance on the data.

How are people handling persistence?

Has anyone used any of the main memory databases for their objects?

Thanks,

Rick

Thanks again.. both article and following discussions everyone.

for eg – A simple game with 3 subsystems called renderer, physicsSim and input. The game has 2 entities floating about. Both entities have a physics component, a renderable component and input component set up in the database.

The work the subsystems do is just the renderer just renders the renderable components, the physics just simulates the physics components and the input just updates the input components with the state of input. But where is the part that the input subsystem has to tell the physics system to apply forces based on input or the physics system to tell the renderer the transform to render at.

Is it ok to do a querry in the renderer to look for a physics component with the given entity id to get the transform to render at, if so I cant see the benefit and think this will cause threading issues or am I just still thinking in the wrong way to solve this problem?

Many thanks and I look forward to the next article.

The facetious answer would be “use structs”.

My preferred approach is passing around big streams of byte data, and using a single instance of a (pertinent) struct to view that data one record-at-a-time from the OOP code. This allows for query-system-friendly “ask for everything you need at once, then slam it down the pipe in a single batch of bytes” … while also providing sane access semantics.

I tried googling for a link to a technique for a more comprehensive answer, and then found that the terminology I’ve been using for ten years apparently doesn’t exist. I’ll get back to you on that one :(.

When we cross over to our application code, typically in an OO language, the component data is the point at which your entity model loses its generic one-size-fits-all structure. Whilst the core entities and components remain 100% dynamic, is there a point at which we transition to a more static data model, in particular for ComponentData?

I would expect code within a GunComponent to be able to call…

if (data.GunRate > 1000) {

… or …

data.GunName = “Colt”

… accessing the data via strongly typed accessors rather than a bag of string data. Perpetual casting and parsing of string data would otherwise cause a hefty performance hit.

This is a general question, but inspired by the following line from your most excellent (dude) article:

float[] gunData = getComponentDataForEntity( GUN_COMPONENT, new_id );

^ So does getComponentDataForEntity always return a float array?

Ideally, as many systems as possible. That makes each system as small as possible, and as easy to edit + maintain + improve as possible.

…but use discretion, obviously.

In the end, *depending upon hardware/OS*, additional systems carry little overhead. At some point, adding X additional systems adds signficant overhead as the cost of iterating over “all entities” N+X times rather than N times becomes significant.

Generally, though, it’s not something to worry about: just have lots of systems now, and merge them later as/when necessary.

NB: one system certainly *can* act on multiple components, in fact most systems *must* act on components from other systems, although often only in a “read only” capacity.

(e.g. the rendering system needs to read the world-co-ords for each object, and add that to the local-co-ords for each polygon, in order to render everything in the right place on screen :). The world-co-ords are being maintained by another system, one to do with movement, but the polygon co-ords are being maintained by the rendering system. Or the animatin system, if that’s a separate system (which it probably is))

Beneath all the other reasons for using an ES, the core reason is simply “to do things in an OOP environment that we cannot otherwise do” – so Java and AS3 in no way undermine usage of an ES.

Well … except that without access to C/C++ structs, it’s hard to do the “streaming” part fast. Various people have reproduced structs in Java (it’s only mildly tricky), and it works fine now that java has direct (low-level) access to RAM. I have no idea what equivalents are available in AS3 today. You could still use an ES without that, it’s just that *some* of the performance improvements would no longer work.

re: mobile…

I’ve been concentrating on “big” platforms because … well, actually … I’ve been concentrating on “multiprocessor” platforms, where (generally speaking) you want to do as much data-driven programming as you can, and where some of the side-effects of ES’s have no negative side-effect on performance (because they’re “multiprocessor friendly”).

Again, there’s no particular reason to focus on those platforms: I got started with ES’s purely for the improvements they bring to the implementation of game-logic. That’s universal.

But I always intended to veer these blog posts towards “not ONLY are ES’s a better way to code, BUT ALSO they give you higher performance (in certain types of game)” – hence the title ;). A lot of techniques in game development make development easier/faster, but slow down the runtime game a lot. It’s nice to occasionally find some that are easier AND improve performance.

(NB: that’s not the only reason for the title)

I’ve read and enjoyed all of the previous posts on Entity Systems (including yours), and they all seem to be targeted towards end-users / clients that run ON fast hardware, e.g. PS3, or gaming PCs running games coded in C/C++.

I know very little about the Cell Architecture, except that it is much faster than a PC, and probably an order of magnitude faster than a mobile device (like the iPhone). So my question is, what do you suggest for slower devices/platforms; mobile, flash, java?

For instance, flash isn’t multithreaded…would you simulate threads for the Systems? Also, forgive my naivete, but don’t languages like Java and AS3 *force* OOP?

Sure… But… That means closing the door on a lot of nice/essential things….

Side-effect free
Trivially (and automatically!) parallelizable
Trivially (and automatically!) cacheable
No more dupe bugs

What’s not to love? ;)

“data analysis on the entity system through tools, that’s precisely the same analysis model as e.g. binary blobs. Except that binary blobs are ridiculously fast to store and load compared to an entity system, require much less database hardware, and so on.”

You’ve lost me here. Maybe I’m thinking of a slightly different concept when you say “binary blobs”, because the blobs I’m used to do not exhibit the features you describe.

Firstly, access:

A. ES’s provide direct access – and direct cross-entity joins – to all data.

B. Blobs literally *prevent* direct access – and all cross-entity joins.

The data analysis you can do offline on ES’s can also be done online – and it requires zero setup. To do the same analysis on blobs requires vast amounts of pre-processing (counted in hours or days to convert from the blobs into a usable format)

The inability to join across entities/game-objects is the main reason I would avoid blobs here – IMHO it’s like cutting both your DBMS’s arms off, blinding it, and then asking it to carry a cup of water without spilling a drop.

Secondly, speed:

If you have a crap DBMS, with poor locking (e.g. MySQL about 10 years ago), then yes – blobs significantly increase write speed by circumventing lock-management / consistency maintenance (at the expense that you’re not allowed any strong references between objects; ouch – that causes more performance problems elsewhere). But if you’ve got a good DBMS, circa 2009, that shouldn’t be the case.

You get some minor speed increases because you don’t have to do any CPU work. But you also get some minor speed decreases because you have to send vastly more data than you actually wanted / needed – and you cannot start processing on the received data until you’ve received the lot (unless you want to write some clever code to change your entire semantics of accessing data in RAM).

So … where am I going wrong here? Have there been some big changes in blobs in recent years that passed me by? (oops)

“I also believe that if you really know what you’re doing, and you can find a robust enough language, and you coudl find qualified programmers, you’d write everything on the server in a functional language.”

Would be nice if you could elaborate on that… One of these days when you get the time.
I think one of the main challenges of that is the use of external libraries and frameworks; F# should be faring better than erlang in that matter for instance… But most of the great frameworks one could use for an MMO backend I could think of are either exclusive or available on the java platform… Is there a solid functional language running on the Java platform?

@Jason

I have no problem with a single process having everything – but it never needs it all at once. It only needs it sequentially – bringing me back to: when would you ever need all that data at once? (other than for data-dumps to go to a foreign system – offsite backup, etc)

[actuallly, I do have a problem with monolithic processes – unless it’s got a decent built-in scheduler and built-in threading system, and is micro-managing a load of mini-processes, which would be fine by me. But at that point I’d still like to know what was so wrong with the various OSS and commercial scheduling systems that you felt “I can do better; writing a multi-threaded OS ain’t so hard”; are the alternatives unusable?)

Yes – sorry about that – I meant:

- EITHER: you’re already using it, or have used it, and at least know how to use it (most people)
- OR: you’re not using it – but that’s because you’re not using ANYTHING yet, you haven’t got that far (you probably WILL end up using it, and if you’re this new to MMO’s, you really SHOULD use it)

For the record: Alternative persistence backends are a lovely idea and I’m all for them.

OTOH … at AGDC, on our panel, Marty was claiming that only map/reduce was worth using, because “every other DB backend is too slow at writes” … and my response was twofold:

1. Use more functional code
2. Use Entity Systems

I believe you can make a lot of better-known techs (like OOP and SQL) work “well enough” if you modify them by using an ES. I also believe that if you really know what you’re doing, and you can find a robust enough language, and you coudl find qualified programmers, you’d write everything on the server in a functional language. But I also consider that totally unrealistic for 99% of us.

(if anyone tries it, let me know – I’ll be cheering for you, but don’t ask me to *bet* on you ;))

Should we? Don’t you think it depends on how one wants to store and navigate one’s data? SQL/relational isn’t the golden hammer. I wouldn’t dismiss other storage/databases solutions (object, map/reduce inspired systems), especially for a game object entity system before thinking about a game’s specificity.

Just because there is a world simulation process doesn’t mean that the individual game systems within that process aren’t largely independent, and only work with a subset of entity components. For example, the movement system should (ideally) only need to know about an entity’s physics model – collision geometry, position/orientation, velocity, etc. But, if you have decided to distribute the server load based on geography (e.g. one server handles all processing for a portion of the world), you still end up with a process that needs the whole entity.

And, as Matt pointed out, those crazy game designers have ways of creating systems that do require access to numerous components. Combat systems, in particular, tend to grow in that direction. (For this reason, I’d argue, using geographical distribution is still the “best” way to spread the load on the server…but that is a whole other discussion.)

It is, in my opinion, a matter of designing the architecture of the game to fit the designers’ and players’ vision as much as possible, rather than restricting the vision to what architecture you have. The latter certainly comes into play quite a bit, but I think our job as programmers is to fight against it as much as possible… which is the challenging part that makes being a game programmer so fun and fulfilling, personally.

Now, re: data analysis on the entity system through tools, that’s precisely the same analysis model as e.g. binary blobs. Except that binary blobs are ridiculously fast to store and load compared to an entity system, require much less database hardware, and so on.

“the typical MMO architecture has a “world simulation” process that needs access to most, if not all, components of an entity”

If it’s working correctly, I don’t see how that would happen?

If you’re accessing most/all components of the entity, then you’ve failed to build ES Systems – instead, you’ve built a monolithic “doEverthingPlease()” method.

Why would you do such a thing? What in your simulation algorithm reqires doing everything in a single process in a single place?

As usual (since it’s all I do), I’m considering how these systems work in an MMO, and in particular on the server side. Loading all (dynamic) entities, even into a caching server, is probably not feasible. (Though for entity templates, this is exactly what you’d want to do.) And the typical MMO architecture has a “world simulation” process that needs access to most, if not all, components of an entity, so partial entity loading isn’t applicable. So, it’s vital to be able to load an entire entity from the database in an efficient manner. Making multiple queries, one per component, does not strike me as satisfying that goal.

In a previous project of mine, we faced this issue. It turned out, after much experimentation, that the fastest way to load an entity from the database (MS SQL Server, fwiw) was to do a join across all of the component-specific instance data tables. If an entity didn’t have a row in one of those tables, then the result would have NULLs in those column positions, which had to be handled appropriately at the application level. Not pretty, and definitely not the easiest thing to maintain, but sometimes that’s how it goes.

It’s worth noting is that we only had about 5 components that had any instance data; add a few more, maybe a different approach would be better. If I were starting with a new technical design, I’d probably stick with a simpler method (i.e. query each component table individually), until it became necessary to improve performance.

I might have misunderstood what kind of data you’re talking about, but…

“entity systems are really awful at data analysis” – I’d argue the opposite :), although I agree that what you say is true “by default”.

The difference for me is that any real world ES is going to fall flat on its face as a data-maintenance nightmare if *all* you implement is the runtime system. Practically, you *must* build toolchain features / plugins that support the ES directly in your game-editors.

As soon as you do that, all the data model is once again back – only this time it’s even more explicit (and easier to read and write) than in the alternatives (such as OOP): it’s purer, because the *only* thing affecting the structures you have is the metadata you added to track those structures. In, say, traditional OOP, you’ll “additionally” have occurences of subclassing and non-subclassing that had to be done for reasons other than the core data structure.

FYI – in my earlist conversations with Scott Bilas about ES’s for Dungeon Siege etc, IIRC … he picked on the editor-support as the biggest single win/lose criteria for an ES being deemed a success at the project / final game level. For offline games like DS, the ES being implemented well or badly alters the output of the progrmming team, and the final runtime performance and bugginess. BUt the editor support alters the volume and quality of game-content – which for an RPG (obviously!) is the biggest single factor.

So … yeah … very important topic. One I haven’t gone into in any detail (yet), because with modern games (larger scale and/or multi-threaded and/or online), the ES implementation itself becomes a lot more critical. And it’s easier to screw up, IMHO :). But one I certainly want to cover in detail at some point – although I have less knowledge on how to do that part “right” – I have ideas and wishes on how to do it “better than I did before”, but haven’t tried them out yet.

re: 1 – good point. As you say, assuming only one instance of a given component is needed per entity … I think that’s a better way of handling it.

re: “N + c database queries for an entity with N components” problem.

…each system is typically only going to need access to a handful of components. If you need all the data for an entity, it’s either for offline / human-readable purposes (load it on screen to show to a player), so that latency isn’t an issue any more, or it’s as part of a mass serialization, in which case you’re probably going to sidestep it and just start dumping tables en masse.

Ideally: rather than fetch entities on-deman, you pre-select all the data needed by a particular system for ALL entities (should be < 10% of the total data of all entities – as per above, you only pick up the components that this system actually uses), and pass it that as input parameter on each tick of the game-loop. There are obvious optimizations here, e.g. splitting that pre-select into batches, but the use-cases for how much you want to pass to the system are going to depend a lot on where / how you're using the ES (is this a PS3 client? a multi-server cluster? etc).

@Jason: Transact-SQL has ExecuteSQL(), which is about as bad as you imagine. I saw a case where it was useful – an automated database update script had some lines of SQL that referred to non-existent tables and columns if that portion of the script didn’t need to be run. The script was smart enough to check for that condition, but if you left the ALTER TABLE commands as bare SQL they’d be parsed and SQL Server would error on them before anything was actually run. Wrapping them in ExecuteSQL() let us check for whether they were going to be valid, and THEN get the database to parse/execute them.

But yeah, it’s the database equivalent of self-modifying code, with equivalent big angry warning signs flashing around it. :-)

1) If you’re willing to live with the limitation that a given entity can only have a single instance of any specific component (which may not be a limitation at all, depends on design), then the component_data_id columns are unnecessary, and the component data tables would use entity_id as their primary key.

Even if you really needed multiple components of the same type attached to an entity, I don’t know if I’d necessarily use a separate id space to store them. An “instance_id” column (unique only to a given entity_id) would also work, and component data tables would have be keyed on entity_id + instance_id.

Why do this? Well, I think it’s clearer to have component data indexed on entity_id anyway, but it also means that component data tables will be sorted based on entity_id, which is a good thing for performance.

2) I generally prefer to not store table names in other tables, e.g. the components.table_name column, and would opt for an algorithmic method. My knowledge of SQL is far from complete, but as far as I know, you can’t get a column value and then use that value in a later “static” query as the table name. Instead you have to build the query strings dynamically, which reduces performance (or at least, forces the database to re-analyze/optimize such queries).

Hard to describe exactly what I mean, but let’s assume that SQL included a unix-like backtick operator. The following is what I’d theoretically like to write, but (to my knowledge) cannot:

SELECT * FROM `SELECT table_name FROM components WHERE component_id = $2` WHERE entity_id = $1;

The above query is meant to return (arbitrary) component data, given an entity id and a component id. Then again, I’m not sure how the db optimizer could do much with the above, even if I could legally write it.

I guess my main issue is that I prefer using stored procedures – exclusively – from the application, for a number of reasons. I don’t know that I could do that with the “dynamic” table names utilized in your approach – it would depend on what the database procedural language supported.

And yes, using “known” table names does mean that entity loading queries would hard-code those tables (perhaps in a huge join, even), but in the interests of performance that is something you may ultimately find necessary. I look forward to the next article in this series, and how you might avoid the “N + c database queries for an entity with N components” problem.

Maybe you can readdress this issue that has been nagging me:
How do systems interact with each other?
Are the systems oblivious of each other?

Let’s imagine two systems:
“ShootSystem”
“RegenerateHealthSystem”
- But the condition of some game unit (tank) is that it cannot shoot while regenerating.

1. Can I not make the ShootSystem somehow query the RegenerateHealthSystem if that entity is regenerating?

2. Should these two Systems actually be one System? Something like “RegenerateHealthAndShootingSystem” ? That doesn’t make sense to me, I thought you said this was supposed to be modular!? :)

3. If these systems can communicate, then what is the significance of this when you have each of those systems running on it’s own server?

This is just a thought but one way this might be done is if all of the different Components are stored on a separate Database Server and all of the System Servers are connected by a message system then the animation process could work like this:
First, the Animation System Server activates it’s Animation and updates the Animation Component on the database.
Then it sends a message to the Render System Server that a animation has been activated (this message would probably hold things like the Entity-id).
And finally the Render System Server will use the information in the Animation Message to fetch the animation data from the Database and use that during render time.
Hope this helps.

So taking the example where the Animation system just modifies the polygons in the Render component. How is this best handled when the two systems are running on different servers? (I know its not likely that a desktop game with an Animation and Rendering system would be large enough to take two servers, but the problem still holds for larger Systems that need to interact)

it depends a bit uponhow your rendering layer works, obviously…

Beyond that, it depends how you choose to implement the ES internals of your systems.

I’ll think about this properly, and try to include a better response later, but off the top of my head (nb: I reserve the right to later declare some or all of this stupid and wrong ;))…

For instance: if your renderer requires polygon arrays, then your renderable component may include a list of polygons to render. Your animation system might mutate those polygons directly – either by modifying them in-situ, or by Reading eg a bones list from it’s own component – the animation component – moving the bones, regenerating the entire polygon list, and overwriting it.

The rendering system would pick up the polygons each frame, and probably pick up the world-co-ords too, and translate the polys into position.

I haven’t settled on one because for the last year our team has been focused on prototyping gameplay for something other than your standard Diku/EQ/WoW clone. I was just starting on some aspects of world persistence the last couple of weeks, and now I don’t have to worry about that. A big part of my interest in exploring approaches is balancing production performance and data analysis, and none of the standard approaches do very well at one or the other.