Fast Entity Component System


  • Create a generic System class which stores Components as a Vector array, allows access to them, and processes its data when called.
  • Create an Entity Manager that re-uses expired entity id's, if possible, and facilitates the clean removal an entity by removing it from all systems.
  • Components are classes. Ideally, component classes do not have external methods, but that doesn't mean they aren't allowed.
  • The Entity is represented by an integer, not its own class.
  • The Entity's integer value is equal to the index of its data in any given system's object array. This allows "fast" access to its data. The biggest tradeoff is a potential for null values between "active" indices, bloating the object array.
  • A simple version can be seen in action at Open Processing.

Perhaps add the word "Index" into the name somewhere? Perhaps "Fast Entity-Indexed Component System" ?
I think it would help underlne the key innovative step in this approach — tmachine



  • Entity: An integer.
  • Entity Manager: A singleton class.
  • Component: A class with data.
  • System: A generic class with methods and an object array.
  • Component System: A singleton class that extends System using a specific Component class.


  • Entity: A handle shared by all systems. It has no idea what components it has.
  • Entity Manager: Prevents duplicate IDs from being handed out. Recycles IDs that have been removed from all component systems. Handles the removal of an entity from all component systems.
  • Component: Holds data of a specific type. If things get dirty (as rapid game development often does), it can have methods for other systems to work with that data, such as a vector class that can return its magnitude.
  • System: (This is a generic class, and never used directly) Manage an array of Components of a specified class, using the value of Entity as an index. Has methods to add, update, get, remove, and process that data.
  • Component System: Extends System with the Component's class. Almost always overrides the Process function.


Out of the box, it is only possible to process (or try to process) every object, in every system, each frame. But the framework also allows a system to process individual entities. This could lead to a "group" class that manages its own list of entity ID's, preventing wasted cycles on "blank" entries in systems. It would still use the Entity Manager to create and destroy entities.

Source Code for FECS Framework

Java - Note that this requires Processing. It can easily be ported to pure Java, however.