Quantcast
Channel: GameDev.net
Viewing all articles
Browse latest Browse all 17825

base class for every game object : bad practice?

$
0
0
In my Entity-Component-System, every entity has Com_OwnerShip component. Com_OwnerShip = can own [0,∞) entity / can be owned by [0,1] entity For example :- a rocket OWN 1 physic object + 3 graphic object a rope OWN 10 physic object + 10 graphic object a physic object OWN 1 Bullet(R) physic internal object a game chunk OWN 16*16*16 blocks Here is a way to implement it (can be optimized further):- class Com_OwnerShip{ std::vector<Com_OwnerShip*> ownees; Com_OwnerShip* owners; }; At the end of every time step, I list every owner that was marked as to be destroyed, then mark all corresponding ownee entities as to be destroyed. The process is propagative. Then, I delete all "to be destroyed" entity in a batch-style. I have used it in a few prototypes and always find that it is very convenient. However, I feel that it is probably a bad practice. It probably share the disadvantage of Base_Game_object in OOP. (?) It costs a little more memory, not modular, too wildcard, too "duck-typing". It is a dirty-design (?). Nonetheless, it is better than Strong-Pointer (std::unique_ptr) because I can control entity/component deletion very easily. Is it a good practice? What are alternative approaches? Am I too nervous?

Viewing all articles
Browse latest Browse all 17825

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>