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.
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!
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.
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 KazeI 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.
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.
[Edited by - Echkard on September 25, 2010 9:42:41 PM]
Heh, I think Kylotan is prepared to counter every argument, hence the question :)
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.
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 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 RainweaverThis 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.
I look for "data-drivenness", reuse...The downside is that they require a lot of development time
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 EchkardEh, 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'.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.
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.
:)
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.
:)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
