5 ms·

> Enough with the ECS advocacy however. Entity/component/system sounds like model/view/controller. But I like to think of data/logic/presentation. The point b

> Enough with the ECS advocacy however. 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.

ehnto 5y ago
They are quite different concepts and certainly in practice. 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.
- dragonwriter 5y ago
  > I've never seen MVC used in anything but single-run applications that end with an discrete output. 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...
  - ehnto 5y ago
    That's interesting, I knew it was a pattern older than it's use in the web but hadn't given it much thought. There's certainly nothing inherent in either design that limits them to either use case.
    - slver 5y ago
      Keep in mind the "web" use of MVC originates with Ruby on Rails. Which actually significantly misunderstood what MVC is...
  - vbsteven 5y ago
    Single run VS state+loop is not the best description of the distinction between MVC and ECS. I look at it like this: 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.
- layoutIfNeeded 5y ago
  >I've never seen MVC used in anything but single-run applications that end with an discrete output. Wut? Every desktop GUI framework in widespread use is some variant of MVC (i.e. MVC, MVVM, MVP, whatever…).
orthoxerox 5y ago
ECS is not MVC. Components are data, systems are logic AND presentation, entities are lifetime management.
slver 5y ago
> Entity/component/system sounds like model/view/controller. 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).
- smitty1e 5y ago
  > model: data+logic 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.

ehnto 5y ago

They are quite different concepts and certainly in practice. 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.

dragonwriter 5y ago
> I've never seen MVC used in anything but single-run applications that end with an discrete output. 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...
- ehnto 5y ago
  That's interesting, I knew it was a pattern older than it's use in the web but hadn't given it much thought. There's certainly nothing inherent in either design that limits them to either use case.
  - slver 5y ago
    Keep in mind the "web" use of MVC originates with Ruby on Rails. Which actually significantly misunderstood what MVC is...
- vbsteven 5y ago
  Single run VS state+loop is not the best description of the distinction between MVC and ECS. I look at it like this: 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.
layoutIfNeeded 5y ago
>I've never seen MVC used in anything but single-run applications that end with an discrete output. Wut? Every desktop GUI framework in widespread use is some variant of MVC (i.e. MVC, MVVM, MVP, whatever…).

orthoxerox 5y ago

ECS is not MVC. Components are data, systems are logic AND presentation, entities are lifetime management.

slver 5y ago

> Entity/component/system sounds like model/view/controller. 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).

smitty1e 5y ago
> model: data+logic 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.