4 ms·

Regarding the camera with hitpoints, is there a name for that class of bug? Poorly thought out code reuse? Overly specific inheritance? A similar seeming bug i

• tinco 11y ago
  It's inherent to common game architecture. Far out the most flexible way of dealing with the multitude of complex entities in a game is to not work with inheritance but rather with 'components'. Ideally this means that an entity is nothing more than a UUID for which data is stored in component tables (a la relational databases). Unfortunately that approach is rather cumbersome to reason about and brings with it unhandy syntax requisites. Given an entity UUID, how do you get a value for some property? It would be component_table_get(health_components, entity_id)->hitpoints. Or something similar. (note: what happens if you accidentily call that function on a entity_id for which no health_components entry exists?) The alternative which is really fine for smaller games and which often leaks into the codebase of larger games, sometimes for performance reasons is to make the entity a struct which has some members common to all entities. Now you can do entity->hitpoints, but the downside is that every entity, including abstract game components such as the camera also have hitpoints. If you're curious why games don't do inheritance (anymore) look up articles about Component Entity Systems, they usually do a good idea of explaining why games are too complex for inheritance.
  • golergka 11y ago
    > Unfortunately that approach is rather cumbersome to reason about and brings with it unhandy syntax requisites. Given an entity UUID, how do you get a value for some property? It would be component_table_get(health_components, entity_id)->hitpoints. Or something similar. (note: what happens if you accidentily call that function on a entity_id for which no health_components entry exists?) I work with Unity engine (which uses exactly that model), and in good code these problems don't arise — or, rather, these checks are meaningful and actually represent the logic, rather then being "unhandy syntax requisite". Imagine that you have a lava object with a trigger collider (that means that it doesn't influence the physics) and a Lava custom component (MonoBehaviour) on it. In `OnTriggerEnter` method of Lava you run `var health = GetComponent<Health>()` method on GameObject that entered lava and determine if that thing is something that can be damaged — because, quite possibly, it is a camera (as in that example) and the method will return null. And then, if it is something that you can damage, then you can use the `health.Damage(5 /* random dice roll */)` on it.