Hilfe bei Klassendesign für Spiel

[Lukas1995]

Morgen !

Also: Nach dem Durcharbeiten von Quaxlies Tutorial, fertigstellung einiger einfacher Spiele wie Snake, Pong... hab ich mich an ein kleines Jump'n'Run gewagt.

Das Spiel ist 2D, der Spieler läuft automatisch auf einer ebenen Strecke entlang. Ihm kommen dann Blöcke entgegen, wo man rüberspringen muss. Klappt alles schon ganz gut. Die Blöcke werden immer dann generiert, wenn der Abstand vom letzten Block aus groß genug ist. Die Blöcke haben verschiedene Eigenschaften, zum Beispiel macht einer nur normalen Schaden, ein anderer macht wiederrum Schaden über die Zeit, einer stellt die Karte auf den Kopf für einige Zeit etc.

Es darf nur je eine dieser Arten auf den Spieler wirken, heißt nur einmal Schaden über Zeit, einmal das Umdrehen.

Ein Block soll aber auch nur eine Eigenschaft haben. Bis jetzt hab ich es so gehandhabt, dass ich für jede Eigenschaft eine neue Klasse angelegt habe, und der Block hat dann 4 Objekte, die bei der Erstellung null gesetzt werden und eine zufällige Eigenschaft ausgewählt wird, die er haben soll.

Mein Problem liegt darin, dass ich, um das Spiel umzudrehen auf den Rendercode der Oberklasse Game zugreifen muss. Die überprüft, ob auf dem Spieler die Eigenschaft vorhanden ist:

if (player.rotate != null) {
g.rotate (400,300,180)
}

Als Engine benutze ich Slick 2D, g stellt hier das Grafikobjekt von Slick dar.

Allerdings scheint der Ansatz nicht wirklich OO zu sein. Kann man das sauberer lösen oder geht das so doch halbwegs in Ordnung :bahnhof:

danke schonmal

 

[Fu3L]

if (player.rotate != null) {
g.rotate (400,300,180)
}

Das kleine Stückchen zeigt schonmal zwei Anfängerfehler: Zum einen greift man auf Felder eines Objektes nicht direkt zu, sondern immer über Getter und Setter Methoden (eventuell mit Ausnahmen, wenn man sowas wie Point2D hat, ist Geschmackssache).
Das zweite ist: Erstelle am besten eine Methode wie: player.isConfused() oder wie auch immer benannt, die dem Rendercode zeigt, dass die Welt auf dem Kopf stehen soll.
So löst du dich von der internen Darstellung und erreichst eins der Ziele der OOP: Kapselung/Information Hiding.

Nun ist es generell aber schon ungünstig, wenn immer nur eine Eigenschaft gleichzeitig da sein kann, dafür 4 Variablen anzulegen. Wenn alle Eigenschaften ein bestimmtes Interface implementieren oder von einer bestimmten (abstrakten) Basisklasse erben, kannst du alle in einer Variablen vom Typ des Interfaces oder der Basisklasse ablegen.

 

[Lukas1995]

Okay, danke, das mit dem Interface find ich gut, werd ich gleich umsetzen. Ich denke, damit ist das geklärt