Objekte eines Würfelspiels

[Kackfohgel]

Hallo,

ich programmiere gerade ein kleines Würfelspiel.

Ziel des Spiels ("Schlag den Raab" hat mich da auf die Idee gebracht) ist es möglichst schnell 50 Punkte zu erwürfeln. Man darf so lange würfeln, bis man eine 6 gewürfelt hat (dann gehen alle noch nicht gesicherten Punkte verloren) oder man seine Punkte sichert. In beiden Fällen ist dann erstmal der Gegner/Mitspieler an der Reihe.

Ich habe die Programmlogik zunächst einmal funktional programmiert mit zwei Klassen Spiel und Spieler. Nun habe ich versucht, dass Ganze etwas objektorientierter anzugehen und gleichzeitig in einer GUI zu verpacken. Bisher habe ich ein gutes Gefühl dabei auf dem richtigen Weg zu sein (jedenfalls habe ich derzeit eine funktionierende Vorabversion*). Woran es derzeit in erster Linie hapert ist mehr die Logik als der Code. Deshalb und da ich mich bisher noch nicht wirklich um Kapselung usw. gekümmert habe, möchte ich es auch erstmal ohne meinen bisherigen Code probieren.

Gehört eine Methode würfeln z. B. eher in eine Spielerklasse, wo die ermittelte Zufallszahl von 1 bis 6 direkt den Spielerattributen zugewiesen wird und die weiteren Aktionen (z. B. Spieler bei 6 auf Inaktiv setzen bzw. bei 1-5 eine Entscheidungsabfrage (Weiter?/Schieben?)) direkt in der Spielerklasse erfolgen oder wäre die Ermittlung der Zufallszahl eher die Aufgabe einer Klasse Würfel und der Spieler ruft eine Methode wuerfel.wuerfeln() auf und bearbeitet dann den Return (die Augenzahl) wie oben?

In diesem Fall wäre die Aufgabe der Klasse Würfel sehr einfach => Ermitteln der Zufallszahl (Ok, mit der GUI vlt. noch Aktualisierung des Fensters mit den aktuellen Augen evtl. mit einer kleinen Animation). Womit ich bei der nächsten Problematik wäre. Gehört die gesamte Darstellung des Würfels (paint) und der Spielernamen (JLabel) in die Klasse Spielfeld (JPanel) und aktualisiert das Würfeln lediglich das Spielfeld oder ist auch die Selbstdarstellung der Klassen eine Aufgabe die eher in die Klasse selbst gehört. Für Variante 1 spricht, dass alles was die Darstellung betrifft übersichtlich in einer Datei untergebracht ist. Objektorientiert könnte ich beides erklären:
Das Spielfeld-JPanel ist die Tafel und dort wird ja nicht der Spieler selbst drangenagelt sondern nur der Name angeschrieben. Auch wird dort nicht der Würfel festgeklebt sonder lediglich die aktuelle Augenzahl aufgemalt.
Auf der anderen Seite gehört zu den Eigenschaften des Objektes doch auch irgendwie das Aussehen und das spricht dafür, dass auch dieses in der Klasse selbst definiert wird.
Oder bin ich komplett auf dem Holzweg und das eine ist das Spielfeld, dass andere der Spieler oder der Würfel und dann gibt es noch ein Objekt Namensschild und Würfelanzeige oder Ähnliches?

Welche/wieviele Klassen/-aufteilung empfehlt ihr?

Ich hoffe, das kann man so abstrakt erklären/beantworten. Objektorientierung klingt theoretisch eigentlich so logisch und einfach, aber gerade als Anfänger neigt man doch schnell dazu (zumindest ist das bei mir so) prozessorientiert zu denken.

___
*Falls es für die Beantwortung hilfreich ist und ihr versprecht mich nicht zu hart ranzunehmen ;-) stelle ich meinen bisherigen Code natürlich gerne zur Verfügung

 

[TryToHelp]

Erstmal die Idee des Spiel klingt interessant,

Ich würde den Würfel als eigene Klasse machen, da es ja auch im realen Leben ein eigenes Objekt ist und man könnte so zum beispiel leicht das spiel varieren mit anderen würfeln, z.b. einem w20 oder w2 (ach mist das heißt dann ja Münze)

Generell würde ich Darstellung und Logik trennen, dann lässt sich leicht die GUI bzw. Darstellung ändern, aber nichts an der Logik, z.b. der Logig ist es egal, ob sie auf der Konsole, einer Gui, über das Netzwerk oder einer KI die aufrufe bekommt.

Aber das ist nur meine Meinung, ob diese gut ist oder nicht, sei mal dahin gestellt ;-)

 

[Kackfohgel]

Hallo und vielen Dank für deine Antwort.

Erstmal die Idee des Spiel klingt interessant,

Naja, die Idee ist wohl schon uralt und die Variante wird in Würfelclubs und Kneipen angeblich rauf und runter gespielt. Mich haben vor allem die relativ einfachen Regeln dazu bewogen, mich an diesem Spiel zu probieren.

Ich würde den Würfel als eigene Klasse machen, da es ja auch im realen Leben ein eigenes Objekt ist und man könnte so zum beispiel leicht das spiel varieren mit anderen würfeln, z.b. einem w20 oder w2 (ach mist das heißt dann ja Münze)

Die Wartung mögliche Änderungen/Ergänzungen hatte ich bisher bei dieser Entscheidung garnicht mit einbezogen, aber genau das hat mich jetzt überzeugt. Btw: Da fällt mir ein Kapitel in "Java von Kopf bis Fuß" ein, wo die das in einem lustigen Beispiel erklären bei dem ein Prozessorientierter gegen einem Objektorientierten antritt um bei der Chefin zu landen und der P0 zwar zu Beginn die Nase vorne hat, aber der OO durch die späteren Änderungswünsche schnell aufholt. Wie konnte ich das nur vergessen ... vlt. fehlt mir die gutaussehende Auftraggeberin ;-)

Generell würde ich Darstellung und Logik trennen, dann lässt sich leicht die GUI bzw. Darstellung ändern, aber nichts an der Logik, z.b. der Logig ist es egal, ob sie auf der Konsole, einer Gui, über das Netzwerk oder einer KI die aufrufe bekommt.

Das hört sich auch plausibel an und ist von Prinzip auch der Ansatz, den ich bisher verfolgt habe

Aber das ist nur meine Meinung, ob diese gut ist oder nicht, sei mal dahin gestellt ;-)

Vom Prinzip will ich ja auch Meinungen hören. Den Königsweg nach Rom gibt es hier vlt. nicht, aber bevor ich mich in die falsche Richtung aufmache, dürfen mir die erfahrenen Wanderer gerne ihren Weg nach Rom zeigen ;-)

 

[Marco13]

Auch wenn man das für den Anfang und so ein "einfaches" Spiel nicht als unbedingte Empfehlung oder gar "Umsetzungsvorschrift" ansehen sollte, könntest du dir mal MVC (Model View Controller) ansehen. Gibt auch FAQ-Einträge dazu

 

[Kackfohgel]

Hallo Marco,

vielen Dank für deine Antwort.

Das MVC-Tutorial hatte ich schonmal gelesen. Werd es mir aber nochmal zu Gemüte führen. Denke, als ich es das erste mal studiert habe, war mir das noch zu theoretisch und ich wusste noch nicht wirklich, welche praktischen Vorteile mir das bringen kann. Ist halt auch schwierig, bei den ganzen Input im Selbststudium das wirklich relevante herauszufiltern und zu behalten

MfG

 

[Marco13]

Wie angedeutet: Man kann bei MVC viel diskutieren und philosophieren (und das wird hier auch immer wieder gerne gemacht ) aber ... nur um zu verhindern, dass dann irgendwann die Zeile
class Würfel extends JLabel
irgendwo auftaucht

 

[Kackfohgel]

... nur um zu verhindern, dass dann irgendwann die Zeile
class Würfel extends JLabel irgendwo auftaucht

Du scheinst ein Hellseher zu sein
So sah meine Klasse wirklich noch aus (nur als ein Überbleibsel vom Ganzen hin und her probieren). Hab das jetzt schnell gelöscht (da es in der derzeitigen Version eh nicht mehr genutzt wurde), genauso wie die überflüssigen imports.

Hab jetzt auch beschlossen, erstmal aufzuräumen, die ganzen Auskommentierungen zu löschen, anständig zu Kapseln usw. .... bevor doch mal jmd. den Code sehen will. Vlt. blick ich dann auch selber wieder besser durch.

 

[Kackfohgel]

Beim Überarbeiten meines Programms fällt mir gerade auf, dass ich aus einer Klasse heraus eine Methode einer anderen Klasse aufrufe und dabei das (komplette) Objekt mit this übergebe.

chef.class

Knecht knecht = new Knecht();
int fruststufe = 8;
...
knecht.tuwas(this);
...

knecht.class

...
tuwas(Chef chef) {
 if(chef.fruststufe > 10) { /* tue ich was */ } else { /* so tun als ob */ }
}
...

Eigentlich brauche ich für die derzeitige Methode ja lediglich die Fruststufe und könnte die Methode auch anpassen und nur knecht.tuwas(this.fruststufe); aufrufen. Das hätte erstmal den Vorteil, dass ich den Knecht nicht mit den ganzen anderen Problemen/Attributen des Chefs zumülle und er sich auf seine Arbeit konzentrieren kann. Auf der anderen Seite macht es Anpassungen einfacher, weil ich für mehr benötigte Informationen lediglich die tuwas-Methode des Knechtes anpassen muss.

In meinem Fall kommt noch hinzu, dass ich die Fruststufe zur Weiterverarbeitung in einen String umwandeln muss (für die Ausgabe in einem JLabel) und hier stellt sich die Frage, wo ich den Fruststufen-Wert caste, wenn ich nicht das komplette Chefobjekt übergebe: Bereits den gecasteten Wert übergeben oder in der Methode casten?

Vlt. ist beides am Ende wieder eine Geschmacksfrage, aber ich würde gerne eure Meinungen dazu hören.


____
Ich hoffe, dass Beispiel ist jetzt nicht allzu blöd, aber ein Schöneres ist mir jetzt auf die Stelle nicht eingefallen.

 

[TryToHelp]

Wie angedeutet: Man kann bei MVC viel diskutieren und philosophieren (und das wird hier auch immer wieder gerne gemacht ) aber ... nur um zu verhindern, dass dann irgendwann die Zeile
class Würfel extends JLabel
irgendwo auftaucht

Das war ja auch mein Vorschlag, zwar nicht ganz so groß wie MVC, die Logig und die Darstellung zu trennen ;-)

Zu deiner Frage, also ich würde dann nur die Fruststufe, als nicht das ganze Objekt übergeben, da der Knecht garnicht das wissen haben muss über das andere Objekt.
Das Casten würde ich bei dem Knecht, als der aufgerufenen Funktion machen, weill dann muss der Chef nicht wissen, was der Knecht will, sondern rein mit seinem Objekt so arbeiten wie er es kennt ;-)

 

[Kackfohgel]

Vielen Dank für deine weitere Antwort. So wie du das erklärt hast klingt das sehr logisch und nachvollziehbar. Werd es so umsetzen.

 

[Landei]

Wahrscheinlich zu spät, aber ich würde vorschlagen, die erste Version eines solchen Spiels immer erst auf der Konsole umzusetzen. Da kommt man gar nicht erst in Versuchung, Programmlogik mit GUI zu vermanschen.

 

[Kackfohgel]

Hi Landei,

du wirst lachen, aber meine erste Zwei-Klassen-Version (Spiel, Spieler) war auf der Konsole (mit Ausnahme der Abfrage, ob nochmal gewürfelt oder geschoben werden soll mittels JOptionPane). Hatte mir das dann auch relativ einfach vorgestellt mit der Erweiterung um eine grafische Ausgabe. Aber aus der Vorstellung einfach ein, zwei weitere Klassen für die grafische Darstellung zu erstellen, bin ich dann schnell in die Realität zurückgeholt worden, da die Konsolenversion relativ unsauber und nicht wirklich objektorientiert war. Wollte dann das "aufräumen" und die GUI in einem Schritt machen und da steck ich jetzt gerade mittendrin bzw. seid eurer Hilfe gestern sehe ich schon Licht am Ende des Tunnels.

Bin guter Dinge das Spiel am Wochenende fertig stellen zu können. Habe aber schon neue Features im Kopf - so schnell werdet ihr mich nicht los ;-)

MfG

 

[TryToHelp]

... bzw. seid eurer Hilfe gestern sehe ich schon Licht am Ende des Tunnels.

Bin guter Dinge das Spiel am Wochenende fertig stellen zu können. Habe aber schon neue Features im Kopf - so schnell werdet ihr mich nicht los ;-)...

Das freut mich, das dir die Hilfe weiterhilft, ohne das man dir den ganzen Code direkt vorkauen muss, sondern du wirklich nur ideen / inputs suchst und diese dann selber umsetzt und scheinbar mit spaß dabei bist, was ein wichtiger teil ist, beim Erlernen des Programmierens.

Das hört sich doch gut an, kannst ja wenn du es soweit hast ja mal Zeigen, was du hast, würde mich interessieren und helfe auch gerne weiter wenn ich kann =)