Register Game Object Components in Game Subsystems? (Component-based Game Object design)

topright
  • Register Game Object Components in Game Subsystems? (Component-based Game Object design) topright

    I'm creating a component-based game object system. Some tips:

    1. GameObject is simply a list of Components.
    2. There are GameSubsystems. For example, rendering, physics etc. Each GameSubsystem contains pointers to some of Components. GameSubsystem is a very powerful and flexible abstraction: it represents any slice (or aspect) of the game world.

    There is a need in a mechanism of registering Components in GameSubsystems (when GameObject is created and composed). There are 4 approaches:


    • 1: Chain of responsibility pattern. Every Component is offered to every GameSubsystem. GameSubsystem makes a decision which Components to register (and how to organize them). For example, GameSubsystemRender can register Renderable Components.

    pro. Components know nothing about how they are used. Low coupling. A. We can add new GameSubsystem. For example, let's add GameSubsystemTitles that registers all ComponentTitle and guarantees that every title is unique and provides interface to quering objects by title. Of course, ComponentTitle should not be rewrited or inherited in this case. B. We can reorganize existing GameSubsystems. For example, GameSubsystemAudio, GameSubsystemRender, GameSubsystemParticleEmmiter can be merged into GameSubsystemSpatial (to place all audio, emmiter, render Components in the same hierarchy and use parent-relative transforms).

    con. Every-to-every check. Very innefficient.

    con. Subsystems know about Components.


    • 2: Each Subsystem searches for Components of specific types.

    pro. Better performance than in Approach 1.

    con. Subsystems still know about Components.


    • 3: Component registers itself in GameSubsystem(s). We know at compile-time that there is a GameSubsystemRenderer, so let's ComponentImageRender will call something like GameSubsystemRenderer::register(ComponentRenderBase*).

    pro. Performance. No unnecessary checks as in Approach 1.

    con. Components are badly coupled with GameSubsystems.


    • 4: Mediator pattern. GameState (that contains GameSubsystems) can implement registerComponent(Component*).

    pro. Components and GameSubystems know nothing about each other.

    con. In C++ it would look like ugly and slow typeid-switch.


    Questions: Which approach is better and mostly used in component-based design? What Practice says? Any suggestions about implementation of Approach 4?

    Thank you.

  • Door number 3... Component registers itself in GameSubsystem(s)

    The component is in place to keep the coupling abstracted from the GameObject itself. Somehow, somewhere something does in fact need to interact with the subsystems and this is the component and its purpose.

    The coupling isn't actually a bad thing in this case.

    The performance is essentially required in this case if you expect to have any complexity in your system, you just can't afford the search style approaches of the other options.

    Finally if one subsystem needs to be reactive to another (renderer, physics, audio all need to do stuff when something happens) the components can facilitate this with each other through the game object and keep this particular type of cross system-coupling managable through the components.

Tags
c++ architecture component-based
Related questions and answers
  • I'm writing a shooter (like 1942, classic 2D graphics) and I'd like to use a component based approch. So far I thought about the following design: Each game element (airship, projectile, powerup... remove_component(C* c) { components.at<C>() = 0; } void serialize(filestream, op) { /* Serialize all componets*/ } ... }; std::list<Entity*> entity_list; With this design I can get #1... components and that would require searching each other component's list at each step. Which approch do you think is better? is boost::fusion map suited to be used in that way?

  • ) Where should I place the messaging system for my game engine? Lua? C++? I'm tempted to just have C++ object to behave as servers, offering services to lua business logic. Things like physics system, rendering system, input system, World class, etc... And for all the other things, lua. Creation/Composition of entities based on components, game logic, etc... Could anyone give any insight on how... language, in my case Lua. On the other hand I want to use a component based design for my entities, and here starts my questions: 1) Should I define my componentes in C++? If I do this in C++ won't I

  • there is a totally different and better way to do this, please let me know. Additional info: the game is in C++, and the graphics engine is Ogre3D. EDIT: changed the part about the trajectories of the non... component associated with it). No problem until this point. For this function I want to use a scientifically tested, accurate N-body simulation algorithm (like this). It's my field so I already know how to do that. The challenge is how to make the game activate the function efficiently. This is what I've thought of so far: The algorithm can calculate a lot of time steps in a short time, so I could

  • critical place in the code. He gave the example of loading data from a wad file in doom, which while fast, still took that naive approach (at least according to the talk, I haven't looked..., not noticeable, so it's better to optomize how much work you can get done in your lifetime, than to make things a millisecond faster, again, assuming it's not in your physics engine or something like...I was recently listen to a talk that Jonathan Blow gave, you can find it here. In the talk, he was talking about what data structures he (and he seemed to imply many others) use, and why. Which

  • _interior_cave1.xml, which contains all the information on what textures are used. It loads the textures as said by the tileset-XML-file, it gives them an ID and then the SceneManager-class knows how to lay out...I'm writing a game engine which is going very fine. However, I'm now posed with handling textures. My Engine is in 2D, for simplicity reasons mostly to get a good idea of how to work with OpenGL. I..., and OpenGL renders the whole thing. I think that's the best I can do at explaining. Know that the SceneManager itself contains no OpenGL code, just paths and information that OpenGL needs to know

  • I'm working on a Component/Entity-System based game engine atm. And I have this little dilemma. I have simple geometrical structures which might be downloaded or created in game at some point... only the transformations needed each frame. My Components would then point to these arrays. Is it the right approach? If not, how to store the structure data to get it loaded only when needed to GPU... and the display. But I started thinking about the future of this engine as I already invested some spare time over a year and a half in it. Now I would like to duplicate a few routines into OpenCL kernels

  • question about it is, is this a worthwhile approach at all? If it's a bad design I want to know now before I invest too much more time making all the screens I'm going to need. How do you build up... sort of designs other people used to overcome them, or would use. For a little background, I started working on it in my free time last summer. I was initially making the game in C#, but about 3 months... areas of concern I have and wanted to get some opinions on the proper way others have solved them or would solve them. 1. Cyclical Dependencies When I was doing the game in C#, I didn't really have

  • I've been using OpenGL for a short time now- and I'd like some clarification on VBOs. As I understand it, a VBO is an object stored on VRAM. In immediate mode, to apply a texture we simply bind... be a bit more difficult to just draw the objects on the screen but with some math I'm sure it's doable. Question 2: Once we figure out which objects need to be rendered, would it be acceptably fast... often, are there any guidelines as to the performance differences between GL_STATIC_DRAW and GL_DYNAMIC_DRAW? Final Question: Should I even consider using vertex lists? Or are VBOs just a better

  • with different types of objects in the same scene. I was also thinking about making a MeshNode class and then make a Mesh object that contains them, but then I have some conflict on where to store some data... full of questions about this.. Thanks in advance. EDIT: I'm gonna add some code about it Yes probably I'm mixing up things, but it's complicated because there are a lot of data: struct... I was thinking about making smaller structures with the fTime variable each so I can have attribute keyframes, light keyframes and buffer keyframes, then make the node structure look like

Data information