Game Engines 2: Components

Time for blog #2 for Game Engines! Today I'm going to be talking about one particular topic that has become very prominent in the Game Industry and in game engines in general: Component based systems!

So first of all what is a component based system? Essentially a component system relies on two things: Entities and Components. The Entity is the container for all the components and is basically an object in the game world. The entity only has to worry about having a tag and an ID (and even then, an ID is usually enough) to allow for developers to easily track down an entity in the system. On the other hand we have the Components in the system which is the meat of the object that can then make it unique. Components can range from things such as transformations to meshes to scripts and contain different values that allow the entity to interact with the game world.

So now that we know what an Entity and a Component are, what does this mean? Basically we can have a huge range of flexibility with our Entities. In previous system designs that rely heavily on inheritance we would have to deride from a long range of classes to create an entity that can do what we want (i.e. Entity->Character->Enemy->Flying Enemy->Drone) and we would have a harder time crossing over features from different classes. With components we would only have to worry about adding something such as a Flying component, Enemy component and any components that might be specific to the Drone enemy. This allows for anyone working with the engine to easily make an entity that can fit their needs (so long as they can make their own components).

That's the general summary of how an Entity Component System works on the surface. In my next blog I'm going to go into some of the lesser well-known components that you can use in an ECS (and that isn't currently implemented into 2LoC: Scripting!