Sign in to follow this  
Kylotan

Components for entities - why?

Recommended Posts

Simple question for you all, probably with some not-so-simple answers.

Of late there's been a massive increase in the number of people wanting to move towards component-based systems for their game characters, sometimes confusingly called "entity systems". In this, what used to be one big game object class is typically broken up into various component classes, and they are mixed and matched together and joined up in one of various ways.

Now, I understand the benefits of making small, cohesive bundles of code rather than 1 big uber-class. And I certainly appreciate that composition is generally preferable to inheritance when it comes to complex behaviour as you can more easily implement the permutations. All well and good.

But I'm intrigued as to why people think this applies so closely to game characters? I follow a lot of mainstream development too and nowhere else has there been such a rush to try and change one of their common domain objects to a new paradigm like many game developers are. What is specific to game development or game objects that makes them especially amenable to this approach? Why don't other developers need to go down this route to the same degree, and can we learn something from them instead? Is there a 'third way', that neither requires monolithic classes in a rigid hierarchy, nor a complex binding of algorithmic Lego? Why is it that, despite so many people being sure that components are the answer to the problem, we have nothing remotely resembling a consensus on how these components communicate (or if they even need to communicate at all)?

I'm interested to hear your views.

Share this post


Link to post
Share on other sites
Why?

a) It's new, and thus "cool".
b) Hardware is getting fast enough where the extra overhead of such an approach isn't a performance killer.

What I find most odd of all is that the overarching reason for OOP is code maintainability and reuse .. yet game code is some of the *least* maintained and reused code in the industry. I exclude middleware/engine/library code from that, of course. But the entity approaches typically find there way into the highest code levels ... code that is lucky to be reused once, if ever, in many cases.

Game developers are to their credit some of the least hide-bound in all software development. An only partially tongue-in-cheek explanation of this is their incredibly low salaries....if a design decision goes bad, the resultant loss of a job isn't quite as painful!

Share this post


Link to post
Share on other sites
The main advantage I find is that its just a given the feature requirements of a game design will change over the course of its development, a component system lets you add new features and change existing ones without having to rewrite everything else.

You say game code has poor reuse but a game project can undergo more changes from planning to release than many software packages will have in their entire lifetime.

Share this post


Link to post
Share on other sites
Quote:
Original post by Kylotan
What is specific to game development or game objects that makes them especially amenable to this approach?


What I like most about entity systems is that I don't have half updated "characters" like with an old school big-hierarchy approach. Instead I update each component type in one batch. This means that physics is updated first, then logic, then it's rendered (of course there are many more component types).

Updates could be run in multiple threads, as long as those components do not depend on each other. The way I see it, there will be dependencies between different types of components. Those dependencies should make up a tree (Vertex = Type, Edge = Type A requires B) and all Vertices/Types with the same depth can be safely updated in multiple threads. However I can't say if this will make a noticeable difference, those are just my unproven thoughts :D

I think ES also make it easier to make Characters more data driven. Since characters are defined by an aggregation of components, it's easy to make up new characters that posses different or more components.

There are probably more advantages though.

Share this post


Link to post
Share on other sites
Quote:
Original post by Kylotan

that makes them especially amenable to this approach


A talking rock that gives out quests.

Implemented via configuration file.

As a mod.

Share this post


Link to post
Share on other sites
Quote:
Original post by Kaze
You say game code has poor reuse but a game project can undergo more changes from planning to release than many software packages will have in their entire lifetime.
I beg to differ. There are plenty of corporate programmers still working on packages first written 20 or even 30 years ago, with hundreds of thousands of lines of code being revised every year. In some environments, software designed for internal use is essentially an immortal, never-dying beast that, without ever once being rewritten from scratch, undergoes continual piece-meal modification for the entire life of the company.

[Edited by - Echkard on September 25, 2010 9:42:41 PM]

Share this post


Link to post
Share on other sites
Heh, I think Kylotan is prepared to counter every argument, hence the question :)

Quote:
Original post by Kylotan
Of late there's been a massive increase in the number of people wanting to move towards component-based systems for their game characters, sometimes confusingly called "entity systems".


I look for "data-drivenness", reuse, extreme flexibility. Component-based systems are based on those principles. The downside is that they require a lot of development time, careful design and last but not least, a thought to performance - because resolving complex behaviour at runtime is bound to be slower than just a bunch of virtual calls.

Entity is a common synonym for game object. Actor, entity, go, game object, object, prop.

Quote:

Is there a 'third way', that neither requires monolithic classes in a rigid hierarchy, nor a complex binding of algorithmic Lego? Why is it that, despite so many people being sure that components are the answer to the problem, we have nothing remotely resembling a consensus on how these components communicate (or if they even need to communicate at all)?


The third-way is when you know what to hard-code and what to resolve at runtime, basically a mix of what you said, and I can't tell if there's a "fourth way".

Why are you surprised about lack of consensus? I'm not, when I see stuff like CORBA, DCOM, ICE, what have you...

I for one think that communication is fire and forget, and based on messages. However, you could say that function calls are "messages" to an object (Smalltalk comes to mind). So really, it depends on how you want to approach the problem.

I've been trying to write an entity system for three years now (and counting). There are so many issues to tackle it's almost masochistic. So yeah, I keep asking myself if it's worth it. The answer is: it depends :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Rainweaver
I look for "data-drivenness", reuse...The downside is that they require a lot of development time
This is the essential dichotomy that I (and I think possibly Kylotan) am trying to highlight. The benefit of code reuse is a savings in overall development time ... but if you spend more total time on your entity system than you would have on an alternative, you didn't get a benefit, you took a loss.

Quote:
Entity is a common synonym for game object. Actor, entity, go, game object, object, prop.
These are not all synonymous. An entity system is a specific means to implement a game object/actor. It's essentially a variant of the compositing design pattern.

Share this post


Link to post
Share on other sites
Quote:
Original post by Echkard
Quote:
Entity is a common synonym for game object. Actor, entity, go, game object, object, prop.
These are not all synonymous. An entity system is a specific means to implement a game object/actor. It's essentially a variant of the compositing design pattern.
Eh, overly pedantic. That is one, *narrow* definition of an entity system - but any system involving any type of 'entity' could equally be considered an 'entity system'.

Personally, I was calling the objects in my game 'entities', long before 'component/entity systems' showed up here on GDNet.

The wikipedia page sums it up pretty well, I think: an entity is something that has a distinct, separate, though not necessarily material, existence.

Share this post


Link to post
Share on other sites
Hi all.

I think that the component / entity system is a very usefull approach.
It can be used to make to composing of objects not bound to the code but instead bound to the data ( of course each component consists of code but you get the point).

This means that the making and editing of old / new objects can be taken away from the coders and put into the hands of artists or others that edit / design your game. And I think it's easier to edit and compose new objects by putting parts / components togheter in an editor to form it rather then spending time coding it and it can also be less error prone.

But there is always the time factor. If you don't have the time to make a big component system and an editor for it don't do it. Choose an approach that fits your project instead.

:)

Share this post


Link to post
Share on other sites
There is no dichotomy. A component based system is totally compatible with a traditional object oriented system. I think the problem here is confusion between terms; if you are using classes, single responsibility principle, and instancing, but are not making code objects which simulate the real world, you are using a totally different paradigm to the one where you have a series of objects, each of which simulates real world behaviour.

With traditional object oriented programming, a class is designed to simulate an object from the real world; for example, a weapon has a series of tasks, such as firing, reloading, jamming, etc. It also has a set of properties; the amount of ammunition, the damage it does, the sound it makes and so on. A weapon has an internal mechanism which you cant control, instead you have to control it through its "public interface" - the trigger, the magazine well, the fire selector, etc. In object oriented code, your job is to simulate that interface as closely as possible.


With a component based system, there is no single class Weapon; rather, there is an Entity with a list of components, and each component obeys Single Responsibility Principle. Weapon may be one of these components. Each type of component can be in a seperate list, just as you previously had a list of class Weapon, class Monster, etc.

But you don't have to use one or the other; there is no dichotomy. If your Weapon component is exactly the same as the Weapon you had in the old system, and you also have a Vehicle component which is modelled in a similar fashion, You would be able to have a turret which "has a" weapon, as well as "has a" vehicle; The entity would be in a set of these components, the weapon component would be in a list of weapons, and the vehicle component would be in a list of vehicles. The task of class Entity is just to hold these things together.

Share this post


Link to post
Share on other sites
Quote:
[i]Eh, overly pedantic. That is one, *narrow* definition of an entity system - but any system involving any type of 'entity' could equally be considered an 'entity system'.
Sorry, no. In this context, an entity system is a design paradigm for implementing objects via dynamic composition, rather than through a deep hierarchy.

By your definition, anything OOP is an "entity" system, because it has objects in it. Or not even an OOP system --anything program at all, as long as it has something nebulous you can term an "actor": anything that has action. A definition which is not only incorrect, but so vague as to be essentially meaningless.

Quote:
The wikipedia page sums it up pretty well, I think
It sums up the definition of the English term, which is considerably different than the meaning in the context of an entity system. That's like claiming a binary bit is "any small piece of something", because you read the dictionary definition.

Share this post


Link to post
Share on other sites
Quote:
Original post by Echkard
Quote:
[i]Eh, overly pedantic. That is one, *narrow* definition of an entity system - but any system involving any type of 'entity' could equally be considered an 'entity system'.
Sorry, no. In this context, an entity system is a design paradigm for implementing objects via dynamic composition, rather than through a deep hierarchy.
We appear to be talking at cross-purposes.

I was commenting re Kylotan's suggestion that the 'entity' nomenclature is confusing, with which I agree - and our conversation bears out.

There is nothing particularly unique about the 'entity' in component-centric systems - on the contrary, I would say that component systems are significantly less 'entity' related than a traditional inheritance hierarchy.

Share this post


Link to post
Share on other sites
Quote:
Original post by speciesUnknown
There is no dichotomy. A component based system is totally compatible with a traditional object oriented system.

I don't want to interrupt the responses yet - keep 'em coming - but I wanted to comment on this point.

I agree with you insofar as that when I see people talking about component-based entities as an alternative or replacement for OOP I think they're wrong. As you say, you typically implement components as objects, and in one way they are the logical endpoint of applying the single responsibility principle.

However, I would argue that there is a dichotomy - not in theory, where it's a sliding scale, but in practice - between the traditional system which favours inheritance, over the component system which favours composition. Given that you have a GameEntity, and you want a Player, a Goblin, and a Troll, do you create Player/Goblin/Troll classes that inherit from GameEntity, or do you create objects that implement Player/Goblin/Troll behaviour and aggregate them within the GameEntity? I think that's the major distinction that people are making. Even if you used to group Goblin and Troll under one NPC or Monster class, people still used to have that as a separate class to the Player. But now, not only are those two being merged into one, but people are realising that Player, NPC, and even collectable Objects or Lights or Waypoints can all just be Entities, perhaps.


Oh, one other thing, regarding terminology: I think "entity system" is a poor name because it doesn't capture the unique essence of what is different with this approach, ie. component-based aggregation to define the behaviour. Entities can and did exist before the interest in making them component-based picked up. Sure, we could just adopt the new meaning of 'entity' in this context, but it seems unnecessary since 'component' expresses it more precisely.

Share this post


Link to post
Share on other sites
Quote:
Original post by Kylotan
Regarding terminology: I think "entity system" is a poor name because it doesn't capture the unique essence of what is different
Absolutely. The proper name is "composite design pattern", but some early game developer thought he had stumbled onto something new, and therefore created a separate name for it. The problem is made worse by all the multitudinous ways the term "entity" is used in programming.

Share this post


Link to post
Share on other sites
Quote:
Original post by Echkard
Quote:
Original post by Kylotan
Regarding terminology: I think "entity system" is a poor name because it doesn't capture the unique essence of what is different
Absolutely. The proper name is "composite design pattern", but some early game developer thought he had stumbled onto something new, and therefore created a separate name for it. The problem is made worse by all the multitudinous ways the term "entity" is used in programming.


But who gets to decide what the proper name is? Is it down to the first person to use it? How do we know who was the first? What happens if that person gives it a stupid name? What if somebody uses something which is 95% the same as the thing with this other name, but has some fundamental difference - should it still use the same name? OR should it use a different name to avoid confusion? What about 80%?

Share this post


Link to post
Share on other sites
Quote:
Original post by Kylotan
But I'm intrigued as to why people think this applies so closely to game characters?


Game pieces more often have bits of functionality that are shared between 'types' of objects, or enabled/disabled via levelling/technology/spell-effect/equipment. Bizdev tends to have a lot less of this, and tends to be hacked on at the end.

Quote:

I follow a lot of mainstream development too and nowhere else has there been such a rush to try and change one of their common domain objects to a new paradigm like many game developers are.


I would perhaps argue that the Bizdev world went through upheaval maybe 10 years ago with the big IoC push, and are still trying to settle that out to something that isn't completely terrible.

Quote:

Is there a 'third way', that neither requires monolithic classes in a rigid hierarchy, nor a complex binding of algorithmic Lego?


I still think that languages that provide mix-ins or a structural type system (or even plain old dynamic languages) better lend themselves to component based entities. The options in current curly brace language systems are... poor.

Quote:

Why is it that, despite so many people being sure that components are the answer to the problem, we have nothing remotely resembling a consensus on how these components communicate (or if they even need to communicate at all)?


See above. The utilities to provide unsucky interaction between aggregated entities or multiply-inherited base classes or message hooked bits of a whole just aren't there with the tools we have. Programmers can conceptualize what they want, but not how to implement it.

It's kinda like Da Vinci's flying machines. He knew what he wanted to do, but the engineering practices of the time just couldn't get them to work. Or it's like the hordes of useless business analysts with grandiose vision, but vague details. Depending on your cynicism currently of course.

Share this post


Link to post
Share on other sites
Quote:
Original post by Telastyn
Quote:

Is there a 'third way', that neither requires monolithic classes in a rigid hierarchy, nor a complex binding of algorithmic Lego?


I still think that languages that provide mix-ins or a structural type system (or even plain old dynamic languages) better lend themselves to component based entities. The options in current curly brace language systems are... poor.


I'm curious, what do you think of Scala? It's technically a curly-brace language (albeit a rather less conventional one) and it has some support for mixins (again, less conventionally than other curly-brace languages).

Share this post


Link to post
Share on other sites
Quote:
Original post by Kylotan
But I'm intrigued as to why people think this applies so closely to game characters? I follow a lot of mainstream development too and nowhere else has there been such a rush to try and change one of their common domain objects to a new paradigm like many game developers are.
I'll throw in my own (anecdotal) experience here. I know some people seem to think of component-based entity design as a 'fad' or something that people adopt just because it seems to be the 'thing to do', but I can say that switching from an inheritance-based to a component-based system in my own projects was an absolute breath of fresh air. To me at least, describing game objects using components makes infinitely more sense than describing them using inheritance.

This has all already been mentioned, more or less, but it's largely a question of orthogonality. I won't elaborate (since it's already been covered), but the 'talking rock that gives out quests' is a good example. Where would this entity fit in a traditional inheritance-based hierarchy? I suppose you could figure it out, but the point is that with a component-based system, you don't even have to *think* about it; creating a talking, quest-giving rock (or any other entity type that's an arbitrary aggregate of disparate characteristics and behaviors) is as easy as creating any other type of entity.

Share this post


Link to post
Share on other sites
Quote:
Original post by jyk
...but the 'talking rock that gives out quests' is a good example. Where would this entity fit in a traditional inheritance-based hierarchy? I suppose you could figure it out, but the point is that with a component-based system, you don't even have to *think* about it; creating a talking, quest-giving rock (or any other entity type that's an arbitrary aggregate of disparate characteristics and behaviors) is as easy as creating any other type of entity.


Not only this, but with a fixed hierarchy of objects, introducing a new object means recompilation. And if you're using scripts, you're using code as data, which may or may not be a good way to describe and/or store information.

Quote:

Original post by Eckhard
The proper name is "composite design pattern", but some early game developer thought he had stumbled onto something new, and therefore created a separate name for it. The problem is made worse by all the multitudinous ways the term "entity" is used in programming.


An entity system is not just about composition, it is also serialization, net communication, message-dispatching, all of this towards the implementation of an entity system in which entities have (brief) lives and relate to each other in their virtual space; in this regard, the english definition of "entity" that swiftcoder mentioned is way better than "composite design pattern". And since there's no One True Way, as you may have realized by now, arguing about definitions is really pointless. Only a rhetorical exercise.

Quote:

Original post by Telastyn
The utilities to provide unsucky interaction between aggregated entities or multiply-inherited base classes or message hooked bits of a whole just aren't there with the tools we have. Programmers can conceptualize what they want, but not how to implement it.


I see what you mean, but it can be implemented. Only tiring and bothersome. Runtime code generation, text templates, there are options.

Entity systems are not a fad, why would they be? It is not a single pattern, it is not a single way of implementing relationships between game objects, it is not a trend. It's not like you have to implement ESs like there's no tomorrow. They could also be part of the tectonic shift that carries managed code, dynamic languages and indie games into the world of game development. Who knows? Like it? Code it. Not convinced? Use something else. The good of programming. Reinventing the wheel when the wheel doesn't look good enough :)

Share this post


Link to post
Share on other sites
I think that keeping everything divided in components is only for fancy engines that don't really care what kind of data you give them. For small and/or properly planned projects that isn't necessary or worth the effort.
Perhaps multithreading can also work more naturally with components...

While thinking about my experiences, something came into my mind.
How about a hybrid system? Entities can have their Tick / Draw / Serialize / (whatever) functions -and- have some(!) components that work more like clients to a system / resource handles.

Let's say you need a small and dumb bug enemy in your game. Would you rather want to make a bug enemy component and then try to stick that and mesh, sound, pathfinding components together OR put all the AI code (it's simple) in the Tick function, sound in the inherited class / sound library component and keep mesh instance / pathfinding client as components? :D

So after looking at what I wrote, I think the design pattern you use doesn't matter. How you use it is more important.

Share this post


Link to post
Share on other sites
I don t think multithreading is the intention behind component based systems, after all you still have some central object that holds shared data and needs synchronization (locks).


One could argue about it, but multithreading on components is settled at a pretty low level.

Often in games you can separate worlds into regions, where each region can be updated independently. The latter approach is easier to program in my opinion, since it follows the traditionally single threaded designs everyone knows.

The same debate exist for distributed systems, multiprocessing vs multithreading.


To the topic, one question that comes to my mind is, do components store data internally? Thus have a state, or do they simply add functionality to shared data through the factory pattern?


What about systems where components are just ADTs, serving as a data source from hd or some dbms?

Upon these ADTs you have a couple of systems that implement all the functionality and are executed in order( functionality could again be added with the factory pattern).

The latter ones are often used in browser games( at least in my own), but I see potential for large scale mmos here as well.

Share this post


Link to post
Share on other sites
Quote:
Original post by Rainweaver
An entity system is not just about composition, it is also serialization, net communication, message-dispatching...
I'm sorry, but there's nothing unique about any of this in an entity system. Your definition of an "entity system" as "anything with objects" in it is not wrong, it's far too loose to even be meaningful. I suggest the following as a good starting point reference on what actually is unique about composite entity systems:

Refactoring Game Entities with Components

I also find it interesting that no one here has stated explicitly what the primary advantage of such a system is. For instance, assume you have a game with three types of vehicle (car, bus, tank), three types of locomotion (wheel, tread, hover), and four types of weapon (cannon, laser, flame, sonic). Now in a traditional hierarchy, handling all those permutations would require 3x3x4 = 36 different objects, each incorporating multiple inheritance. With an entity system, it requires only 3+3+4 = 10 objects.

Of course, there's a performance hit to resolving all this dynamically, but in some cases it can be well worth it. Of course, if you don't realize the reasons why you might use the entity design approach, you're going to vastly overuse it.

Share this post


Link to post
Share on other sites
Quote:
Original post by Echkard
Now in a traditional hierarchy, handling all those permutations would require 3x3x4 = 36 different objects, each incorporating multiple inheritance. With an entity system, it requires only 3+3+4 = 10 objects.
Except that *nobody* ever actually programmed like that. Long before component systems showed up, we were attaching weapons and locomotion systems to game objects (via composition) to modify their behaviour.

The key difference is that we used to attach those components *statically*. With a component system we are attaching them dynamically, typically in a data-driven fashion.

Quote:
Original post by Telastyn
I still think that languages that provide mix-ins or a structural type system (or even plain old dynamic languages) better lend themselves to component based entities. The options in current curly brace language systems are... poor.
One thing you quickly encounter is that dynamic languages make a large part of our current conception of component systems irrelevant. For example, when you have such flexibility in loading code dynamically, code-as-data becomes a much simpler option than a truly data-driven system.

Share this post


Link to post
Share on other sites
Quote:
Original post by Oberon_Command
Quote:
Original post by Telastyn
Quote:

Is there a 'third way', that neither requires monolithic classes in a rigid hierarchy, nor a complex binding of algorithmic Lego?


I still think that languages that provide mix-ins or a structural type system (or even plain old dynamic languages) better lend themselves to component based entities. The options in current curly brace language systems are... poor.


I'm curious, what do you think of Scala? It's technically a curly-brace language (albeit a rather less conventional one) and it has some support for mixins (again, less conventionally than other curly-brace languages).


I've not actually written any code in Scala, so it's hard to say. It has features that should make this sort of thing easier, but I question how well mere mortals can work in the language.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this