• entries
31
55
• views
46645

# ECS is officially the bomb!

2416 views

Over the last week and a half, I have been working on my own ECS framework. This is a side project away from my main voxel game, but it is something I wanted to do in order to be able to improve my productivity with making games more quickly. Inspired by Phil's Bomberman tutorial, I have implemented my own Bomberman clone with my own made-from-scratch ECS framework (though some conventions and names were adapted).

[size=2]Bomberman-like (brand new genre) game in progress. Using open source sprites but will change eventually.

My own framework has less code than Phil's but as long as the whole game still works on top of it, I would prefer that. Because right now, I don't need two Entities to check if they are exactly the same, or don't need to serialize them for other purposes. And I certainly don't need scripts at the moment.This framework has gone through two main iterations. They differed mostly in how Components are stored in the game.

As you may know in an Entity-Component-System framework Components are just simple data containers, which don't have any game logic, but are mutable by the game logic code, which resides in the Systems. Entities in my framework do not exist at all as classes, but are rather just numbers implied in Components as you'll soon see.

# Framework Structure

The ECS framework in its current state consists of your typical Component and System base classes, which you can build specific Systems and Components from. Here are the important data structures:

• A Dictionary of Component arrays indexed by enum. Usually a small amount of different types.
• Component arrays which are accessed by index, so constant time here.
• Systems take references of important Component arrays. Iterating them takes linear time.
• List of Systems which are always executed in the order that they were added.
• Static array of Messages in Systems. For now, they are just being created by the Input System. Could possibly be made non-static.

The main point of setup and entity processing comes from the SystemManager class, which stores a list of all the different Systems, and calls their Draw and Process function in the game loop.

This class also has an instance of an EntityManager class, which is passed to the System constructors. The EntityManager class is where all the Component arrays are stored (as the base Component class), and where the Systems get all the Components they need. Components are pooled at startup, setting each array to a fixed sized X for max number of entities (though in C# it's straightforward to resize an array if needed).

The arrays themselves are in a Dictionary, using a Enum for Component type as key. They are arrays of base classes, but they added in as derived classes.public Dictionary components { get; private set; }// Add Tile Position componentscomponents.Add(ComponentType.TilePosition, new Components.TilePosition[maxEntities]);
This makes it possible to re-cast them back into their derived classes, but fortunately we would only have to do this on startup. Systems get the arrays of Components they need upon initialization, cast to the the proper type.// Inside a System that uses Collision and TilePosition componentsComponents.Collision[] collision;Components.TilePosition[] tilePosition;public CollisionSystem(EntityManager entityManager) : base(entityManager) { // Load important components collision = components[ComponentType.Collision] as Components.Collision[]; tilePosition = components[ComponentType.TilePosition] as Components.TilePosition[]; }
No further casting is needed for entire arrays after this point. The only casting that is done while the game is running is for getting certain Components at a given index.

# When an ECS is more like a CS

Not dealing with Computer Science, but dealing with Components and Systems only. There are no entities in the framework, or at least not as objects. There is no Entity class, but instead entity IDs are stored in the components themselves and also referred to indirectly by the array indexes. The Components are access sequentially by the Systems and you can be sure that any Components in the same location of their respective array together make up an entity.

The EntityManager also has as an integer variable, TotalEntities, for the total amount of entities active in the game. It tells each System how far into the Component arrays it should iterate. An entity is "removed" by replacing the removed entity's components with the components of the last active entity in the array. TotalEntities is reduced by 1, and this is the new index marker to tell the EntityManager where it should add Components to make a new entity.

Since arrays are fixed size, the amount of entities should not exceed the size provided in the pool. You can usually easily test and find out what a suitable size is for simpler games. I want improve this in the future by making the EntityManager resize the arrays to a much larger size if it should reach the limit (which should generally be avoided anyways to maintain good performance).

# Component Organization

In the first iteration, the framework had arrays of each Component type, as concrete classes. Each derives from a base Component class, but the arrays are set up as the derived Component classes. So you had arrays of different classes named spriteComponents, screenPositionComponents, etc. This was inflexible for two reasons. First, adding a new component type meant also adding code for it to do a type check in the function to "Add" an entity.// Get proper EntityPrefab methodType prefabsType = typeof(EntityPrefabs);MethodInfo theMethod = prefabsType.GetMethod("Create" + templateName);// Call method to create new templatenewTemplate = (EntityTemplate)theMethod.Invoke(null, new object[] { nextEntity });// Check every array for proper insertion foreach (Component component in newTemplate.componentList) { if (component is Components.Sprite) components.components[ComponentType.Sprite][nextEntity] = (component as Components.Sprite); if (component is Components.Bomb) components.bomb[nextEntity] = (component as Components.Bomb); if (component is Components.Collision) components.collision[nextEntity] = (component as Components.Collision);// Etc...}
This has been improved since, and now adding Components to an array doesn't require manually going through every possible Component type.// Check every array for insertionforeach (Component component in newTemplate.componentList) components[component.type][nextEntity] = component;

# Enity Prefabs

Every game using ECS benefits from having pre-assembled entities to use right off the bat. It's a logical way to plan the rules of your game and what kind of game objects it will have. I use a small class called EntityTemplate which stores a list of Components. A class called EntityPrefab contains different methods (CreatePlayer, CreateSolidBlock, etc.) to return a new copy of a template, and its Components are added to the pool.

You still have to invoke EntityPrefab methods since the methods are dynamically chosen with the "templateName" String parameter. I would like to replace it with just adding prefabs to a List of EntityTemplates, so you just select them from a list. In hindsight this should have been the more obvious approach but I was taking from Phil_T's approach to making entity prefabs.

# Getting into the Game

I will talk about this in the next post, since I've probably gone long enough already! Then I'll be able to go into more detail on how the game uses the framework. But since the first draft of this post and now, I have also made some more improvements on the ECS code and ironed out some game bugs too. The game is getting closer to being playable!

## 1 Comment

. An entity is "removed" by replacing the removed entity's components with the components of the last active entity in the array. TotalEntities is reduced by 1, and this is the new index marker to tell the EntityManager where it should add Components to make a new entity.
I like the idea :D

## Create an account

Register a new account