Variable Methodenwahl

[Gonzo17]

Servus,

also mir geht's um folgendes. Erstmal die Situation. Ich programmiere an einem Jump'n'Run-Spiel mit und zur Kollisionserkennung habe ich jeweils eine Methode, die überprüft, ob rechts, links, oben oder unten geblockt ist. Die Methoden funktionieren jeweils gut, allerdings muss ich die ja bei der Berechnung der neuen Position mehrmals aufrufen. Einmal bewegt sich eine Figur in einem Intervall nach rechts und oben, einmal nur nach unten. Dazu müsste ich ja theoretisch eine riesige if-else-Kaskade aufbauen, was ich jetzt zum Testen auch erstmal gemacht habe, allerdings stellt sich mir da die Frage: geht das nicht einfacher?

Was mir da so vorschwebt ist eine Möglichkeit, dass man anhang zB eines Enums bestimmt, welche Methoden aufgerufen werden sollen. Das Enum hat dann natürlich so viele Felder wie meine if-else-Abfragen. Ich würde dann zB das passende Feld aus dem Enum in eine Methode weitergeben und die ruft dann alle notwendigen weiteren Methoden auf. Gibt's da ne elegante Lösung? Oder muss ich tatsächlich so hässlichen Code verwenden? (der ist ja nichtmal mehr übersichtlich, man muss ja dauernd überlegen, welches if/else man gerade behandelt)

Gruß, Gonzo

 

[Gelöschtes Mitglied 5909]

Das hört sich nach einem typischen Fall für Polymorphimus an

 

[Cola_Colin]

Man könnte eine Methode schreiben, die die Richtung in die die Bewegung blockiert ist, zurückgibt oder eben nicht blockiert.
Die Rückgabewerte könnte man z.B. über einen enum lösen.
Intern kann die die 4 anderen aufrufen.

 

[Marco13]

So ganz ist nicht klar, an welcher Stelle da die "Häßlichkeit" einsetzt. Man kann sich zwar bei jedem "if" die Frage stellen, ob man es vermeiden könnte (und meistens sollte man sich diese Frage auch stellen), aber manchmal kommt man eben nicht drumrum. Poste vielleicht mal ein bißchen (nicht notwendigerweise "vollständigen", aber doch repräsentativen Code.

@raiL: <korinthenkack> Polymorphismus ? Wikipedia </korinthenkack>

 

[Gelöschtes Mitglied 5909]

blaaa

 

[Gonzo17]

if (isMovingDown) {
	if (isMovingRight) {

	} else if (isMovingLeft) {

	} else {
	
	}
} else if (isMovingUp) {
	if (isMovingRight) {

	} else if (isMovingLeft) {

	} else {

	}
} else {
	if (isMovingRight) {

	} else if (isMovingLeft) {

	} else {
	// nothing to do
	}
}

Edit: Zum Verständis, es wird erst die vertikale, dann die horizontale Bewegung abgefragt. Da eine Figur ja aber auch "schräg" springen kann, muss da eben eine gesonderte Berechnung erfolgen (aber auch unter der Verwendung der vier Methoden zum Abfragen, ob eine Kollision geschieht).

So sieht das ganze if-elseif-else-Gebirge aus. Die boolean Variablen kann ich vorher problemlos ermitteln und dienen mir dazu, die Richtung der Figur zu ermitteln. Und je nachdem, in welche Richtung(en) sich die Figur bewegt, muss eben auch unterschiedlich vorgegangen werden.

Um mir das ganze zu sparen wärs eben am coolsten, wenn ich einfach eine Variable hätte, die die Richtung beschreibt (zB eben in Form eines Enums) und dann (wie auch immer, das ist ja die Frage) Methoden ausgeführt werden, die dazu nötig sind. Wobei ich da eben natürlich dann kein if nutzen will (sonst könnt ichs ja auch so lassen).

Wie ich Polymorphie da nutzen soll, ist mir nicht ganz klar. Könnt ihr mir ein kleines Beispiel geben?

 

[Cola_Colin]

Vektorrechnung im Bezug auf die Position und Bewegung würde dir das alles ersparen.

 

[Gonzo17]

Vektorrechnung im Bezug auf die Position und Bewegung würde dir das alles ersparen.

:reflect:

Irgendwie hast du da schon recht. Wie genau würde man da vorgehen? Man rechnet die neue Position aus und checkt ab, ob der Vektor von alt nach neu in einem geblockten Bereich liegt?

 

[Cola_Colin]

Grundlegende Vorgehensweise ist:
Position und Bewegung als Vektoren speichern.

Mögliche Neue Position = Alte Position + Bewegung*vergangene Zeit.
Wenn Mögliche Neue Position nicht blockiert dann setze sie als die neue Position, sonst verwerfe das ganze.

Das kann dazu führen, dass sich sehr schnelle Objekte durch andere Objekte hindurchbewegen können.
Um das zu verhindern kann man zwar noch was machen, das ist aber recht kompliziert und eben nur bei wirklich schnellen Objekten nötig, bei anderen kostet das ganze nur unnötig Rechenleistung.
Kann man also erstmal weglassen. Wichtig ist eben nur, dass die vergangene Zeit zwischen zwei Rechenschritt möglichst klein ist.
Ist sie sehr sehr groß, so wird das Problem schlimmer.

 

[Gonzo17]

Das klingt generell sehr interessant. Allerdings geht das nicht so einfach, ich weiß nicht ob folgender Sachverhalt aus meiner Beschreibung hervorgegangen ist. Und zwar ist ein Bereich nicht einfach "geblockt", sondern von bestimmten Seiten aus geblockt. D.h. es wäre möglich durch bestimmte Blöcke von unten durchzuspringen, aber obendrauf bleibt man steht. Deswegen brauche ich ja die Information, von welcher Richtung sich die Figur her bewegt.
Ich probiers mal mit den Vektoren aus und gebe dann Rückmeldung.

 

[Cola_Colin]

Da wirst du dann die Positionen und Bewegungen von Spieler und Block vor der potenziellen Kollision noch in Betracht ziehen müssen.

 

[Kubus]

Ist ja erstmal nicht schlimm, Vektoren haben ja immer eine Richtung, also kannst du dien Problem damit gut modellieren. Nebenbei würde dir das auch ermöglichen viel mehr Bewegungen zu prüfen statt nur die von dir angegeben, also würde es deinen Code sogar erweiterbar machen.