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.
Components for entities - why?
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.
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.
Quote:Original post by RainweaverI'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:
An entity system is not just about composition, it is also serialization, net communication, message-dispatching...
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.
Quote:Original post by EchkardExcept 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.
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.
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 TelastynOne 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.
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:Original post by Oberon_CommandQuote:Original post by TelastynQuote:
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.
Quote:Original post by swiftcoderErr, if you're attaching them statically, then you're creating a custom class for that particular set of behaviors. Which is exactly the scenario I describe above, whether or not you actually call the leaf classes things like TankHoverWithTurret vs. CarHoweverWithLaser. Static composition requires you to define each possible permutation beforehand.
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.
I'll just relate to you my experiences when I introduced 'entity systems' (whatever you call it) to our new game.
I was a new employee, but I already have experience working with entity systems on my personal game projects. I was tasked to do the physics management of the game and since there was no game object management system yet, it was up to me on how to make those game objects. Looking at the code of the company's previous games, I could say that they are heavy users of static hierarchy. And based on what I saw in their code, there were lots of hacks just to get a certain type to do what it's supposed to do. I'd like to avoid that so I implemented an entity system as the game object management system.
At first, they were very confused. They could not comprehend how I was making unique entities. They couldn't see a MinionEntity class or a HazardEntity class which they expected. All they see are a bunch of
There were many questions, many objections. I got a fight with my lead. I did a lot of explaining. I gave them links to read about. Then out of the blue, someone was able to finish his task using the entity system and defended me. From then on, everyone was using the system. Eventually, they got the hang of it and they found that it's simple and flexible, too. It was smooth sailing from then on.
From these experiences, I could say that using entity systems is a lot better than the traditional static hierarchy. Making changes, adding features, removing features are easier (we had a lot of changes). We could delegate tasks to someone else with less worry. For example, a certain programmer would be assigned to code a particular system. All we have to do is request a component from his system, add to our entities, make some preparations for it using its interface, and should be working fine. If that component does not work, or breaks, we knew who to ask or whom to assign for fixing.
We also avoided the hack tricks (why do game programmers love them). Most of the time, there's no need to hack. If a certain programmer needs to, the design of his system must be poor.
I was a new employee, but I already have experience working with entity systems on my personal game projects. I was tasked to do the physics management of the game and since there was no game object management system yet, it was up to me on how to make those game objects. Looking at the code of the company's previous games, I could say that they are heavy users of static hierarchy. And based on what I saw in their code, there were lots of hacks just to get a certain type to do what it's supposed to do. I'd like to avoid that so I implemented an entity system as the game object management system.
At first, they were very confused. They could not comprehend how I was making unique entities. They couldn't see a MinionEntity class or a HazardEntity class which they expected. All they see are a bunch of
// prepare a minion entityEntity* entity = entityManager.request();Transform* transform = entity.addComponent<Transform>();... // prepare transformRigidBody* rigidBody = entity.addComponent<RigidBody>();... // prepare rigid bodyMeshRenderer* renderer = entity.addComponent<MeshRenderer>();... // prepare the renderer
There were many questions, many objections. I got a fight with my lead. I did a lot of explaining. I gave them links to read about. Then out of the blue, someone was able to finish his task using the entity system and defended me. From then on, everyone was using the system. Eventually, they got the hang of it and they found that it's simple and flexible, too. It was smooth sailing from then on.
From these experiences, I could say that using entity systems is a lot better than the traditional static hierarchy. Making changes, adding features, removing features are easier (we had a lot of changes). We could delegate tasks to someone else with less worry. For example, a certain programmer would be assigned to code a particular system. All we have to do is request a component from his system, add to our entities, make some preparations for it using its interface, and should be working fine. If that component does not work, or breaks, we knew who to ask or whom to assign for fixing.
We also avoided the hack tricks (why do game programmers love them). Most of the time, there's no need to hack. If a certain programmer needs to, the design of his system must be poor.
Quote:Original post by EchkardQuote:Original post by RainweaverI'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:
An entity system is not just about composition, it is also serialization, net communication, message-dispatching...
Refactoring Game Entities with Components
I'm not sure if you're doing this on purpose or you really can't understand what I wrote. I guess the condescending tone made it clear from post 1 that you have nothing to contribute but picking on words to make you look smart. It's okay, I have nothing more to say. I just hope others are as patient as necessary to not let the discussion wither.
Quote:Original post by Echkard*sighs* Nope. They are still components, and they are still attached together by client code. The difference is that they cannot be changed post-creation, and they cannot be attached based on data-driven configuration files.
Err, if you're attaching them statically, then you're creating a custom class for that particular set of behaviors. Which is exactly the scenario I describe above, whether or not you actually call the leaf classes things like TankHoverWithTurret vs. CarHoweverWithLaser. Static composition requires you to define each possible permutation beforehand.
Quote:Original post by RainweaverI understand perfectly, but your definition is still wrong. An entity component system is not just "any code with objects in it". It's a specific implementation method of dynamic composition. Look at the links I gave, or the sample code that Mazelle posted.
I'm not sure if you're doing this on purpose or you really can't understand what I wrote.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement