3 ms·
This appears to be more-or-less the entity-component system (ECS) architecture as well.
by tel 6y ago
This appears to be more-or-less the entity-component system (ECS) architecture as well.
- shoo 6y agoI agree. Perhaps also known as "data-oriented design". Decompose entities into components by modelling the data in a normalised way, as is done when modelling for relational databases. Group together similar data as records in homogeneous arrays, and batch process it without need for OOP polymorphic branching etc. Further reading/viewing, somewhat gamedev oriented (as is the author of this article): Richard Fabian's Data-Oriented Design book https://www.dataorienteddesign.com/dodbook/ https://www.dataorienteddesign.com/dodbook/ ; Mike Acton's 2014 CppCon "data oriented design and c++" talk https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc This way of structuring applications may not be a good fit for all software development contexts. It may be a good fit for game development with high performance requirements, or similar kinds of situations.
- tel 6y agoThat's helpful, thanks! I've been learning about it in a simulation environment, not a game dev one. I think some, but not all, of the constraints are similar. I'll take a look at those references.
- DecoPerson 6y agoNah there’s far far more to ECS than just allocating this way. Put it this way: You can do ECS without this strategy, and you can do this strategy without doing ECS. Therefore: they are not conceptually related. However, they go really well together. (My cress: introduced/advocated-for ECS at two different game studios, with varying levels of success. One already used the handle strategy heavily, for all kinds of resources, but definitely wasn’t doing ECS.)