4 ms·
This is kinda what Entity Component Systems do - they implement in-memory relational database for game objects, handle dependenceis and allow your game logic co
by ajuc 5y ago
This is kinda what Entity Component Systems do - they implement in-memory relational database for game objects, handle dependenceis and allow your game logic code to run efficiently over them while still keeping the pretense of OOP :)
Why pretense? Because behaviors (Systems in ECS terms) are completely separated from data (Components) and data for different game objects (Entities) is kept together in regular or sparse arrays.
Encapsulation is nowhere to be seen, code is written to specify the components it depends on and run on these arrays.
ECS is very fashionable in gamedev lately as it allows for efficient multithreading, explicit depencencies for each subsystem, cache locality and trivial (de)serialization. Used together with handles (tagged indexes instead of direct pointers) it reduces likelihood of dangling pointers and other memory management bugs.
- tffgg 5y agoECS ist Standard for enterprise web apps as well
- sdeframond 5y agoI am curious as to what you are referring to. Are you thinking of redux-like architectures?
- tompazourek 5y agoI have seen some enterprise web apps, but they never used ECS. Can you please share more details about your experience?
- pphysch 5y agoMay be referring to the common 3 layer architectures (see Fowler's PoEAA) which map closely to ECS: Top layer is for "frontend", whatever that means for the product (UI, sound, simulation, etc.), the stuff with side effects. "Systems". Middle layer is purely functional, for business/domain logic AKA utility functions. The most liquid layer, but should not be confused as trivial. Bottom layer is where state (or a way to access & modify it) lives. Data access layer, component layer, etc.
- tompazourek 5y agoI don't think they really map that closely... But you might be right. Thanks.