spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ja hast recht, ein paar Funktionen fehlten da.

Das schöne an der Lösung ist: Sie ist absolut robust. Du hast keine Data-Struct, die du durch irgendeine falsche Abfrage falsch interpretieren könntest oder so. Du hast die Typsicherheit, die dir vom Compiler garantiert wird, sollte sich irgendwo ein Fehler einschleichen kannst du das ganze nicht kompilieren, bis er behoben ist.

Was mir noch nicht so gut gefällt: Collider muss alle konkreten Untertypen kennen. Aber vielleicht hilft das hier:
http://sourcemaking.com/design_patterns/visitor/cpp/2
Ich habe es jetzt nur grob überschlagen, aber es scheint so, als würde dabei im Grunde das Dispatching auf andere Klassen aufgeteilt, so dass deine Kollisionsklassen sauberer bleiben. Du hast damit dann im Grunde eine Typsichere Nachschlage-Tabelle, die sich zwar nicht besonders hübsch schreibt, dafür aber wieder sehr robust sein sollte.

Vielleicht hat ja noch jemand anderes eine gute Idee, wie man das eleganter lösen könnte.

Zitat von »wluc-16«

Später bekommen sie ja auch ihre jeweiligen Werte (also Position und Größe bzw. Radius). Dann passe ich auch noch die Kollisionsfunktionen an.

Auch dann wirst Du denselben Code in beiden Klassen-Methoden haben müssen. Anders geht's gar nicht, denn sie müssen ja dasselbe tun.

Das allgemeine Problem bleibt bestehen. Willst Du eine Kollision mit einer Kugel anders handhaben als mit einem Rechteck, muss der Code für die Kollision beide Typen kennen. Um das Dilemma kommst Du nur rundrum, wenn Du die Kollision verallgemeinerst, z.B. auf Polygone.

Virtuelle Funktionen sind natürlich nicht die einzige Lösung. Eine andere Möglichkeit wäre es, in die Basisklasse einen konstanten Member aufzunehmen, der den Typ enthält, dann zwei Objekte zu nehmen, die beiden Typen nachschlage, anhand der Typen in einer Tabelle die richtige Funktion raussuchen, die Objekte entsprechend zu casten und dann an die Funktion zu übergeben.

Das ist natürlich nicht unbedingt 'sauber'. Wenn man in dem Code einen Fehler macht, können lustige Abstürze und anderes passieren. Wenn du andererseits beim implementieren aufpasst, sollte es trotzdem sehr robust sein und sich wesentlich eleganter Programmieren lassen (also mit kürzerem und hübscheren Code).

Man muss es auch so sehen: Wenn eine Sache einmal funktioniert und man nicht davon ausgeht, sie noch 3 mal erweitern zu müssen, dann kann auch eine eigentlich hässliche Lösung durchaus akzeptabel sein. Erweiterbarkeit und Änderbarkeit ist zwar toll und wichtig, aber manche Codeteile packt man halt dann doch nie wieder an. Und dann ist alles was zählt, dass sie richtig funktionieren und schnell genug sind.

Ich persönlich benutze übrigens Bullet für alles was mit Kollision und Physik zu tun hat. Einfach, weil ich mich auf den Grafikteil konzentrieren wollte und man bei Kollisionsabfrage auch richtig viel Zeit verwenden kann.