3 ms·

A must have architectural pattern for such a list: "Entity Component System" http://en.wikipedia.org/wiki/Entity_component_system http://en.wikipedia.org/wiki/E

A must have architectural pattern for such a list: "Entity Component System" http://en.wikipedia.org/wiki/Entity_component_system http://en.wikipedia.org/wiki/Entity_component_system

munificent 13y ago
Must has: http://gameprogrammingpatterns.com/component.html http://gameprogrammingpatterns.com/component.html :)
interpol_p 13y ago
Not to take away from the value of component systems, but I find them remarkably tedious to code with. In Unity 3D they work well because the component attachments are driven by the visual interface. Your coding happens inside components, and is then linked up in the scene visually. The second game engine I implemented used an entity component system, and I found myself not wanting to use it. Attaching and building components in code just to do trivial things was tiresome. I think such a system is valuable for a game that's already designed, prototyped and ready to be implemented cleanly, but it's not a great pattern for prototyping/rapid game development. It's almost like you need one set of patterns for game prototyping (messy, hacky, and immediate operations), and an orthogonal set of patterns for final game implementation.
- robertkrahn01 13y ago
  Well, my personal pov is that for certain prototyping requirements component systems are actually a good fit because they make it easy to rewire thinks quickly and to easily plugin/replace strategies (as in strategy object). In this regard it is ver yrelated to the DCI pattern (http://en.wikipedia.org/wiki/Data,_context_and_interaction http://en.wikipedia.org/wiki/Data,_context_and_interaction). Also, components/systems fall much easier into place when using a functional programming approach.
- drblast 13y ago
  Conceptually, I think it is harder and kind of a pain to code for at first. But one of the advantages I've found using it is the ability to completely decouple the state of game objects from the code that manipulates them. This gives you the following (rarely mentioned) benefits: 1. Saving game state is trivial (as is replaying it, like in a rewind or time-travel) 2. For garbage-collected environments, it's easy to completely avoid GC pauses by re-using old game state objects. 3. Adding existing functionality to any object is trivial. #2 was the biggest win for me. I made some small bullet-hell style shoot-em-ups in C# that would pause for GC until I reworked the game into a component system where all game objects were stored in a table, and each row in the table contained all columns for all possible objects properties. So when a bullet went offscreen, the row its state was stored in became available for the next game object (bullet, alien, etc.) The only step necessary was to wire that row to the various components that would control the game object. The GC pauses disappeared, and this made changing the game and prototyping extremely easy. I'd imagine this would simplify memory management in C++ in the same manner. I also really enjoyed have things like "AffectedByGravity" as a component and the ability add objects arbitrarily into it, instead of some hackish inheritance chain.
  - interpol_p 13y ago
    I mostly agree with you, I just found that trivial things — like drawing sprites — became cumbersome. In my case it involved adding the transform component, the sprite render component, any movement components (usually custom subclasses for the specific game) and then adding that node into the graph. When I wanted to hack away quickly on ideas I found I avoided my own engine because of all the typing it took just to get something up on the screen and moving. Or I found myself creating simple wrappers on top of the component system that killed the flexibility for the sake of brevity and readability. In my personal experience coding with components did something to stop the creative, messy part of my brain that just wanted to see things on the screen and moving as soon as possible.
    - drblast 13y ago
      Yeah, I see that. The reason I think what I did became so easy is that I took the component model to the absolute extreme. There were no objects at all, just a table of state data and a collection of functions you could add to an "entity." I think most implementations mix and match some sort of OO and that would get messy quick. What I did worked great for the particular bullet-hell style shmup I was making. I don't know how well it would work with other types of games, particularly those with game entities that had a ton of state that wasn't shared. With the bullet-hell game, an enemy shared a lot of state with the main character and bullets. An RPG might be a different story.
- chipsy 13y ago
  I've oscillated back and forth between the different entity paradigms numerous times. In my most recent try I moved towards a design that is essentially an inversion of typical component strategy to put less emphasis on components as unique structures, since in so many cases, they're a repackaging of an existing data type. To do this, I have some generic container types that are extensions of common ones(list, bag, etc.) to be aware of entities and clean up after them. Instances of the generics are subsequently parametrized with the data I need. The top level entities hold the minimum of information needed to do despawning. It's had some success in use, but I'm not ready to say it's a major improvement.
lucaspiller 13y ago
I was reading a couple of good articles about this yesterday: http://piemaster.net/2011/07/entity-component-primer/ http://piemaster.net/2011/07/entity-component-primer/ http://piemaster.net/2011/07/entity-component-artemis/ http://piemaster.net/2011/07/entity-component-artemis/

A must have architectural pattern for such a list: "Entity Component System" http://en.wikipedia.org/wiki/Entity_component_system http://en.wikipedia.org/wiki/Entity_component_system

munificent 13y ago

Must has: http://gameprogrammingpatterns.com/component.html http://gameprogrammingpatterns.com/component.html :)

interpol_p 13y ago

Not to take away from the value of component systems, but I find them remarkably tedious to code with. In Unity 3D they work well because the component attachments are driven by the visual interface. Your coding happens inside components, and is then linked up in the scene visually. The second game engine I implemented used an entity component system, and I found myself not wanting to use it. Attaching and building components in code just to do trivial things was tiresome. I think such a system is valuable for a game that's already designed, prototyped and ready to be implemented cleanly, but it's not a great pattern for prototyping/rapid game development. It's almost like you need one set of patterns for game prototyping (messy, hacky, and immediate operations), and an orthogonal set of patterns for final game implementation.

robertkrahn01 13y ago
Well, my personal pov is that for certain prototyping requirements component systems are actually a good fit because they make it easy to rewire thinks quickly and to easily plugin/replace strategies (as in strategy object). In this regard it is ver yrelated to the DCI pattern (http://en.wikipedia.org/wiki/Data,_context_and_interaction http://en.wikipedia.org/wiki/Data,_context_and_interaction). Also, components/systems fall much easier into place when using a functional programming approach.
drblast 13y ago
Conceptually, I think it is harder and kind of a pain to code for at first. But one of the advantages I've found using it is the ability to completely decouple the state of game objects from the code that manipulates them. This gives you the following (rarely mentioned) benefits: 1. Saving game state is trivial (as is replaying it, like in a rewind or time-travel) 2. For garbage-collected environments, it's easy to completely avoid GC pauses by re-using old game state objects. 3. Adding existing functionality to any object is trivial. #2 was the biggest win for me. I made some small bullet-hell style shoot-em-ups in C# that would pause for GC until I reworked the game into a component system where all game objects were stored in a table, and each row in the table contained all columns for all possible objects properties. So when a bullet went offscreen, the row its state was stored in became available for the next game object (bullet, alien, etc.) The only step necessary was to wire that row to the various components that would control the game object. The GC pauses disappeared, and this made changing the game and prototyping extremely easy. I'd imagine this would simplify memory management in C++ in the same manner. I also really enjoyed have things like "AffectedByGravity" as a component and the ability add objects arbitrarily into it, instead of some hackish inheritance chain.
- interpol_p 13y ago
  I mostly agree with you, I just found that trivial things — like drawing sprites — became cumbersome. In my case it involved adding the transform component, the sprite render component, any movement components (usually custom subclasses for the specific game) and then adding that node into the graph. When I wanted to hack away quickly on ideas I found I avoided my own engine because of all the typing it took just to get something up on the screen and moving. Or I found myself creating simple wrappers on top of the component system that killed the flexibility for the sake of brevity and readability. In my personal experience coding with components did something to stop the creative, messy part of my brain that just wanted to see things on the screen and moving as soon as possible.
  - drblast 13y ago
    Yeah, I see that. The reason I think what I did became so easy is that I took the component model to the absolute extreme. There were no objects at all, just a table of state data and a collection of functions you could add to an "entity." I think most implementations mix and match some sort of OO and that would get messy quick. What I did worked great for the particular bullet-hell style shmup I was making. I don't know how well it would work with other types of games, particularly those with game entities that had a ton of state that wasn't shared. With the bullet-hell game, an enemy shared a lot of state with the main character and bullets. An RPG might be a different story.
chipsy 13y ago
I've oscillated back and forth between the different entity paradigms numerous times. In my most recent try I moved towards a design that is essentially an inversion of typical component strategy to put less emphasis on components as unique structures, since in so many cases, they're a repackaging of an existing data type. To do this, I have some generic container types that are extensions of common ones(list, bag, etc.) to be aware of entities and clean up after them. Instances of the generics are subsequently parametrized with the data I need. The top level entities hold the minimum of information needed to do despawning. It's had some success in use, but I'm not ready to say it's a major improvement.

lucaspiller 13y ago

I was reading a couple of good articles about this yesterday: http://piemaster.net/2011/07/entity-component-primer/ http://piemaster.net/2011/07/entity-component-primer/ http://piemaster.net/2011/07/entity-component-artemis/ http://piemaster.net/2011/07/entity-component-artemis/