Adam Martin's 2007 articles offered three core concepts:
- Entity: A unique ID that tags each game-object as a separate item. Implementations typically use a plain integer for this.
- Component: All the data for one aspect of the object. Implementations typically use Structs, Classes, or Associative Arrays.
- System: All the code for the one aspect of the gameobjects, with each System running continuously as if it has a private internal thread, performing global actions on every Entity that possesses a Component of the same aspect as that System.
"Component" is used to mean both the template/OOP class that holds the data, and the individual instances of that template/class. When this is unclear, we usually say "Component-Type" to mean the class, and "Component Instance" to mean a single instance attached to a specific Entity.
"Aspect" is defined loosely. Originally, we recommended developers to start with "1 component-type per 1 System", but real-world projects rarely stick to this, often having multiple Component-types for a single System — and multiple Systems sharing individual Component-types.
(later updated to rename "System" to "Processor")