Grundsätzlicher Spieleaufbau an (m)einem Beispiel

[k3ltis]

Hallo,

ich hab eine art Moorhuhnjagd in Java gemacht. Anstatt Hühner gibts aber drollige Zombies. Es funktioniert alles ganz gut - trotzdem bin ich irgendwie unzufrieden mit dem Quellcode... wir haben im Studium immer wieder eingebläut bekommen, dass man sich bei der Modellierung der JavaKlassen am besten an der Realität orientiert, sprich: modelliere eine Klasse Zombie so, wie du ihn dir auch in wirklichkeit (ok blödes Beispiel ) vorstellen würdest.

Eine weitere "Regel" ist, dass man bei Klassenattributen unbedingt das Geheimnisprinzip wahren soll - mache alles möglichst Private und baue getter bzw. setter mit ein...

Um dann den Zugriff auf eine Klasse so gering wie möglich zu halten mache so wenig getter und setter wie möglich, sondern rufe lieber eine Zentrale Methode, wie z.b. "update()" auf, die dann Klassenintern alles selbstständig regelt...

Mit diesen drei Grundsätzen, die ja eigentlich schon irgendwie Sinn machen, habe ich einen Quellcode geshreiben, der zwar alles schön strukturiert - an dem mich aber einige Dinge vom Zugriff her massiv stören. Um zu erläutern, was genau ich meine hab ich mal den Aufbau des Spiels grob als UML-Diagramm dargestellt.




Uploaded with ImageShack.us


Erläuterung:

Spiel hat 3 Attribute, die jeweils spielrelevante Objekte separat
organisieren sollen.
Es sieht momentan so aus: Spiel.update() ruft drei Methoden auf:
1. interfaceverwaltung.update()
2. waffenverwaltung.update()
3. zombieverwaltung.update()

Diese rufen wiederrum selbst die updateMethoden ihrer Unterobjekte auf
z.B. die der Gun-Objekte und Zombie-Objekte.

Das gleich läuft mit der render()-Methode, den key- und
mouseListenern...

Stellt euch vor man feuert auf einen Zombie. Die keyPressed
Methode der Waffenverwaltung liefert ein Ereignis an die KeyPressedMethode der
aktuell ausgewälten Gun. Dann wird intern eine Kugel vom Magazin
abgezogen und so weiter... alles schön und gut.

Gleichzeitig soll aber auch überprüft werden, ob ein Zombie getroffen wurde. Also muss bei
einem wirklcihen Schuss (nicht bl0ß bei einem Klick) ein Event in der Zombie-mousePressedMethode ausgelöst werden.

Die einfachste Möglichkeit wäre es also das mousePressed-Event an die zombieverwaltungsklasse
direkt aus der GunKlasse zu übergeben. Denn - wenn z.B. das Magazin leer ist, wird auch nicht gefuert und dann muss auch keine Kollision aufgerufen werden.

Was habe ich also getan? Ich habe an die GunObjekte einInstanz von zombieVerwaltung übergeben,
um diese von der GunKlasse aus aufzurufen.

Macht man das so??? Wäre es nicht sinvoller die Zwischenebene der ganze VerwaltungsKlassen wegzulassen und einfach NUR eine Gun- und eine ZombieKlasse anzulegen, deren Objekte dann direkt in Spiel.java erzeugt und verwaltet werden?


liebe Grüße
Keltis

 

[Fu3L]

Die Verwaltungsklassen sollten im Idealfall von der Eingabe getrennt sein.

Eine Möglichkeit der update Methode im Spiel.java wäre folgende Umsetzung:

-Input. Was für ein Input: Schuss:
  boolean geschossen = Waffenverwaltung.schieße 
  wenn(geschossen)
    boolean zombieGetötet =  ZombiVerwaltung.schieße an position (berechne WeltPosition des klicks) 
      wenn(zombiegetötet)
        increaseScore
        playSound

Dabei könnte zombiegetötet auch ein int sein, dass die erzielte Punktzahl angibt, je nach Zombie.
Soltlest du mehr zurückgeben müssen, kanns auch ein ResultObjekt geben, ist klar.

 

[k3ltis]

Hab ich das richtig verstanden?

NUR in der Spiel.java soll ein Listener sein? Das würde bedeuten, dass ebenfalls NUR in der Spiel.java die Eingabe mit einer If-Kasakde vorselektiert wird um dann die entprechenden Methoden der VerwaltungsKlassen aufzurufen.

Kannst du mir das mit dem Input etwas genauer erläutern?


gruß
keltis

 

[Fu3L]

Ja, das hast du richtig verstanden. Es sollte nach Möglichkeit nur ein System (das kann eine einzige Klasse sein), die sich mit dem Input befasst. Und diese wandelt das dann in Spielaktionen um, wie etwa "es wurde geschossen". Im Menü (sofern es eins gäbe) könnte man ja auch klicken und es wäre kein Schuss. Für sowas ist diese Trennung sinnvoll.

Dann holt das Spielupdate die angesammelten Inputs vom Inputhandler ab und sieht zB, dass ein Schuss vom Spieler getätigt wurde. Es guckt dann, ob das tatsächlich möglich ist und lässt dann prüfen, ob da wo der Maus Cursor ist, auch ein Zombie ist und ob der dadurch getötet wird.

 

[k3ltis]

Vielen Dank Fu3l,

bin gerade dabei meinen Code "umzudichten". Es sieht schon nach halben weg gleich viel besser aus