ich arbeite zurzeit mit einem Freund an einem Spiel, bei dem ich (mit dem bisherigen design) periodisch nach kollisionen suche und dann bei der kollisionsbehandlung je nach typ der beteiligten objekte etwas bestimmtes mache.

Also ich habe ungefähr sowas an Klassen:
- GameObject (Basisklasse für alle folgenden Klassen)
- Enemy (Basisklasse für Gegner)
- Immortal(Basisklasse für Wände/Bläcke / etc.)
- Usable (Basisklasse für Powerups etc.)
- und paar mehr...

und dann gibt es eine Reihe von konkreten Klassen, die jeweils von Enemy,Immortal,Usable oder weiteren Basisklassen ableiten.

Ich suche dann in einer Liste von GameObjects nach Kollisionen und wenn ich was finde mache ich ungefähr sowas:

a.collideWith(b); b.collideWith(a);

Und je nach typ des jeweils anderen muss dann eine von der konkreten klasse festgelegte behandlung erfolgen.

Bisher machen wir das so, dass ich für jede der Basisklassen eigene container nehme und dann dann kollisionen immer zwischen zwei containern checke und dann beim aufruf direkt die für die basisklasse überladene methode aufgerufen wird beim anderen objekt.

Alerdings erlaubt das nur spezielles verhalten für jede Basisklasse, manchmal brauch ich auch besonderes Verhalten für konkrete Klassen.

Bisher regeln wir das durch dynamic cast... allerdings finde ich das nicht besonders toll.
Also ungefähr so:

if((a = dynamic_cast<Yoshi>(b))
{
   //Spezialbehandlung für Yoshi
}

Ich kenne die Möglichkeit double dispatch zu verwenden, aber dann muss JEDE klasse eine methode für JEDE andere klasse haben, was ich nicht besonders toll finde...
Meistens sind die Behandlungen für die Basisklassen gleich.
Dann hab ich mir noch überlegt, man kann sich ne virtuelle methode machen, wie
getTypeId() oder die eingebauten typeinfos oder so verwenden und dann maps verwenden um auf die funktionen zu mappen.
So richtig hat mich das aber auch nicht überzeugt...

Hat jemand Vorschläge?

Hat jemand Vorschläge?

Mein Vorschlag: Einfach beim normalen Double Dispatching bleiben.

Aber Du wirst mecp lesen wollen. Da läßt er sich in aller Ausführlichkeit zu diesem Themenkomplex aus.
http://www.amazon.de/Effektiv-programmieren-Verbesserung-Programme-Entwürfe/dp/3827312752

In typischer 3D-Umgebung hat man ja Flächen (Ebenen, rechteckige, radiale, ...), Polygonnetze und geometrische Körper; dann per Komposition auch Zusammengesetztes. Hier musst du dann "nur noch" die einzelnen Formen kollidieren lassen (also Fläche<->Polygonnetz, Kugel<->Quader, ...), das ist noch handhabbar per Double-Dispatching.

Es wird ein 2d spiel und bisher verwenden wir ausschließlich an den axen ausgerichtete (soll heißen nicht gedrehte) rechtecke.

Aber es geht hier weniger um das FINDEN von Kollisionen als um die BEHANDLUNG, also sowas wie wenn mario auf nen gegner springt, stirbt der gegner, außer wenn es sich z.B. um eine art "igel" handelt, dann braucht man eine spezialbehandlung

Danke für eure Vorschläge!
Bitte melden, falls noch jemand ne Idee hat

Wenn sich die Anzahl der Behandlungen relativ klein ist, dann schreib die 3 bis 4 if einfach hin. Wenn es viele gibt, dann mach dir so ne map < pair<objectTypeA, objectTypeB>, event >

sowas wie wenn mario auf nen gegner springt, stirbt der gegner, außer wenn es sich z.B. um eine art "igel" handelt, dann braucht man eine spezialbehandlung

Hm, lässt sich das dann nicht in die Spiellogik integrieren? Also statt

void mario::onCollide( object* Other ) {
    if ( igel* Igel = dynamic_cast<igel*>(Other) )
        this->Health -= 10;
    else
        Other->die();
}

lieber

void mario::onCollide( object* Other ) {
    if ( Other->hasSpikesOnBack() )
        this->Health -= Other->getSpikesStrength();
    else if ( Other->isDyingAtJumpOnBack() )
        Other->die();
}

?

Oder du abstrahierst die Kollisionen nochmal in z.B. "berühren", "draufspringen" usw. Eine Möglichkeit dann für die Logik in Stachelsachen:

void thing_with_spiky_back::PlayerJumpsOnYourBack( player* Player ) {
    Player->suffer( this->getSpikeStrength() );
}

class igel : public thing_with_spiky_back {
    ...
};

void mario::suffer( int Strength ) {
    if ( this->IHaveArmor )
        Strength -= this->MyArmorStrength;
    if ( ! this->IHaveAStar )
        this->Health -= Strength;
    if ( this->Health <= 0 )
        this->die();
}

Da musst du wahrscheinlich mal tabellarisch herausarbeiten, was bei welcher Aktion mit welchen Charakteren und Objekten passiert. Wenn du genug Gemeinsamkeiten findest, lässt sich das bestimmt gut zusammenfassen und in Logik gießen.

a.collideWith(b);
-->
<a>
     b->WhoAreYou(this)
</a>
-->
<b>
     a->OkIam(this)
</b>
-->
<a> (in Iam)
     ...
</a>

"OkIam" Sei eine Überladene Methode für die Basisklassen und für jeden Sonderfall einer konkreten Klasse.

So oder so ähnlich kannst du deine Viecher identifizieren, ohne in allen klassen Methoden für alle anderen anbiten zu müssen, da du ja je auch eine Überladung für die Basen hast. In den Methoden für die Basen machst du dann halt das gleiche was du jetzt auch tust.

cu

struct Monster
{
    virtual void jumped_onto(Mario& m)
    {
        die();
    }
};

struct Igel : Monster
{
    virtual void jumped_onto(Mario& m)
    {
        m.take_damage(10);
    }
};

struct Mario
{
    void collide_with(Monster& m)
    {
        m.jumped_onto(*this);
    }
};

Mario ist es egal, auf welches Monster er springt. Lediglich vom Monster hängt es ab, wie es sich verhält (sterben, Schaden austeilen, beides etc.). Und schon gibt es kein Double-Dispatch mehr. Vielleicht gibt es bei anderen Fällen, wo das auftritt, ähnliche Lösungen.

Blöd wirds dann, wenn man neben Mario auf den Steinmenschen Igor spielen kann, der Igel zermalmt. Hier wäre es z.B. möglich, verschiedene Angriffsarten zu definieren (normaler Sprung, Sprung mit Steinhaut usw.), auf welche das Monster dann anders reagiert.
Oder man macht es mit Double-Dispatch, ich bezweifle aber, dass das hier einfacher ist.

Ich habe mich noch nicht entschieden, wie ich es langfristig löse.

Falls noch weitere Ideen da sind, bitte melden

ich melde mich mal wieder hierzu, weil es neuigkeiten gibt.

Im eigentlichen Programm haben wir bisher noch nichts geändert, aber wir planen, alles neu zu machen und dann wäre es gut einen geeigneten ansatz zu verwenden.
Beim neumachen soll auch unterstürzung für netzwerk mit rein, und dafür habe ich mir überlegt, dass ich die technik von virtuellen konstruktoren benutzen kann, die ich gerade bei "More Effective C++" gelesen habe.

Also sowas wie

GameObject* GameObject::CreateFromStream(istream& str)
{
   int classID;
   str >> classID;
   //switch case / kaskadierende else ifs zum erstellen eines objekts des jeweiligen typs
   //pointer auf erstelltes objekt zurückgeben
}

Für dieses vorgehen brauche ich etwas wie classID's und dann dachte ich mir, wenn ich die eh schon einführe, um objekte übers netzwerk zu kriegen, dann kann ich die ids noch gleich so designen, dass ich anhand dessen auch die basisklassen rausfinden kann und dann statt double dispatch oder dynamic cast oder ähnlichem einfach je nach classID handeln kann.

Idee für den Aufbau der classID (soll eine riesige enum werden^^) ist dann folgendes:
(GameObject ist basisklasse von allem, davon erben z.B. Enemy und Usable und davon erben wiederrum Crawler und Mushroom)
GameObject -> 1 //erste basisklasse
Enemy -> 11 //erste abgeleitete klasse der ersten basisklasse
Usable -> 12 //zweite abgeleitete klasse der ersten basisklasse
Crawler ->111 //erste konkrete klasse von ...
Mushroom -> 112 //zweite konkrete klasse von...
Also die vorderen ziffern sind dann für die basisklassen und die letzte ist für die konkrete klasse (da brauch man dann evtl. 2 ziffern).
Dann kann man durch geschickte rechnung die einzelnen stellen der zahl extrahieren und dann die basisklassen und konkrete klasse herausfinden und darauf basierend handeln.
Die Zahl für gameobjekt kann man eignetlich auch sparen, weil sowieso alles davon erbt

Ein Nachteil ist vermutlich, dass, wenn man was zur enum hinzufügt, einiges neukompiliert werden muss...

Was haltet ihr davon?
Hat das ganze sonst noch irgenwelchen großen Nachteile?
Gibt es bessere Alternativen?

enum ClassID
{
    ...
    ANYDERIVED,
    ...
    NUMBER_OF_CLASSES
};

class Base
{
protected:
    std::bitset< NUMBER_OF_CLASSES > ids;
};
class AnyDerived
    : public Base
{
public:
    AnyDerived
    {
        ids[ ANYDERIVED ]=true;
    }
};

Danach sollte es ja sehr einfach sein, rauszufinden was in einem bestimmten Objekt alles drinsteckt.

Du hast schon Recht. Ich würde jetzt aber erst mal versuchen, das Programm fertig zu schreiben und mir erst dann Gedanken über einen int mehr oder weniger zu machen. Es ist gut möglich, dass dein Bottleneck wo ganz anders sein wird, dann wäre das hier verschwendete Zeit. Nur für den Fall würde ich dem Mechanismus, den du jetzt wählst, einen Wrapper verpassen damit du nicht viel neu schreiben müsstest.

So also ich hab mir das ganze nochmal überlegt und tendiere nun doch dazu, double dispatch zu verwenden.

Ich wollte das dann so machen:

class GameObject
{
    void initiateCollision(GameObject& obj) = 0;
    void collideWith(Enemy& enemy) = 0;
    void collideWith(Usable& usable) = 0;
    void collideWith(Player& player) = 0;

    void collideWith(Crocodile& croc); // nicht = 0!
    void collideWith(Mushroom& mushroom); //nicht = 0!
    //...
};

Also erstmal initiateCollision muss von jeder erbenden Klasse überschrieben werden und dadrin einfach machen

void XY::initiateCollision(GameObject& obj)
{
   obj.collideWith(*this);
}

Die collideWith mit den Basisklassen müssen von jedem überschrieben werden (deswegen = 0) und irgendein standardverhalten für kollision mit objekten von dieser basisklasse festlegen.

Alle anderen (mit konkreten basisklasse) sind bei GameObject nach dem muster implementiert:

void GameObject::collideWith(Crocodile& croc)
{
   collideWith(static_cast<Enemy&>(croc));
}

Ich hoffe mal, dass das so funktioniert.

Alle abgeleiteten Klassen müssen also die methoden für die Basisklassen überschreiben, alle weiteren für konkrete Klassen sind optional und werden nur überschrieben, wenn für diese klasse eine sonderbehandlung nötig ist.
Falls eine methode nicht überschrieben wird, sorgt die geerbte methode von GameObject dafür, dass die Behandlung für die Basisklasse aufgerufen wird.

Das problem dabei ist nur, dass wenn ich eine neue Klasse hinzufüge, ich bei GameObject eine neue Methode reintun muss und deswegn alle abgeleiteten Klassen neu kompilieren müssen...
Ich hab mir überlegt, evtl. alle abgeleiteten Klassen zum pImpln um das problem zu vermindern, bin mir aber nicht sicher, ob das in diesem fall möglich/angebracht ist.
Normalerweise tut man alles was zur pImpl-Klasse gehört in eine cpp-datei inkl der pImpl-Klassendefinition.
Ich würde das dann so modifizieren, dass ich die pImpl-Klassendefinition in einen eigenen header tue und 2 cpp-dateien habe, eine für die richtige klasse mit weiterleitungsmethoden und eine für die pImpl-Klasse.
Wenn ich dann die Basisklasse ändere, muss nur die "richtige" klasse die weiterleitungsfunktionen neu kompilieren und die pImpl-Klasse mit der eigentlichen logik bleibt unberührt (so zumindest habe ich mir das gedacht :-).

Was meint ihr?

Es gibt auch andere Möglichkeiten, z.B. so wie es in der Loki-Bibliothek gemacht wird. Dann musst du nicht einmal die Klassen verändern. Das könnte dann ungefähr wie folgt aussehen, solche Klassen findest du ausser in Loki z.B. hier.

// Polymorphe Klassenhierarchie
class B {...};
class D1 : public B {...};
class D2 : public B {...};

// Überladene Funktionen (abgeleitete Klassen als Parameter!)
void Collision(D1& lhs, D1& rhs);
void Collision(D1& lhs, D2& rhs);
void Collision(D2& lhs, D2& rhs);

// Funktionen registrieren
DoubleDispatcher<B&> dispatcher;
dispatcher.Register<D1, D1>(&Collision);
dispatcher.Register<D1, D2>(&Collision);
dispatcher.Register<D2, D2>(&Collision);

// Aufruf
B* x = new D1;
B* y = new D2;
dispatcher.Call(*x, *y); // Collision(D1& lhs, D2& rhs)
delete x;
delete y;

Und kann ich bei dem was du vorgeschlagen hast auch Basisklassen gleich behandeln, ohne für jede abgeleitete Klasse nen register zu machen?

Das würde einiges an arbeit sparen.

sonst braucht man n*(n+1)/2 (glaube ich) funktionen, wenn man aber nur in sonderfällen ne spezialbehandlung braucht, kann man das stark reduzieren und dann wäre es gut, wenn man auch nicht n*(n+1)/2 mal registrieren muss.

Ich werds mir auf jeden fall mal angucken.

Für die gemeinsame Behandlung von Klassen als Basisklasse ist mir bisher leider keine Lösung eingefallen, Alexandrescu hatte in seinem Buch diese Funktionalität ebenfalls weggelassen. Das Problem ist, dass die Dispatcher auf der Basis von typeid arbeiten, und in C++ gibt es keine Möglichkeit, eine Vererbungsrelation zur Laufzeit abzufragen. is_base_of aus den Type-Traits ist zwar gut, aber dazu müssen beide Klassen zur Kompilierzeit bekannt sein.

Das Ganze läuft darauf hinaus, dass man in irgendeiner Weise die Vererbungshierarchie manuell angehen muss. Wenn man Metaprogrammierung sinnvoll einsetzt, könnte man eventuell sogar nur eine Liste von Klassen angeben, und der Compiler findet dann heraus, welche wovon erbt. Ich könnte mal etwas tüfteln, denn wie du sagst, wäre eine Derived-To-Base-Konvertierung in manchen Fällen eine enorme Erleichterung.

Nehmen wir an, ich habe 99 Klassen und kollisionen zwischen diesen sind alle registriert.
Jetzt füge ich eine 100te Klasse ein.
Jetzt muss ich wirklich 99 neue einträge in die map machen (wenn wir von symmetrie ausgehen, sonst noch mehr)?

Es wäre wünschenswert noch ein "default-mapping" zu haben, dass falls ein eintrag fehlt einfach die funktion für die basisklasse aufzurufen.
Falls jemand eine Idee hat, wie das zu bewerkstelligen ist, bitte her damit
Mit double dispatch ist das ja kein problem, aber dafür muss da alles neu kompilieren, wenn eine klasse dazukommt...

Beides gefällt mir nicht so recht, ich muss mich wohl für das kleiner übel entscheiden, ich bin mir nur noch nicht sicher, welches es ist

Ich könnte das problem vll ungefähr so lösen:

//typedefs für kollisionsbehandlungsfunktionen für alle basisklassen
//ich weiß nicht ob die typedefs mit templates so gehen, aber sowas in der art muss doch irgendwie gehen, oder?
template <class T>
typedef void (*EnemyCollisionFunc)(T& t, Enemy& e);
template <class T>
typedef void (*PlayerCollisionFunc)(T& t, Player& p);
template <class T>
typedef void (*UsableCollisionFunc)(T& t, Usable& u);
//...

template<class T>
registerDefaultMapping(EnemyCollisionFunc<T> defaultEnemyHandlerFunc,
PlayerCollisionFunc<T> defaultPlayerHandlerFunc, UsableCollisionFunc<T> defaultUsableHandlerFunc)
{
   //gehe alle klassen durch und registriere eine default funktion
   //z.B.
   dispatcher.Register<T, Ghost>(defaultEnemyHandlerFunc);
   dispatcher.Register<T, Zombie>(defaultEnemyHandlerFunc);
   //..
   dispatcher.Register<T, Mario>(defaultPlayerHandlerFunc);
   //...
   dispatcher.Register<T, Mushroom>(defaultUsableHandlerFunc); 
   //...
   //später können spezialfälle durch neue einträge überschrieben werden
}

Sollte doch funktionieren, oder?

Das bringt mich noch zu einer anderen Frage:
Wenn ich das symmetrisch registiere, liegt es ja nah, dass ich zur behandlung eine freie funktion habe und nicht 2 memberfunktionen aufrufe.
Haltet ihr es für sinnvoll diese freie Kollisionsbehandlungsfunktionen dann in der klassen als friend zu deklarieren/definieren und dann in den freien funktionen die komplette logik zu machen, oder sollte ich memberfunktionen fürs kollidieren haben und dann in der freien handler funktion 2 memberfunktionen aufrufen?
Nochmal mit codebeispiel:
1.Variante:

//Ghost und Mario haben diese funktion als friend deklariert
void handleCollision(Ghost & g, Mario & m)
{
   //irgendne behandlung, z.B. sowas:
   g.changeDirection();
   m.takeDamage(1000);
   //evtl muss man aber auch auf private sachen zugreifen
   m.setAnimationLoop(Mario::HitByGhost);
}

2.Variante:

void handleCollision(Ghost & g, Mario& m)
{
   g.collideWith(m);
   m.collideWith(g);
}

Was haltet ihr für besser?

Es wäre wünschenswert noch ein "default-mapping" zu haben, dass falls ein eintrag fehlt einfach die funktion für die basisklasse aufzurufen.

So eine Fallback-Funktion habe ich mir auch schon überlegt. Momentan kann man das auf Call-Seite erreichen, indem man die Exception bei Nicht-Finden fängt und dann selbst eine andere Funktion aufruft. Ist natürlich nicht so elegant.

Doch besonders flexibel ist der Fallback-Ansatz nicht, er kommt mir mehr wie ein verzweifelter Versuch vor, dem Derived-To-Base-Problem mindestens etwas näher zu kommen. Wenn ich eine Klassenhierarchie A -> B -> C (C am meisten abgeleitet) habe, nur B und der Fallback für A registriert ist und ich ein C übergebe, wird der Fallback aufgerufen, obwohl eigentlich B richtig wäre.

Ideal wäre wirklich, wenn man Basisfunktionen registrieren könnte, und diese automatisch aufgerufen werden, falls die abgeleitete Version nicht registriert ist. Aber ohne die ganze Klassenhierarchie nochmals manuell anzugeben scheint das nicht zu gehen, zumindest sehe ich keine Möglichkeit. Naja, vielleicht wäre das wirklich die beste Möglichkeit. Wenn jemand andere Ideen hat, nur her damit

Gast1337 schrieb:

Sollte doch funktionieren, oder?

Grundsätzlich wahrscheinlich schon, allerdings wird so eine Funktion registerDefaultMapping mühsam zu implementieren, wenn sie generisch sein soll. Dann bräuchte man wohl Typlisten.

Du könntest allerdings auch für alle Möglichkeiten ein Funktionsobjekt registrieren (z.B. std::tr1::function ), das dann intern weiterdispatcht. So kannst du während der Laufzeit die Zuordnung über einen Schalter ändern.

Gast1337 schrieb:

Was haltet ihr für besser?

Ich würde eine globale Funktion mit direkter Berechnung nehmen. Je nachdem, wie deine Klasse gekapselt ist, muss die Funktion nicht mal ein friend sein.

Eine weitere sache über die ich nachdenke ist wie ich das mit der serialisierung mache.
Wenn ich das selbst schreibe, würde ich eine enum machen, die für jede Klasse einen eintrag hat.
wird dann ein objekt serialisiert, wird zuerst ein element der enum in den stream geschrieben, dann das eigentliche objekt.
Beim Empfänger hat man dann eine map, die enum-werte auf virtuelle konstruktoren mappt (mit virtuellen konstruktoren ist sowas gemeint:

GameObject * createXY(sf::Packet & packet);

)

Das problem ist wieder:
Jede klasse muss zugriff auf die enum haben, damit man objekte der klasse "fragen" kann (virtuelle methode), welchen typ sie haben.
Also müssen alle klassen neukompilieren, wenn eine neue dazukommt...
Das wollte ich ja gerade vermeiden, deswegen überlege ich mir das ja auch mit deinem double dispatcher anstatt normalem double dispatching.

Ich habe mir boost::serialization angeguckt, aber einige sachen stören mich daran:
Die Archive sind entweder textbasiert (z.B. xml), haben also ne menge overhead, oder binär, aber dann nicht portabel (endianess ist das (haupt-)problem, denk ich mal).
Und zur Unterstützung für serialisierung von objekten durch basisklassenpointer:
Das funktioniert damit im prinzip schon, aber auch da muss man registrieren).

Evtl. kann ich das aber auch selbst mithilfe von dieser "registrierung" hinbekommen?
Ich könnte dann in einer funktion die direkt am anfang von main aufgerufen wird alle klassen registrieren und dann typeinfo auf die enum mappen zum serialisierung und die enum auf virtuelle konstruktoren mappen zum deserialisieren, oder so.

Ich überlege auch noch, ob es überhaupt sinnvoll ist, rücksicht auf sowas wie endianess zu nehmen, weil doch eigentlich eh fast alle computer auf denen man spiele spielen würde little endianess haben soweit ich weiß.