Timeline for How should game objects be aware of each other?
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 8, 2013 at 8:16 | vote | accept | Shoe | ||
| Nov 1, 2013 at 12:32 | vote | accept | Shoe | ||
| Nov 1, 2013 at 12:34 | |||||
| Nov 1, 2013 at 1:19 | answer | added | Engineer | timeline score: 1 | |
| Nov 1, 2013 at 0:33 | answer | added | David C. Bishop | timeline score: 2 | |
| Oct 31, 2013 at 21:25 | answer | added | danijar | timeline score: 1 | |
| Oct 31, 2013 at 20:05 | answer | added | onedayitwillmake | timeline score: 1 | |
| Oct 25, 2013 at 10:06 | answer | added | Philipp | timeline score: 12 | |
| Oct 25, 2013 at 7:37 | comment | added | Sean Middleditch |
@Jefffrey: ideally you don't write type-specific code. You write interface-specific code ("interface" in the general sense). Your logic for a TeamASoldier and TeamBSoldier is really identical -- shot at anyone on the other team. All it needs of other entities is a GetTeam() method at its most specific and, by congusbongus's example, that can be abstracted even further into IsEnemyOf(this) kind of interface. The code doesn't need to care about taxonomical classifications of soldiers, zombies, players, etc. Focus on interaction, not types.
|
|
| Oct 25, 2013 at 7:20 | comment | added | Shoe | @congusbongus, so how do you code type specific code without the use of types? | |
| Oct 25, 2013 at 6:34 | comment | added | congusbongus |
@teodron you're right in saying that the speed difference between RTTI and virtual functions is negligible. I was more arguing about not tying the type system - which can be kind of arbitrary anyway - with game logic. IsHuman is a bad example; better to have things like IsShootable or IsEnemyOf(character), which in turn might lead to an aspect-oriented solution.
|
|
| Oct 25, 2013 at 6:23 | comment | added | teodron |
@congusbongus Using a vtable and custom IsA overrides proved to be only marginally better than dynamic casting in practice for me. The best thing to do is for the user to have, wherever possible, sorted data lists instead of iterating blindly over the whole entity pool.
|
|
| Oct 25, 2013 at 6:20 | comment | added | teodron | an extra: you almost never send a ton of objects to each other entity that might be interested in them. That's an obvious optimization you'll have to really consider. | |
| Oct 25, 2013 at 6:11 | history | tweeted | twitter.com/#!/StackGameDev/status/393620803767795712 | ||
| Oct 25, 2013 at 6:06 | comment | added | congusbongus |
I'd advise against using the type system for game logic. For example, instead of depending on the result of dynamic_cast<Human*>, implement something like a bool GameObject::IsHuman(), which returns false by default but is overridden to return true in the Human class.
|
|
| Oct 25, 2013 at 6:04 | comment | added | teodron | I think you're looking for a versatile C++ RTTI custom implementation. Nevertheless, your question does not seem to be only about judicious RTTI mechanisms. The things you ask for are required by almost any middleware the game will use (animation system, physics to name a few). Depending on the list of supported queries, you could cheat your way around RTTI using IDs and indices in arrays, or you'll end up designing a full fledged protocol for supporting cheaper alternatives to dynamic_cast and type_info. | |
| Oct 25, 2013 at 4:53 | history | asked | Shoe | CC BY-SA 3.0 |