Entity/component/system sounds like model/view/controller.
But I like to think of data/logic/presentation. The point being that keeping these dimensions orthogonal is more imoprtant than how they are labeled.
Entity/component/system sounds like model/view/controller.
But I like to think of data/logic/presentation. The point being that keeping these dimensions orthogonal is more imoprtant than how they are labeled.
At it's barest, a controller organizes models and renders them into a view.
Again simplifying, an entity has components which describe it's functionality, and the entity can get passed through a system. The entity is the concept of the thing, and the components are it's features. The system uses the features to make decisions about how the entity interacts with the system.
I've never seen MVC used in anything but single-run applications that end with an discrete output. Whereas ECS is more often used in software with a perpetual state and loop, such as game engines.
Exceptions abound.
MVCs original use was GUIs, which are not “single run applications with a discrete output”, but instead “software with a perpetual state and loop”. Yes, its since been adapted to web use, which usually fits that single-run description, but still...
In MVC a typical interaction goes like this:
-> INPUT: user interacts with view
-> view triggers controller action
-> controller updates the model
-> controller passes model to view
-> OUTPUT: view changes
-> (rinse and repeat)
The important part here is that there is a single input that flows through the steps and generates output. This maps well to web frameworks where the input is an HTTP Request and the output is the Response. It also maps well to GUI frameworks where the input is a user interaction event and the output is changes to UI on screen. The perpetual "state and loop" for triggering the next input from the previous output is implementation detail and doesn't really matter for the pattern.ECS is different because it doesn't have discrete interactions converting input->output. Instead they are built up out of a number of systems all interacting with eachother. User inputs enter a system and that triggers a complex flow of other system interactions, eventually generating 0..N outputs.
Disclaimer: I have lots of experience using MVC in various domains, not that much with ECS.
Wut? Every desktop GUI framework in widespread use is some variant of MVC (i.e. MVC, MVVM, MVP, whatever…).
Maybe to someone who has no idea what ECS is. ECS is not three things named "entity", "component" and "system".
Instead you have entities separated into components which are transformed by one or more systems that operate on all of them in bulk.
There's literally no overlap between ECS and MVC.
> But I like to think of data/logic/presentation.
It's OK to think however you find it useful for yourself. But data/logic/presentation isn't MVC either.
If I have to use these terms, it'd be rather:
- model: data+logic
- view: presentation output processing
- controller: presentation input processing & mapping to model(s).
My point regarding orthogonality is that lif is better when the state is pure. Just the database table and its rows.
The logic functions operating on that state are better kept to map, filter, and fold as much as possible.