What is an ECS?

Honestly it might be more beneficial to do standalone research on this topic but I can understand that most articles that talk about what an Entity Component System are a bit complex and hard to follow if you come from a purely GameMaker background (at least that was the case for me).

ECS stands for Entity-Component-System. It's called that because those are the three buildings blocks for the architecture. In pure ECS, Entities are IDs that hold components, Components hold the data and only the data of various aspects of your game, and Systems run the core logic of your game doing work using the data in the components the entities are holding. Faulty-ECS is not a pure ECS. Here is how I've interpreted the architecture:

Entities

Entities are objects that are children of the Entity object. They hold different components that systems will manipulate within your game. Since Entities are just GameMaker objects, you can still use them in the traditional way. You don't have to put all your logic onto external systems. You can take a hybrid approach where entities can be set up to hold some, all, or none of their logic inside their own events. The choice is there and it's up to you to decide how often you want entities to tap into systems.

Components

Components are just constructor functions that hold some data and inherit from IComponent. Typically, components just hold data and only data. However there are hybrid approaches to components that allow components to process some logic, though you'll have to be careful as this blurs the line between components and systems. Personally I take the approach of defining functions on components if and only if they are useful in setting up the data or manipulating small parts of the data within those components, i.e. helper functions.

Systems

Systems are where all or most of the logic of your game lives. Individual systems are only interested in entities with a small subset of components that pertain to them. They will loop over and process all entities that match the subset of components they are interested in. Systems are constructors that inherit from ISystem. ISystem provides them with several functions to do work and these functions are matched with common events that GameMaker uses like beginStep, step, or roomStart along with several others. Systems are created in corresponding SystemManager objects prefixed with sys_. These basically ensure that the system functions run on the appropriate events and in the appropriate order. System managers inherit from the SystemManager object, and you can have multiple systems created on a system manager object. This is used to organize systems as you see fit (for example, a sys_rendering object might create a AnimationSystem, DepthSortingSystem, and a PostProcessingSystem).

Worlds

There is one more aspect that we need to discuss and that is Worlds. Worlds are objects that spawn certain system managers. So you can imagine having a world_main_menu object that spawns system managers which in turn spawns systems that only pertain to the main menu. We wouldn't need to spawn sys_player_stats when we're on the main menu, right? By using world objects, you can separate areas of your game that might work entirely differently to each other, and prevent systems from running that shouldn't be running.

Notes

• ECS architecture favors composition over inheritance and tries to stay away from Object Oriented Programming concepts. Although, in reality there is some overlap and both have their advantages or disadvantages depending on the situation.
• See https://github.com/SanderMertens/ecs-faq for more information.