Earlier quoted context omitted.
>"Nonsensical levels of generality is one of the classic OOP pathologies" I think it has nothing to do with OOP which I find very convenient for some domains and not so much or even opposite for others. These "Nonsensical levels" of anything is a disease which is called Architecture Astronauts Syndrome and victims apply it to any paradigm
OOP can be convenient for prototyping a game because you can just write new stuff at high velocity like "yeah a cow is a pig but it's brown and drops leather, a skeleton is a zombie that shoots arrows, and a client is just a server with graphics". Figuring out the right decomposition right from the start can be harder.
Introduction to Data-Oriented Design [pdf]
81–83 of 83 posts
Re: Introduction to Data-Oriented Design [pdf]
#82Re: Introduction to Data-Oriented Design [pdf]
#83Earlier quoted context omitted.
No it’s not an ad hominem. The first principles examination is you need an array of structs. If your goal is to ship a product you would use this proven technique. It’s shipped more AAA and small games than any other. The ECS is a hobby project which solves problems unrelated to your goal. (Making a cool ECS) And because it was not engineered with the goal of shipping you’re sitting on a pile of unknowns when you try…
Proven technique is an Appeal to Authority. You have offered no real first principal evidence for your claims. Here's some evidence in favor of flecs: I find value in its reflection and serialization system, as well as it's pipeline API. Games require far more than a bunch of arrays. The simulation code itself is dwarfed by the UI, VFX, animation and scene layout code. The APIs in Flecs have a lot of value for these…