{"id":6006,"date":"2017-11-23T16:10:00","date_gmt":"2017-11-23T16:10:00","guid":{"rendered":"http:\/\/www.gamasutra.com\/view\/news\/310237"},"modified":"2017-11-23T16:10:00","modified_gmt":"2017-11-23T16:10:00","slug":"blog-creating-an-awesome-game-design-pattern-in-c","status":"publish","type":"post","link":"https:\/\/sickgaming.net\/blog\/2017\/11\/23\/blog-creating-an-awesome-game-design-pattern-in-c\/","title":{"rendered":"Blog: Creating an awesome game design pattern in C++"},"content":{"rendered":"

The following blog post, unless otherwise noted, was written by a member of Gamasutra\u2019s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.<\/small><\/em><\/strong><\/p>\n

\n

Hi Folks.<\/p>\n

This is actually my first post on gamasutra\u00a0\ud83d\ude42 I am here pretty much every day and checkout cool posts, today is gonna be the day I add one by myself \ud83d\ude42 You will find the origial post here.<\/p>\n

In this article I want to talk about the Entity-Component-System (ECS<\/strong>). You can find a lot of information about the matter in the internet so I am not going to deep into explanation here, but talking more about my own implementation.<\/p>\n

First things first. You will find the full source code of my ECS in my github<\/a>\u00a0repository.<\/p>\n

An Entity-Component-System\u00a0\u2013 mostly encountered in video games \u2013 is a design pattern which allows you great flexibility in designing your overall software architecture[1]<\/sup><\/a>. Big companies like Unity, Epic or Crytek in-cooperate this pattern into their frameworks to provide a very rich tool for developers to build their software with. You can checkout these posts to follow a broad discussion about the matter[2,3,4,5]<\/sup><\/a>.<\/p>\n

If you have read the articles I mentioned above you will notice they all share the same goal: distributing different concerns and tasks between Entities, Components and Systems. These are the three big players in this pattern and are fairly loose coupled. Entities<\/strong> are mainly used to provide a unique identifier, make the environment aware of the existence of a single individual and function as a sort of root object that bundles a set of components. Components<\/strong> are nothing more than container objects that do not possess any complex logic. Ideally they are simple plain old data objects (POD\u2019s). Each type of a component can be attached to an entity to provide some sort of a property. Let’s say for example a \u201cHealth-Component\u201d can be attached to an entity to make it mortal by giving it health<\/em>, which is not more than an integer or floating point value in memory.<\/p>\n

Up to this point most of the articles I came across agree about the purpose and use of entity and component objects, but for systems opinions differ. Some people suggest that systems are only aware of components. Furthermore some say for each type of component there should be a system, e.g. for \u201cCollision-Components\u201d there is a \u201cCollision-System\u201d, for \u201cHealth-Components\u201d there is a \u201cHealth-System\u201d etc. This approach is kind of rigid and does not consider the interplay of different components. A less restrictive approach is to let different systems deal with all components they should be concerned with. For instance a \u201cPhysics-Systems\u201d should be aware of \u201cCollision-Components\u201d and \u201cRigidbody-Components\u201d, as both probably contain necessary information regarding physics simulation. In my humble opinion systems<\/strong> are “closed environments”. That is, they do not take ownership of entities nor components. They do access them through independent manager objects, which in turn will take care of the\u00a0entities and components life-cycle.<\/p>\n

This raises an interesting question: how do entities, components and systems communicate with each other, if they are more or less independent of each other? Depending on the implementation the answer differs. As for the implementation I am going to show you, the answer is event sourcing[6]<\/sup><\/a>. Events are distributed through an \u201cEvent-Manager\u201d and everyone who is interested in events can listen to what the manager has to say. If an entity or system or even a component has an important state change to communicate, e.g. “position changed” or “player died”, it can tell the \u201cEvent-Manager\u201d. He will broadcast the event and all subscriber for this event will get notified. This way everything can be interconnected.<\/p>\n

Well I guess the introduction above got longer than I was actually planning to, but here we are \ud83d\ude42 Before we are going to dive deeper into the code<\/a>, which is C++11 by the way, I will outline the main features of my architecture:<\/p>\n