• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Dominik2000

Component based architecture and messaging

19 posts in this topic

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.
1

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?

1

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?

1

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?

1

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.

1

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.

1

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.

1

Share this post


Link to post
Share on other sites

I just wanted to ask if you've considering not using an event/messaging system?  Considering you have systems that will operate over components, and these components contain some data, why not have these "events" simply be a new component, or data in a component?

 

For whatever event you think an entity or component might need, you should be able to solve it using data in the component, or a specific component type.

 

For example, if you want to have a "collision event" why not create a collision component, and store it in the entities that are colliding.  then, when you run your collision system, it will run over those entity's with the collision component.

 

At least consider it.  I'm not saying you must use it, but I believe it to be a viable solution.

1

Share this post


Link to post
Share on other sites

Instead, I use a simpler approach. All my component systems know the required dependencies and explicitly synchronize components once per frame.

 

That's what I do too, and I think it's a reasonable approach. It's fine for that dependency to be encapsulated in the systems.

 

 

 


I have edited the diagram, now I have a render manager, and a render system component. It's better I think, what I don't know is, if the waypoint system should be a system or manager. It' has notihing to do with the entity itself... Hmm....

 

When you say "it has nothing to do with the entity itself", it makes me wonder if you fully understand the point of an entity-component-system framework.

 

In my view, all game objects should be entities. Not all entities have to have the same set of components - in fact most entities will just use a few. The waypoint has nothing to do with the player entity, say. But it is its own entity. I would think you would have a waypoint entity that is comprised of a Position and Waypoint component (and a Render component?). Or possibly the Waypoint component could describe a full series of waypoints itself (that would make it less trivial for them to be rendered, but then you wouldn't need some other component/entity that is responsible for connecting waypoints together in a path.

 

In your diagram, I would also question the lack of an InputSystem. Surely entities will need some sort of Component that describes how they are controlled - e.g. what input they respond to. So just like you have a RenderComponent and RenderSystem, you might want an InputComponent and InputSystem in addition to your InputManager which performs more low level/platform-specific tasks.

 

Also, you have a box called "Logic" above your engine. What do you envision going in there? I think the bulk of game logic should be in the systems or in individual scripts attached to the entities.

Edited by phil_t
0

Share this post


Link to post
Share on other sites

I like the idea to remove the event system. The sync of the position between the components was the problem, and the reason to not remove the event system. I think I understand Reitanos approach.

 

 

 


In my view, all game objects should be entities. Not all entities have to have the same set of components - in fact most entities will just use a few. The waypoint has nothing to do with the player entity, say. But it is its own entity. I would think you would have a waypoint entity that is comprised of a Position and Waypoint component (and a Render component?). Or possibly the Waypoint component could describe a full series of waypoints itself (that would make it less trivial for them to be rendered, but then you wouldn't need some other component/entity that is responsible for connecting waypoints together in a path.

 

Yes but I want to have one place to store all waypoints and pathes to other waypoints. In my opinion every entity has it's own waypoint component. So I have much duplicate data in store...

 

 

 


In your diagram, I would also question the lack of an InputSystem. Surely entities will need some sort of Component that describes how they are controlled - e.g. what input they respond to. So just like you have a RenderComponent and RenderSystem, you might want an InputComponent and InputSystem in addition to your InputManager which performs more low level/platform-specific tasks.

 

Yes I don't have drawn the Input system, sorry for this. And how should I do this without event messaging? How could I exit the main loop?

 

 

 


Also, you have a box called "Logic" above your engine. What do you envision going in there? I think the bulk of game logic should be in the systems or in individual scripts attached to the entities.

 

E.g. I don't know where to put my money system. This I would place in the logic. Or is this another system?

Edited by Dominik2000
0

Share this post


Link to post
Share on other sites


E.g. I don't know where to put my money system. This I would place in the logic. Or is this another system?

 

What do you envision your money system doing? It's hard to give an opinion without knowing what functionality you require.

 


Yes I don't have drawn the Input system, sorry for this. And how should I do this without event messaging? How could I exit the main loop?

 

I'm sorry, I'm not really sure what you're asking here. During your update tick, your InputSystem should be able to query what key/mouse/gamepad events have taken place since the last tick.

 


Yes but I want to have one place to store all waypoints and pathes to other waypoints. In my opinion every entity has it's own waypoint component. So I have much duplicate data in store...

 

You really should avoid any duplicate data. Without knowing more about how your waypoints are created/used/modified (are they static points on a map? Is the player interacting with the game to create them? Is the AI using them to move game objects along a path?), it's hard to offer advice. You could certainly make your way-points completely separate from your entity-component-system architecture - if that makes sense. But if you find, say, that you're suddenly writing a ton of code to synchronize the game entities with your waypoint manager, then maybe it makes more sense to have them tightly integrated with your ECS.

 

Try listing out the various scenarios involving waypoints. For instance: "the user adds a waypoint to his character's path with the mouse", "some way-points are drawn as floating white flags", "a character following a path of waypoints is killed (what happens to the waypoints)". Then figure out a design that makes all this functionality the most straightforward and easiest to implement.

0

Share this post


Link to post
Share on other sites


E.g. I don't know where to put my money system. This I would place in the logic. Or is this another system?
 
What do you envision your money system doing? It's hard to give an opinion without knowing what functionality you require.

 

In my game I want to set a building on an user defined place, that means he can choose, what to build on a gui, and then place it with the mouse cursor. So the money system has to check, has the user enough money, to buy this building, and if yes, to substract the defined price.

 


Dominik2000, on 30 Sept 2013 - 3:19 PM, said:

Yes I don't have drawn the Input system, sorry for this. And how should I do this without event messaging? How could I exit the main loop?
 
I'm sorry, I'm not really sure what you're asking here. During your update tick, your InputSystem should be able to query what key/mouse/gamepad events have taken place since the last tick.

 

My fault, dumb question.

 


Dominik2000, on 30 Sept 2013 - 3:19 PM, said:

Yes but I want to have one place to store all waypoints and pathes to other waypoints. In my opinion every entity has it's own waypoint component. So I have much duplicate data in store...
 
You really should avoid any duplicate data. Without knowing more about how your waypoints are created/used/modified (are they static points on a map? Is the player interacting with the game to create them? Is the AI using them to move game objects along a path?), it's hard to offer advice. You could certainly make your way-points completely separate from your entity-component-system architecture - if that makes sense. But if you find, say, that you're suddenly writing a ton of code to synchronize the game entities with your waypoint manager, then maybe it makes more sense to have them tightly integrated with your ECS.
 
Try listing out the various scenarios involving waypoints. For instance: "the user adds a waypoint to his character's path with the mouse", "some way-points are drawn as floating white flags", "a character following a path of waypoints is killed (what happens to the waypoints)". Then figure out a design that makes all this functionality the most straightforward and easiest to implement.

 

Waypoints will be set on placing buildings in the game (buildings can have waypoints, the user can place also streets). I haven't exactly figured out, how to save this data best. I think that I should have one data store where all the waypoints and pathes to other waypoints are stored, and the entity has a component where the waypoints, it has to drive along, are stored. This global waypoint store needs functionality to calc the best way to one defined waypoint. Maybe it's good to have also a waypoint manager where to store and a waypoint system with components to calculate the way.

 

Is this enough information? 

0

Share this post


Link to post
Share on other sites


In my game I want to set a building on an user defined place, that means he can choose, what to build on a gui, and then place it with the mouse cursor. So the money system has to check, has the user enough money, to buy this building, and if yes, to substract the defined price.

 

Checking a value and subtracting it seems like a fairly trivial operation - so if that's all it is, I don't think it merits a system. Taking a stab at it: I would think that there would be player entity that has a "PlayerInfo" component which has a Money property (among other things that are specific to player entities). The code that runs the GUI for choosing buildings would operate in part off of the PlayerInfo component. That code can just check the Money value to see which buildings are available for the player to build, etc..

 

Note that by "player entity", I don't mean the objects that are owned by players, but an entity that represents the player overall. For instance, if there were 2 players: human vs AI, then there would be two of these entities.

 


Waypoints will be set on placing buildings in the game (buildings can have waypoints, the user can place also streets). I haven't exactly figured out, how to save this data best. I think that I should have one data store where all the waypoints and pathes to other waypoints are stored, and the entity has a component where the waypoints, it has to drive along, are stored. This global waypoint store needs functionality to calc the best way to one defined waypoint. Maybe it's good to have also a waypoint manager where to store and a waypoint system with components to calculate the way.

 

Well I can't really suggest anything concrete from that. It sounds like a fairly complicated setup. If you are having trouble coming up with a design, you might want to try prototyping something to see where "gotchas" come up.

1

Share this post


Link to post
Share on other sites

My advice is that of decomposing the engine in libraries designed with the principles of middlewares: fully decoupled, configurable, robust, reusable, testable. Then, build an entity/component framework at a higher level with a common API for creating, destroying, updating and synchronizing components of any type.

 

With that in mind, you would first develop an AI library with support for steering behaviours, waypoints, pathfinding etc. Have a look at commercial or open source AI libraries for inspiration. Among other things, the AI library is responsible for allocating, destroying, loading, saving and updating AI primitives. AI data and code, being fully decoupled, are optimal and do not suffer from the usual pitfalls of overly generic code.

Then, as part of the entity framework, you would have one component system per AI primitive: an AIAgentComponentSystem, an AIWaypointComponentSystem etc. These systems internally communicate with the AI library. They also synchronize AI components with other components like the TransformationComponent; coupling is at the entity level, not the library level.

 

In your case, an entity moving around the scene following a path could be configured as follows:

<entity name="player">
  <component class="Transformation"/>
  <component class="AIAgent"/>
    <wayPoint>ID</wayPoint>
  </component>
  <component class="Mesh"/>
  <component class="Script"/>
</entity>

The AIAgent component internally owns an AI Agent managed by the AI library. It syncs the agent position with the Transformation component which is then syncronized with the Mesh component for visualization. The Script component contains game logic and allows you to configure the pathfinding at run-time based on game events (i.e: switch pathfinding on/off or pass control to physics).

Then, if desirable, you would have an entity per AI waypoint:

<entity name="waypoint 0">
  <component class="AIWayPoint">
    <ID>423432423</ID>
    <file>waypoint0.dat</file>
  </component>
</entity>

Note that waypoints do not necessarily have to have an associated component if you do not need to manipulate them with the component API.

Please let me know if you need further clarifications as I've written this in a rush.

1

Share this post


Link to post
Share on other sites

Hmm, this is also a interesting idea.

 

A little bit more clarification is needed. In my diagram the systems will be removed and the entity manager has only components? The AI libary will offer a pointer to it's managed AI Agent and this will be stored in the component?

 

It's not completly clear to me.

 

Dominik

0

Share this post


Link to post
Share on other sites

 

A little bit more clarification is needed. In my diagram the systems will be removed and the entity manager has only components? The AI libary will offer a pointer to it's managed AI Agent and this will be stored in the component?

Hi Dominik, let me show you the organization of my Visual Studio solution in this case:

Projects:
- AI library: re-usable, fully decoupled and configurable, could be plugged in other engines
- Entity/component framework: the framework for the management of scenes, entities and component systems.
- AI module: an engine module which, among other tasks, initializes the AI library and adds AI component systems to the entity framework. The AI library is injected as a dependency into them.

The AI library allocates and returns instances of AI agents. In my component framework, there is no Component class (one of my key requirements) and everything can be a component so the AI agent pointer is managed directly. If you have a Component class, then you'll need an AIAgentComponent proxy that stores the AI agent pointer and dispatches calls to it.

 

Please let me know if you have other questions.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0