Hacker News new | past | comments | ask | show | jobs | submit login

Interesting.

I'm not fully convinced by components either, I don't like the idea of the bullet behaviour code having to check if "this entity has 'propeller' and 'rigid_body' components", as if the bullet behaviour code had to re-discover what a bullet was made of (BTW, this feels like a re-implementation of coarse-grained dynamic duck-typing for static languages).

This problem is less visible when the game logic is written in Lua, where dynamic duck-typing is the rule. I do write my game logic in C++/D, though, and the problem is perfectly visible.

The way you describe how you would do it raises a few questions ; because now it seems you can't process entities in a systematic/opaque way.

This implies that, say, the renderer has to loop over bullets, then to loop over doors, and so on. Each time a new entity type is added, this part of the code has to be modified, even though most entities might share the drawing code (e.g mesh).

This sequence of loops appears in many places, like collision checking, game logic update, save/load, etc. and all of them have to be updated when a new entity type is added.

Something in my understanding must be wrong, because the way you do it obviously works ; maybe the issues I just described isn't so problematic in practise?




No, because they share a base Entity class.


Thanks!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: