3 ms·
Splitting objects into components and pursuing a more data-oriented design is absolutely the way to go. However, if you're not very careful this approach won't
by bnastic 15y ago
Splitting objects into components and pursuing a more data-oriented design is absolutely the way to go.
However, if you're not very careful this approach won't scale past mobile games with a few dozen objects - too many iterations to update all the components, or to find one of a particular type (e.g. the physics component), killing your caches in the process (it's more complicated than that, but this is just the gist of it). A well known games company used this exact approach for their AAA engine (on a couple of games) and it was the no.1 reason for a sluggish frame rate. It took considerable effort to get some caching implemented so that there weren't as many indirect jumps around the code.
Splitting objects into components which are then kept physically close in memory and updated in batches is another story, but that almost anti-OOP in nature.