Jump to content
  • Advertisement
Sign in to follow this  
Dominik2000

Component based architecture and messaging

This topic is 2113 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello,

 

I have a component based architecture with subsystems, which hold the component data and implement the game logic. Now a great problem is, how to implement a messaging system.

 

I have a message dispatcher system, with template where every message type registers it's own eventhandler. On Dispatch every function in the list will be called. I don't like this, because it's hard to delete one listener and I don't get how a message queue could be implemented.

 

So I think of a design like that every subsystem has it's own queue and a high level system (e.g. world manager, ...) write to this queue if anything needs to be updated. One problem is, I think, that every high level system needs to know about the low level systems.

 

Is this a good approach? How do you think about coupling/decoupling, because coupling would be the case in my idea.

 

Dominik

Share this post


Link to post
Share on other sites
Advertisement
Most people will tend towards decoupling out of efficiency, being easier to change components. Coupling can work, and can (I stress 'can') be faster to implement as well as be faster overall, however your system will be less robust and will be far more fragile.

Your second idea does not require 'coupling' as I would understand it. Have you looked at Service Oriented Architectures? I think it would fit well and is a decoupled system.

Share this post


Link to post
Share on other sites

I think, one great possibility is to go the third way, because every system can take the event that it can consume, but how can I implement this, without one big switch in every system. I think this is a very bad solution. Should I static_cast the event parameter?

In my event system (unbufferd) I have function calls, so it's easy to have the right parameter. But a solution with a big switch and a static_cast is simply ugly I think.

 

I think you have this event queue in the game loop class?

Share this post


Link to post
Share on other sites

I have thought about a basic architecture, what I need in my game. I want a car to go to different points controlled by AI.

 

So I think I have following low level systems: Render system, Physic system (optional), Position system, AI system, Waypoint system.

High level system would be exactly one Entity sytem, which has references to all the low level systems, because it needs to know everything from above.

 

Is this correct? Is a component system structured this way?

Share this post


Link to post
Share on other sites

There are numerous ways to structure your events and they don't necessarily have to be classes.  Remember, one could easily just treat the event queue as a raw buffer of data and with some bookkeeping constructs, one could easily iterate the events perhaps by id within the raw buffer.  Events after all are just data, right? :)

 

The important thing to realize with a callback mechanism is that when you execute the callback immediately when the event happens, you often trash your instruction and data caches and this is particularly bad in games.  For example event A fires callback A.  While processing callback A, a condition is met that must fire event B that in turn fires callback B.  Inside callback B, a condition is met that must fire another event.  You can quickly see how your instruction/data caches can get trashed.

 

Just make sure that if you move forward with such an event system that it offers both asynchronous and synchronous invocations of your callbacks.  In the case of asynchronous, you queue up the events and a dispatch call at some future point issues all the callbacks in a loop where synchronous would fire the callback for a specific event at the time you emit the event.

 

You can place this queue where-ever is applicable for your code base.  In my engine, I have a framework class which exposes a number of core engine components through the framework interface since the framework interface is generally injected into all classes during initialization or construction.

 

 

 

I think, one great possibility is to go the third way, because every system can take the event that it can consume, but how can I implement this, without one big switch in every system. I think this is a very bad solution. Should I static_cast the event parameter?

In my event system (unbufferd) I have function calls, so it's easy to have the right parameter. But a solution with a big switch and a static_cast is simply ugly I think.

 

I think you have this event queue in the game loop class?

Share this post


Link to post
Share on other sites

I have thought about a basic architecture, what I need in my game. I want a car to go to different points controlled by AI.

 

So I think I have following low level systems: Render system, Physic system (optional), Position system, AI system, Waypoint system.

High level system would be exactly one Entity sytem, which has references to all the low level systems, because it needs to know everything from above.

 

Is this correct? Is a component system structured this way?

 

I'd say a bit of this is a matter of taste. 

 

There is no right or wrong answer on how to design a component system because while games are starting to shift and ship with some component system like concepts, it's still something that depending on the development team and architect who is at the helm of the design process; it all varies and sometimes significantly.

 

I generally prefer the idea that the entity framework is a core component to the engine.  The entity framework exposes an entity manager along with a component system interface.  The developers create derived classes of the component system interface for whatever logic they want to implement for the designers.  These component systems are then registered with the entity manager at start-up, allowing the entity manager to build a repository of meta data about the available components, properties associated with the components (useful for editors), etc.  

 

The beauty is that with the entity manager having all this metadata at it's finger tips, the engine simply exposes the entity manager to the remainder of the application.  Internally, the entity manager can delegate creation and destruction of components to the appropriate component systems without the developer having to find the right system and call it directly.  Our component system interface is also designed so that the component system can interact with our core engine framework and submit jobs to the task manager, register themselves as callback listeners to various systems, etc.

Share this post


Link to post
Share on other sites

 

I have thought about a basic architecture, what I need in my game. I want a car to go to different points controlled by AI.

 

So I think I have following low level systems: Render system, Physic system (optional), Position system, AI system, Waypoint system.

High level system would be exactly one Entity sytem, which has references to all the low level systems, because it needs to know everything from above.

 

Is this correct? Is a component system structured this way?

 

I'd say a bit of this is a matter of taste. 

 

There is no right or wrong answer on how to design a component system because while games are starting to shift and ship with some component system like concepts, it's still something that depending on the development team and architect who is at the helm of the design process; it all varies and sometimes significantly.

 

I generally prefer the idea that the entity framework is a core component to the engine.  The entity framework exposes an entity manager along with a component system interface.  The developers create derived classes of the component system interface for whatever logic they want to implement for the designers.  These component systems are then registered with the entity manager at start-up, allowing the entity manager to build a repository of meta data about the available components, properties associated with the components (useful for editors), etc.  

 

The beauty is that with the entity manager having all this metadata at it's finger tips, the engine simply exposes the entity manager to the remainder of the application.  Internally, the entity manager can delegate creation and destruction of components to the appropriate component systems without the developer having to find the right system and call it directly.  Our component system interface is also designed so that the component system can interact with our core engine framework and submit jobs to the task manager, register themselves as callback listeners to various systems, etc.

 

 

I like your architecture and edited my architecture diagram to this:

http://i40.tinypic.com/2wggbuu.png

 

So I think, it's very similar to your description.

Share this post


Link to post
Share on other sites

I like your architecture and edited my architecture diagram to this:

http://i40.tinypic.com/2wggbuu.png

 

So I think, it's very similar to your description.

 

 

The only thing I'd caution you and possibly others about from your diagram is what you call Render System.  I often consider the rendering system the renderer, the system that interacts with OpenGL or DirectX.  The rendering system is typically something exposed by the engine itself much in the same light Physics, Input, Platform I/O, Networking, and Audio are exposed.  

 

Then you create specialized component subsystems you register with the entity framework that handle specialized behaviors.  This way you can have many component subsystems that perhaps handle specific rendering features, allowing each of those component subsystems to interact with the engine's rendering system.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!