Monopoly UML Umsetzung

[holle]

Hallo, ich bin gerade Dabei mit einem Kumpel Monopoly nachzuprogrammieren. Wir haben bereits ein UML-Diagramm erstellt und den Grundaufbau des Programms festgelegt. Das Spielfeld wird bereits gezeichnet und ein Spieler kann sich über das Spielfeld bewegen.
Das Spielfeld setzt sich aus insgesamt 40 Feldern (Squares) zusammen. Von der Oberklasse "Square" wurden somit für jeden Spielfeldtyp (Strasse, Los, Freiparken, ...) eine Unterklasse erstellt. Jede Unterklasse besitzt einen eigenen Zeichenbefehl und eine Methode "playAction". Die Methode "playAction" soll die Anweisungen enthalten, die der Spieler ausführen soll, sobald er auf ein entsprechendes Feld kommt.
Unser Problem ist jetzt, das die Klasse "Square" im Besitz vom "Gameboard" ist und somit nicht direkt auf den Gamemaster zugreifen kann, der das gesamte Spiel leitet. Somit kann ich in der Klasse "Square" z. B. nicht "Spieler1.geheInDasGefängnis" aufrufen. Habt ihr eine Idee, wie ich das realisieren kann?
Ich habe mal unser UML-Diagramm und das Programm im jetzigen Zustand angehangen...

- Marcel -

[Cube]

Kann uns denn keiner bei dem Problem helfen?
Wir haben im Netz auch einen Java Code gefunden, der sich auch auf einen ähnlichem UML wie unserem aufbaut. da wurde das ganze so gelöst:

Delphi-Quellcode:

JailCell jail = (JailCell)(GameMaster.instance().getGameBoard().queryCell("Jail"));

Allerdings wüssten wir nicht wie wir das in Delphi übertragen sollten.
Unser Problem ist halt wie gesagt, dass wir den GameMaster vom Square nicht aufrufen können, der er nicht von diesem benutzt oder besessen wird.

Für Vorschläge wären wir sehr dankbar ^_^

[DGL-luke]

Naja, dazu musst du der Zelle wohl noch die entsprechenden Instanzen übergeben, z.B. den Gamemaster und den Spieler, der auf die Zelle tritt.

Ungefähr so:

Delphi-Quellcode:

procedure TPlayer.MoveTo(Cell: TCell);
begin
  Cell.StepOnto(self);
end;

[Der_Unwissende]

Hi,
ich glaube ich hab da noch was falsch verstanden.
Es gibt einen GameMaster, der leitet das Spiel? An sich klingt das nach einem sauberen Ansatz, man hat gerne eine zentrale Komponente, die alle anderen kennt (ein Controller). Hier gilt aber nicht und vice versa, vielmehr sollten die anderen Komponenten nur sehen, was sie wirklich sehen müssen.
Ich frage mich ehrlich gesagt, warum die Felder Wissen über GameBoard oder GameMaster haben sollten? Ich meine der GameMaster verwaltet das Spiel. Dass heißt er kennt alle Spieler (und ihre Position auf dem Spielfeld), weiß wer gerade dran ist und kennt die Würfel. Nun wird einfach der Spieler der gerade dran ist bewegt (auf das Feld XYZ). Erreicht der Spieler nun ein Feld, so ist dies nur möglich, weil der GameMaster den Spieler dort hin setzt. Das heißt auch, dass der GameMaster zu dem Zeitpunkt weiß welches Feld nun von welchem Spieler erreicht wurde. Entsprechend kann nun der GameMaster eine Funktion playActiond es Feldes (die es im Diagram glaube ich nicht gibt?) aufrufen. Dieser Funktion kann als Argument z.B. der Spieler übergeben werden.
Der GameMaster kennt hier den Zug und vermittelt zwischen den einzelnen Beteiligten, genau dafür sollte er da sein.

Was euer Diagram/Konzept angeht, so glaube ich solltet ihr euch auch da nochmal genauer anschauen, was ihr wie löst. So wäre es z.B. stärker OO, wenn ihr z.B. von Feldern eine weitere Unterklasse der verkaufbaren Felder erstellt. Nur solche haben dann einen Besitzer, sind überhaupt verfügbar, haben einen Preis, etc.

Na ja, schaut einfach mal. Die eigentliche Frage habe ich hoffentlich beantwortet?

Gruß Der Unwissende

[holle]

Zitat:

Entsprechend kann nun der GameMaster eine Funktion playActiond es Feldes (die es im Diagram glaube ich nicht gibt?) aufrufen. Dieser Funktion kann als Argument z.B. der Spieler übergeben werden.

Danke für die Antwort. Das heißt ich übergebe der Funktion playAction des Squares den Spieler1 vom Typ Spieler und das Square kann dann mit Spieler.geheInDasGefängnis auf den Spieler zugreifen. Wie kann ich dann eine Information auf der GUI ausgeben wie "Spieler1 ist in das Gefängnis gegangen"? Muss ich dann die GUI auch übergeben?

- Marcel -

[DGL-luke]

Naja... könntest du. Ist aber, wie Der_Unwissende sagt, ein wenig unsauber. EIne bessere Möglichkeit fällt mir jetzt aber auch nicht ein... vielleicht kannst du das als funktionsergebnis zurückgeben.

[OregonGhost]

Könnte nicht der GameMaster dafür Ereignisse haben, die die GUI abfängt?

[Der_Unwissende]

Ich schmeiß hier mal den Begriff Callback bzw. mehr OO auch das Observer-Pattern in den Raum. Da findet ihr zwei Möglichkeiten (das Observer-Pattern kann auch über Callbacks realisiert werden, schöner ist hier dann aber das Kommando-Pattern), um über bestimmte Ereignisse zu benachrichtigen.

An sich wäre aber die eigentliche Vorgehensweise, dass du weißt was das Feld machen kann. Der GameMaster prüft also hier alle Optionen die das Feld für diesen Spieler bietet (welche auch immer dass sind, z.B. kaufen oder Haus/Hotel bauen,...). Diese Möglichkeiten fragt der Gamemaster ab. Kommt der Spieler hier auf ein Ereignisfeld, wäre das Ereignis das ziehen und zeigen einer Karte. Auch dass kann dann direkt der GameMaster (oder ein andere Controller) übernehmen. Kommt es nun dazu, dass der Spieler ins Gefängnis muss, direkt dorthin muss, nicht über Los geht, keine 4000 einzieht, dann ist dies wiederum das Ereignis dieser Karte. Wurde eine Karte gezogen, kann hier also die Meldung der Karte angezeigt und die beschriebene Aktion ausgeführt werden. Wo sich ein Spieler dabei befindet ist doch in seiner Position geregelt? Na jedem Zug muss hier also nur ein Update auf dem Spielfeld für diesen Spieler durchgeführt werden, wobei die aktuelle Position des Spieler berücksichtigt wird.