4 ms·

That inheritance structures is bad, leading to very highly coupled designs that are hard to change, has been similar discovered by many in line-of-business ente

by bni 8y ago

That inheritance structures is bad, leading to very highly coupled designs that are hard to change, has been similar discovered by many in line-of-business enterprise software. Some claim (Like Gosling) that inheritance was never a major point of OOP and that it has been overused. What do you mean by "tag" here. Is a "tag" implemented as a class in C++? Do you know of an example in real code that is open source, the the curious can study?

TeMPOraL 8y ago
> What do you mean by "tag" here. Is a "tag" implemented as a class in C++? Google for "ECS", or "Entity-Component-System". It's a sorta-pattern for what I described. I say sorta, because everyone has a slightly different idea of how it's supposed to be implemented, but typically, entities are just dumb containers for (instances of) components, the components store data & type info, and systems mutate those components. So e.g. an asteroid in a game of Asteroids would consist of e.g. "kinematics" component, and "sprite" component, and a "collider" component. If you wanted that asteroid to drop a powerup on death, you'd add "drops powerup" component to it, possibly at runtime. Components may or may not be implemented as classes, and the aggregation may or may not be direct. In small games where I used this (in Common Lisp), components were classes, and each entity object had a list of instances of those components. This was a naïve approach, but got the job done. A more performant implementation might look like this: each component is a struct, and gets a dedicated array of all instances; each entity only has a) tags of the types of components it consists of, and b) indexes into the "components" array. This optimizes for data locality, especially for more isolated systems. For instance, the physics system can now just loop over the array of "kinematics" components, and mutate their state, without knowing anything about actual game objects - and all the data necessary for updating physics for all game objects are close together in memory, reducing cache misses and allowing for other optimizations. Note how this is a complete inversion of OOP - components are now storing just state, all behaviours get segregated into systems that operate on those components in batch mode, and entities exist only to tell you which instances of components together form a game object. I don't have any reference C++ implementation handy to show, but if you read up on ECS, you're bound to find something.

by bni 8y ago

TeMPOraL 8y ago

> What do you mean by "tag" here. Is a "tag" implemented as a class in C++? Google for "ECS", or "Entity-Component-System". It's a sorta-pattern for what I described. I say sorta, because everyone has a slightly different idea of how it's supposed to be implemented, but typically, entities are just dumb containers for (instances of) components, the components store data & type info, and systems mutate those components. So e.g. an asteroid in a game of Asteroids would consist of e.g. "kinematics" component, and "sprite" component, and a "collider" component. If you wanted that asteroid to drop a powerup on death, you'd add "drops powerup" component to it, possibly at runtime. Components may or may not be implemented as classes, and the aggregation may or may not be direct. In small games where I used this (in Common Lisp), components were classes, and each entity object had a list of instances of those components. This was a naïve approach, but got the job done. A more performant implementation might look like this: each component is a struct, and gets a dedicated array of all instances; each entity only has a) tags of the types of components it consists of, and b) indexes into the "components" array. This optimizes for data locality, especially for more isolated systems. For instance, the physics system can now just loop over the array of "kinematics" components, and mutate their state, without knowing anything about actual game objects - and all the data necessary for updating physics for all game objects are close together in memory, reducing cache misses and allowing for other optimizations. Note how this is a complete inversion of OOP - components are now storing just state, all behaviours get segregated into systems that operate on those components in batch mode, and entities exist only to tell you which instances of components together form a game object. I don't have any reference C++ implementation handy to show, but if you read up on ECS, you're bound to find something.