Wednesday, 20 November 2013

Entity Component System - A Breath Of Fresh Air

This week was a big week for me in many aspects. My game studio’s game just made a big milestone which lifted our spirits and helped subdue the game burnout. Also this week a brand new coding design was dropped on us with no warning. After working on our game for the past eternity I was starting to find a lot of flaws and headackes with the way I has to use code. Using higharcal design with a base game object is starting to get stale and inefficient in my opinion. If I have to do anything with the class “GameObject” it will be too soon. Any way enough venting, the design that was brought to my attention is called the “Entity Component system”. This design system is based around the entity and component object. The entity object just has an identification ID and a list of components. A Component is just a container for data. It is time to get into the details of what makes this system a breath of fresh air for me.

Entities and Components



The Entity Component System (ECS) is based on you guessed it entities and components. Entity is a general purpose object that makes up every object in your game. You could think of an entity as a GameObject. The entity class just has an identifier and a container that stores components. A component is just a storage container for data. Here is a quick design to see what a base entity and component would look like in code. [entity and component code here]
Unity an Example of ECS
Entities and containers do not have logic in them they are just used for data. All the game logic will be handled by component managers which will be covered later. Now this might be a hard concept to understand and some of my studio members are still not completely sure how this works. It is easier to understand visually with an example. The game engine Unity is based on this entity component system, and is a great example of using this design graphically. If you were to make a new entity in unity it would create a new blank entity with a unique identifier. This could be a name or a number it does not matter it is just a way to identify it from all the others. The entity would not have any components added to it. If we wanted to make this entity visible we would add a renderable component to the entity. This would then make the entity render able. If we wanted this entity to be a dynamic object then we would add a physics component to it so that the physics system would recognize it. To add them with a GUI you could just drag and drop the components into the entity and they could take effect.

 class Entity{  
 public:  
      virtual ~Entity(){}  
      void addComponent(Component* pComponent){  
           components.push_back(pComponent);  
      }  
      virtual void update(){}  
 private:  
      Entity(unsigned int id) : ID(id){}  
      unsigned int ID;  
      std::vector<Component*> components;  
 };  
 class Component{  
 public:  
      Component();  
      virtual ~Component(unsigned int pType): type(pType){}  
      virtual void update(){}  
 private:  
      // here is where you put all of your data and vars  
      unsigned int type;  
 };  

Systems

A system or manager would query through the entities and check to see if they have a specific component. If the enmity says that it has it then it will give the component to the system and the system will apply its logic to the component. An example of a system like this would be a rendering system. To make an entity renderable you would add the renderable component to it. When the rendering manager goes through all of the entities and asks if they have the renderable component the entity will say yes because the component was added. Once the entity confirms that it has the component then it will send the component to the manager where it will be rendered. But how does the renderer render a component? The renderable component could have a list of vertices stored in it. When the render manager takes the component it would render the vertices to the screen. This is how systems, entities and components communicate and function.

Igniting the Fire Again

I have wanted to make an engine framework for a long time but have never had the motivation to do so. In my second year I had to make an engine framework and at the start I was enjoying making it, but then game code came and pooped on everything and made it a complete mess. After that I have not had the motivation to make an engine framework. Now that I understand this design style it has motivated me to want to make an engine framework again. My first year second semester 2D game was a game that I enjoyed making with a base library that one of my professors threw together. I want to make a 2D engine that would have made making that game a lot easier. It would be a good way to use all of the knowledge that I have gathered since and use it. It would be nice to look at my 2D engine and the first year me could understand and use it easily and effective. Now all I have to do is find the time =/


No comments:

Post a Comment