5 ms·

> Here is a horror story from the good old days when men were men and used DirectX 7. Ugh. > Personally, I hate CONST with a passion, so I like this trick. U

> Here is a horror story from the good old days when men were men and used DirectX 7. Ugh. > Personally, I hate CONST with a passion, so I like this trick. Ugh. > PhysicalObjects could take damage. The air strikes did enough damage in a large enough radius that they were quite literally "killing" the camera. I did fix the bug by ensuring that cameras couldn't take damage, but just to be sure, I boosted their armor and hit points to ridiculous levels. I believe I can safely say we had the toughest camera in any game. Awesome.

shoo 11y ago
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 is the old "kangaroos with rocket launchers" story (from military simulations, not games) [1]. [1] http://www.petting-zoo.net/~deadbeef/archive/4488.html http://www.petting-zoo.net/~deadbeef/archive/4488.html
- 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.
kilotaras 11y ago
I can't recall the source, but the story goes as follow. In some game, menu was written on stone tablets. Due to the bug tablets received guard AI and would randomly walk away to patrol the island.
okasaki 11y ago
There used to be a bug in Kerbal Space Program where solar panels would be occluded by the UI windows.
- TeMPOraL 11y ago
  That's what you get when you keep your UI and game objects mixed together in a some sort of "scene". I suppose Unity that encourages this style.
  - golergka 11y ago
    Actually, KSP uses the old UI framework, where UI objects are "created" every frame. But in new UI framework UI objects are indeed mixed up with game objects, and it makes perfect sense: they live in the same space. Game objects can be 2d, and UI objects can be 3d. For example, you can easily implement weapon UI as a physical display on your weapon's back. You can change your menu from being 2d overlay to be floating in space and collide with level walls in 2 minutes.
SamReidHughes 11y ago
> > Personally, I hate CONST with a passion, so I like this trick. > Ugh. Gamedevs gonna gamedev.

shoo 11y ago

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 is the old "kangaroos with rocket launchers" story (from military simulations, not games) [1]. [1] http://www.petting-zoo.net/~deadbeef/archive/4488.html http://www.petting-zoo.net/~deadbeef/archive/4488.html

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.

kilotaras 11y ago

I can't recall the source, but the story goes as follow. In some game, menu was written on stone tablets. Due to the bug tablets received guard AI and would randomly walk away to patrol the island.

okasaki 11y ago

There used to be a bug in Kerbal Space Program where solar panels would be occluded by the UI windows.

TeMPOraL 11y ago
That's what you get when you keep your UI and game objects mixed together in a some sort of "scene". I suppose Unity that encourages this style.
- golergka 11y ago
  Actually, KSP uses the old UI framework, where UI objects are "created" every frame. But in new UI framework UI objects are indeed mixed up with game objects, and it makes perfect sense: they live in the same space. Game objects can be 2d, and UI objects can be 3d. For example, you can easily implement weapon UI as a physical display on your weapon's back. You can change your menu from being 2d overlay to be floating in space and collide with level walls in 2 minutes.

SamReidHughes 11y ago

> > Personally, I hate CONST with a passion, so I like this trick. > Ugh. Gamedevs gonna gamedev.