Frage zu Kollision

[Dasha]

Hi,

ich arbeite gerade an einen Spiel. Man muss mit einer Figur durch die Gegend laufen und Monstern ausweichen bzw. abs*****en.
Es gibt die Klassen Spieler und Monster, die beide von Sprite erben bzw. es wird auch noch eine Klasse Kugel hinzukommen. (Monster töten Spieler bei Kontakt, Spieler feuert Kugel, Kugel töten Monster u.s.w.)

Diese Sprites sind alle in einer Liste welche sich in der Klasse GameController befindet
Die Sprites in der Liste werden bei jedem GameLoop durchlauf aktualisiert, außerdem habe ich noch einen Sprite Spielfeld, welcher aber nicht in der Liste ist.
Spielfeld habe ich nicht in die Liste gepackt, weil ja nur getestet wird ob ein Sprite mit dem Spielfeld kollidiert ist. Ein Spielfeld kann nicht mit einen Sprite kollidieren, da es sich nicht bewegt.

Verhalten:
(Spieler wird bei Kontakt mit Spielfeldrand an Position xy geportet, Monster prallen ab und Kugeln werden gelöscht). Es wird getestet ob jeder Sprite mit jedem Kollidiert ist.


Jeder Sprite besteht aus einer Form (Klasse Form repräsentiert geometrische Figuren).
In der Klasse Form gibt es eine Methode, die testet ob zwei Formen (Sprites kollidieren ja nicht, sondern Formen).


Da fangen meine Probleme an, ich muss testen (ist jetzt nur die Methode für die Kollision mit dem Spielfeld):
Die normale Methode testet dann alle Möglichen kombinationen was mit wem kollidiert ist.

 public void collideWithSpielfeld(Sprite sprite, Shape spielfeld)
    {

    	if(collisionDetector.collide(sprite.getShape, spielfeld))
    	{
    		if(sprite instanceof Monster) 
    		{
    			sprite.setSpeed(sprite.getSpeed()*-1); //kehr Speed um
    			sprite.setDirection(sprite.getDirection() + 45); //ändert den Laufwinkel
    			sprite.update();
    		}
    		
    		else if(sprite instanceof Figur)  
    		{
    			sprite.setAlive(false) //Beim nächsten Update wird es gelöscht und dann wieder respawnt
    		}

                else if(sprite instanceof  Kugel)  
    		{
    			sprite.setDead(true) //Beim nächsten Update wird es gelöscht
    		}

  }

Einen KollisionsDetector habe ich und soweit funktioniert auch alles. Mein Problem ist mein Design, ich glaube es ist ziemlich schlecht.

Weil:
-Sobald ich eine neue Sprite Unterklasse erstelle muss ich immer die Kollisionsmethoden (Wer ist mit Wem kollidiert und Was ist passiert) umschreiben.
-Die Methoden enthalten mit zu viel Code
-Ich kann über die Methoden keinen Sprite löschen. Ich setze erst mit setAlive den Sprite auf false und beim nächsten Update wird er erst gelöscht (KA ob man das so macht). Der Iterator löscht beim update alle Elemente die nicht mehr am Leben sind.
-Der GameLoop Code ist auch ziemlich viel:
Ich gehe die Liste mit Elementen durch, wenn ein totes Element dabei ist lösche ich es ansonsten wird das Element geupdatet und geschaut ob es mit dem Spielfeld kollidiert ist. Dann wird geschaut ob dieses Element aus der Liste mit allen anderen Elementen aus der Liste kollidiert ist.

Wie gesagt ich bin nicht ganz zufrieden. Hätte an dieser Stelle jemand Tipps für mich wie man die oben geposteten Abfragen kompakter und übersichtlicher gestalten kann? Gibt es irgendwo Beispiele dazu?
Für die Spielfeld-Kollision würde ich, um den Code übersichtlicher zu machen, in die Klassen Figur, Monster und Kugel die Methoden packen. Da brauch ich nicht mehr auf instanceof zu testen sondern kann den Code gleich ausführen.
Das würde ich dann auch bei der normalen Kollision machen aber bei der Kollision "Kugel > Monster" und "Monster > Kugel" würden dann aber die Methoden dann wieder den gleichen Code enthalten.

mfg

 

[Marco13]

Welchen "viel Code" meinst du denn? Das mit dem instanceof ist in der Tat nicht schön, aber ... wenn man n verschiedene Typen hat, und jeder mit jedem kollidieren kann, sind das eben n*n Fälle. Man kann zwar versuchen, dort Gemeinsamkeiten zu finden, aber in letzter Konsequenz muss man im schlimmsten Fall alle Fälle abdecken. Den Fall des geposteten Codes (Kollision mit Spielfeld, was auch immer das bedeutet) in die Klassen packen um das instanceof zu sparen, würde EINEN Fall verstecken, aber eben nicht viel weiter helfen. Spontan dachte ich da an Double dispatch - Wikipedia, the free encyclopedia , kannst ja mal schauen ob du was in der Richtung in Betracht ziehen willst.

 

[Network]

-Sobald ich eine neue Sprite Unterklasse erstelle muss ich immer die Kollisionsmethoden (Wer ist mit Wem kollidiert und Was ist passiert) umschreiben.
-Die Methoden enthalten mit zu viel Code
-Ich kann über die Methoden keinen Sprite löschen. Ich setze erst mit setAlive den Sprite auf false und beim nächsten Update wird er erst gelöscht (KA ob man das so macht). Der Iterator löscht beim update alle Elemente die nicht mehr am Leben sind.
-Der GameLoop Code ist auch ziemlich viel:
Ich gehe die Liste mit Elementen durch, wenn ein totes Element dabei ist lösche ich es ansonsten wird das Element geupdatet und geschaut ob es mit dem Spielfeld kollidiert ist. Dann wird geschaut ob dieses Element aus der Liste mit allen anderen Elementen aus der Liste kollidiert ist.

1.) -> Marco13
2.) Was heißt zu viel Code? Das ist ein Paradoxon an sich. Jedoch schlussendlich nicht schlimm für die JRE. Hier einfach mal schauen, ob man sich Code sparen kann durch logische Umstrukturierung. Besonderst if-Abfragungen verkapseln sich oft zu einem viel zu komplizierten System.

Hilfreich ist es oftmals auch, den Code in einzelne Segmente zu unterteilen und in einzelne Methoden zu packen, die sich hintereinander aufrufen.
Diese Unterteilungen sollten dann natürlich für dich logisch (wieder)erkennbar sein.
3.) Das ist gut so, das macht man auch so. Es hält den Code strukturierter und behält das Konzept eines Spieles bei.
4.) Ich persöhnlich würde die GameLoop in 2 weitere Klassen unterteilen: Logik und Darstellung. Die GameLoop übernimmt dann nurnoch die Tatsache, dass die Schleife weiterläuft und wie sie weiterläuft. (Es gibt sehr viele mehr oder weniger unterschiedliche Möglichkeiten so eine Schleife zu schreiben und von daher ist es auch recht nützlich diesen Code seperat und austauschbar zu haben).

 

[Dasha]

Danke 🙂
Ich werd mal schauen wo ich was umsetzen kann.