Just a quick update on the Entity Component System framework project! Yes, I’ve been working away on it, and it’s now running swimmingly. While I’m still working on some example projects using it, you’re more than welcome to download it and try it out for yourself. The docs (that is, the README) aren’t all that fleshed out, but the headers all have pretty solid explanations of what everything does. There’s only four of them, so it shouldn’t be too tough a read. https://github.com/hellocld/CLD-ECS
As you can see from the image above, I went ahead and made a logo for it. While I might be getting a bit too excited about things with that, I made it for a good reason; one which will be evident hopefully in the coming weeks. And those shapes in the logo weren’t just picked out of a hat. 😉
Finally, I’m confident enough in this simple framework that I also made a little landing page for it. Right now it doesn’t have much other than the logo that links to the GitHub project, but it’s something to keep an eye on. http://cldecs.hellocld.com/
In the past I’ve dabbled a bit with the component-entity system model of design, and with my recent endeavors in teaching myself C++ I thought it’d be a good project to create a simple CES framework. If you don’t know what the CES or ECS design model is, I’d recommend giving the Wikipedia article on it a read before continuing.
The approach I’m taking is very bare-bones, and for good reason IMO. I’d like it to be as simple as possible, so it doesn’t necessarily become restricted to being a “game engine”. Currently I’m using four objects in the framework:
- Component: The Component class is just a base for other custom Components that will simply store data. I’m using simple class inheritance here.
- Library: The Library will contain a database of all Entities and their corresponding Components. The database is an unordered map, with the key being an int that represents an Entity and the value being another unordered map that holds the Components. That “Component” map’s keys are the typeid of the Component object (so as not to store duplicate Component types) and a pointer to the Component itself. The Library also serves as a “Librarian” that can provide information on the Components and Entities; things like a vector of all Entities that contain Component X, a specific Component of a particular Entity, or whether or not an Entity contains a Component of type X. Creation and destruction of Entities is handled by the Library, as is addition and removal of Components to/from Entities.
- System: The Systems will be where the messiness comes in, but that’s all up to the developer using the framework. It will have the ability to communicate with the Library contained in the System’s World (see below), access all the Library’s public methods and alter the data in Components.
- World: The World is the encompassing object that holds a set of Systems and the Library they can access. It initializes all Systems and connects each to the Library. The World is also responsible for the main program loop that runs through each System one at a time, updating each.
I’m fairly certain that while I’ve got a good idea of how I want the framework to function I’m still a good ways off from having it in a relatively solid, functional state. For instance, I’m probably going to need to create some sort of messaging system so systems will have a better way of interacting with one another (Messages could easily be they’re own Component type).
You can follow the development of the framework at Github.