Components for entities - why?

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!

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.

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.

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.

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]

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 :)

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.

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.

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.

:)

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.

Quote:

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.

Quote:

Original post by Echkard Quote: 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.

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.

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.

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%?

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.

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

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.

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 :)