4 ms·
ECS systems for the gaming world are somewhat like this. There is the core ECS framework and then the systems and entity's integrate with each other
by blackth0rn 3y ago
ECS systems for the gaming world are somewhat like this. There is the core ECS framework and then the systems and entity's integrate with each other
- spookie 3y agoECS is incredible. Other areas should take notice
- whstl 3y agoAgreed. I find that we're going in this direction in many areas, games just got there much faster. Pretty much everywhere there is some undercurrent of "use this ultra-small generic interface for everything and life will be easier". With games and ECS, microkernels and IPC-for-everything, with frontend frameworks and components that only communicate between themselves via props and events, with event sourcing and CQRS backends, Actors in Erlang, with microservices only communicating via the network to enforce encapsulation... Perhaps even Haskell's functional-core-imperative-shell could count as that? I feel like OOP _tried_ to get to this point, with dependency injection and interface segregation, but didn't quite get there due to bad ergonomics, verbosity and because it was still too easy to break the rules. But it was definitely an attempt at improving things.
- gigatexal 3y agoECS?
- vacuity 3y agoEntity-component-system paradigm. Compared to OOP, ECS is more "data-first". It's like a database of components (attributes such as Position, Velocity, Player) with entities (simple integer identifiers) as keys. Systems are functions that query for components and perform actions on them. See Shipyard, enTT, Bevy, flecs, etc. The design space is still evolving.
- gigatexal 3y agoAs a database guy I really can get around this. OOP hurts my head sometimes when the hierarchies get too deep.