Klassen Aufbau Kartenspiel

[DMSB12]

Hallo,

ich möchte als Einstieg ein MauMau-Kartenspiel programmieren, bin aber noch in der Entwurfsphase
und erhoffe mir von euch ein paar Anregungen und Korrekturen.

ich brauche auf jeden Fall die class Spielkarte, die die Attribute festlegt. da diese ja unveränderlich sind, wärens dann final String FARBE, final int WERT und final String SPEZIAL (für die Karten mit Spezialfähigkeiten: acht, sieben, Bube) und int id (zum sortieren).
Als konstruktor Spielkarte(String f, int w, String s) {..}
Methode public ausspielen(Spielkarte s) { entfernen aus dem array: Hand, hinzufügen in den array: Spielfeld, ggf. Spezialfähigkeit }
Methode public ziehen(Spielkarte s) { entfernen aus dem array: Stapel, hinzufügen in den array: Hand}

weitere Klassen:

class Bereiche
class Hand extends Bereiche
class Stapel extends Bereiche
class Spielfeld extends Bereiche

jede der o.g. Klassen "verwaltet" den array, der die Spielkarten enthält

so in etwa dachte ich mir die Sache. ich bin noch neu im OOP-Bereich und bin für jede konstruktive Kritik dankbar

 

[Michael...]

Methode public ausspielen(Spielkarte s) { entfernen aus dem array: Hand, hinzufügen in den array: Spielfeld, ggf. Spezialfähigkeit }
Methode public ziehen(Spielkarte s) { entfernen aus dem array: Stapel, hinzufügen in den array: Hand}

Das wäre wohl eher Methoden für Hand und Stapel. Eine Karte muss eigentlich nichts "können" ausser Farb und Wert preisgeben.

class Bereiche
class Hand extends Bereiche
class Stapel extends Bereiche
class Spielfeld extends Bereiche

Was ist Bereiche und warum erweitern alle anderen Klassen Bereiche?

 

[Asgar13]

Spezial kannst du auch über deinen "Wert" regeln.

---

Es gibt bei deiner Überlegung ein Problem:

Farbe: Rot
Wert: 10

Herz 10
oder
Karo 10
?

---

Es können noch weitere Methoden dazukommen z.B. neuer Stapel, falls der alte Stapel keine Karten mehr hat.

 

[XHelp]

Es gibt bei deiner Überlegung ein Problem

Es ist maumau, kein Poker

 

[DMSB12]

Was ist Bereiche und warum erweitern alle anderen Klassen Bereiche?

ich dachte mir das so: was haben die "Spielbereiche" Hand, Stapel (verdeckter Nachziehstapel) und Spielfeld (da wo die offenen ausgelegten Karten liegen) gemeinsam? dass dort Karten hingelegt bzw. gezogen werden und die dort befindlichen Karten in einem container "verwaltet" werden.

Spezial kannst du auch über deinen "Wert" regeln.
Es gibt bei deiner Überlegung ein Problem:

Farbe: Rot
Wert: 10

Herz 10 oder Karo 10 ?

Es können noch weitere Methoden dazukommen z.B. neuer Stapel, falls der alte Stapel keine Karten mehr hat.

ne das stimmt schon. Farbe heisst bei Kartenspielen die Sorte, also Pik, Kreuz, Herz, Karo sind Farben.

Liege ich im Aufbau komplett falsch? was könnte ich anders machen?

Der Hinweis mit der Methode, die eher zu den Bereichen als zu den Karten passt greife ich auf.

Welche container-Lösung würdet ihr vorschlagen?

 

[hdi]

Also hier mal mein Senf:

Wie Michael schon sagte würde ich in eine Karte auch lediglich Wert und Farbe reinnehmen. Diese Spezialfähigkeit die manche Karten haben kannst du wohl nur im Spielkontext umsetzen, also deren Effekt. Welche Spezialfähigkeit es ist leitet sich ja aus Wert/Farbe an, also wäre es redundant dafür noch eine dritte Variable einzuführen. D.h. das sollte von einer höheren Instanz ermittelt werden. Du musst objektorientiert denken: Eine Karte "kann" nichts. Es ist nur ein Stück Papier (gut, Objekt ) mit zwei Informationen (Farbe und Zahl). Im Programm vllt noch eine dritte Information für die grafische Darstellung (Bilddatei oder -pfad).

Für Wert und Farbe an sich würd ich jeweils ein

enum

machen. Immerhin gibt es eine festgelegte Anzahl an Farben und Werten und die ändern sich auch nicht. Mit nem enum hast du auch den Vorteil dass du per == prüfen kannst, was wie vorhin angesprochen grundsätzlich gefährlich sein kann (bei enums ist garantiert dass jede Instanz nur genau einmal existiert, deswegen ist die Identitätsprüfung sicher nicht falsch).

Und wo wir grad über den Vergleich reden, und diese equals-Sache auf die du aufmerksam gemacht worden bist: Für den Vergleich von Karten im Spiel später solltest du die equals-Methode in der Klasse Karte überschreiben. Wichtig dabei: Am besten (bzw. ein MUSS) gleich eine eigene (und bitte passende) hashCode()-Implementierung hinterherschieben. Mehr zur Verbindung zwischen equals und hashCode kannst du den Beschreibungen dieser beiden Methoden aus der API entnehmen.

Und das führt mich zu deinem "Container" von Karten: Du kannst nen Stack nehmen (zB ArrayDeque) das eignet sich sehr gut für einen Kartenstapel, weil es das Ziehen und Ablegen von Karten schon durch die interne Struktur impliziert. Du kannst aber auch über eine ArrayList o.ä. gehen. Diese Collections sind btw (fast?) alle Hash-Table gestützt, deswegen solltest du den vorigen Absatz auch bitte ernst nehmen. Da kann schnell was schief gehen (und sei es nur die Performance) wenn so Methodne wie contains() oder remove() auf einer Collection aufrufst und eine Inkonsistenz zwischen equals und hashCode hast.

...and now, something completely unrelated (was aber für dein Spielchen sicher nützlich ist):

Collections.shuffle()

 

[hdi]

Ich schieb gleich noch was hinterher: Ich will dir nicht den Spaß / Lerneffekt nehmen, also wenn du was mit meinem letzten Beitrag anfangen kannst dann probier dich dran.

Aber für den Fall dass dir der Beitrag jetzt keine Hilfe war, hier etwas konkretes:

public class Karte{

   private final Farbe farbe;
   private final Wert wert;

   public Karte(Farbe farbe, Wert wert){
       this.farbe = farbe;
       this.wert = wert;
   }

   public Farbe getFarbe(){
       return farbe;
   }

   public Wert getWert(){
       return wert;
   }

   @Override
   public boolean equals(Object o){
       if(!(o instanceof Karte)){ 
           return false;
       }
       Karte andereKarte = (Karte)o;
       return this.farbe == andereKarte.farbe && this.wert == andereKarte.wert;
   }

   @Override
   public int hashCode(){
       // die Zahlen sind willkürlich gewählt und sollen nur die Wahrscheinlichkeit verringern, 
       // dass die Kombination von Farbe-Hashcode und Wert-Hashcode auch bei unterschiedlicher
       // Farb-Wert-Konstellation das selbe Ergebnis liefert
       return 3041 + farbe.hashCode() + 7 * wert.hashCode();
   }
}

public enum Farbe{
 
   EICHEL, GRAS, HERZ, SCHELLEN; // sry ich komm aus Bayern :D
}

public enum Wert{

   SIEBEN, ACHT, NEUN, ZEHN, UNTER, OBER, KOENIG, ASS;
}

Eine Karte erzeugst du dann z.B. so:

new Karte(Farbe.GRAS, Wert.NEUN);

 

[jgh]

...

public enum Farbe{
 
   EICHEL, GRAS, HERZ, SCHELLEN; // sry ich komm aus Bayern :D
}
...

Das ist nicht zu entschuldigen :lol:

 

[bERt0r]

Nur so als Anmerkung: Ob du bei 20 oder 36 Karten merkbare Performanceeinbussen bei Collections stößt, egal wie schlecht die Hashfunktion ist wage ich zu bezweifeln

 

[DMSB12]

@Override
   public boolean equals(Object o){
       if(!(o instanceof Karte)){ 
           return false;
       }
       Karte andereKarte = (Karte)o;
       return this.farbe == andereKarte.farbe && this.wert == andereKarte.wert;
   }

wozu soll das gut sein? es gibt jede Karte nur 1x. und wenn eine Karte per Methode aus der Hand auf das Spielfeld gelegt werden soll (ausspielen), dann wird nur geprüft, ob sie gelegt werden darf. Voraussetzungen: gleiche Farbe ODER gleicher Wert wie oberste Karte des Spielfelds, oder es ist ein Bube (für dich Unter).
Analog dazu die Frage, wozu ich den HashCode brauche?

Das Collections.shuffle() geht auf alle Collections? also auch auf ein normales Array? denn Mischen muss ich ja nur bei Spielbeginn ALLE Karten und später dann den Spielstapel (-die letzten 3 gespielten Karten), wenn der Zugstapel leer ist.

Zuletzt noch die Frage zum Enum. Das hab ich noch nicht begriffen. aber wenn ich 1x alle 32 Karten erstelle, dann würden doch normale final string-Attribute reichen, oder? denn diese Attribute brauche ich doch später nur für den Abgleich, ob die Karte spielbar ist, oder?

@hdi: Ich danke dir für deine Anregungen und den anschaulichen Code. Meine Rückfragen sind aufgrund meines noch unzureichenden Verständnisses zu verstehen (drum poste ich ja auch in der Anfänger-Sektion)

 

[faetzminator]

wozu soll das gut sein? es gibt jede Karte nur 1x. [...]
Analog dazu die Frage, wozu ich den HashCode brauche?

Du wirst deine Karten irgendwo in eine Collection legen müssen. Diese Collections benötigen (meist) die korrekte Implementation dieser Methoden.

 

[DMSB12]

Du wirst deine Karten irgendwo in eine Collection legen müssen. Diese Collections benötigen (meist) die korrekte Implementation dieser Methoden.

ich habe noch immer nicht verstanden zu welchem Zweck? was sollen diese Methoden machen?

 

[langhaar!]

@Override
  dann wird nur geprüft, ob sie gelegt werden darf. Voraussetzungen: gleiche Farbe ODER gleicher Wert wie oberste Karte des Spielfelds, oder es ist ein Bube[/QUOTE]

Es fehlt der Fall, dass kein Bube auf einen Buben gelegt werden darf.

Den HashCode brauchst du nicht. Er dient bei manchen Datenstrukturen zum effizienteren Abspeichern der Daten, was eher bei hundertausenden Daten interessant ist als bei 32.

 

[jgh]

ich pers. würde den Aufbau etwas anders gestalten als du mit deinen Bereichen.

Ein Spieler besitzt Spielkarten, also hat ein Attribut von Spielkarten. Und dementsprechend sind deine Überlegungen bez. Bereiche imho obsolet.
Die Spieler bieten zudem Methoden an, um Spielkarten zu entfernen und aufzunehmen, evtl. auch Punkte, Namen, etc und irgendwas wie [c]boolean istAmZug[/c]

Die Spielkarten würde ich auch als enum implementieren, evtl. sogar noch ein Verweis auf eine Fotodatei zur entsprechenden Karte.

Ich könnte mir eine Klasse MauMau vorstellen, die einen Satz an Spielkarten und Spielern besitzt und dann entsprechend der Spiellogik, 32|52 Karten auf 1-x Spieler verteilt.
Aber du machst das schon...

Keep ist small
weder die Spieler müssen wissen, was sie spielen...noch muss die Spielkarte wissen, wem sie gehört.

PS:
ist natürlich auch nur so aus dem hohlen Bauch heraus...appropos Frühstück

 

[faetzminator]

ich habe noch immer nicht verstanden zu welchem Zweck? was sollen diese Methoden machen?

Siehe Galileo Computing :: Java ist auch eine Insel – 9.3 Object ist die Mutter aller Klassen bzw. Galileo Computing :: Java ist auch eine Insel – 9.3 Object ist die Mutter aller Klassen

 

[DMSB12]

ich pers. würde den Aufbau etwas anders gestalten als du mit deinen Bereichen.

immer her mit den Vorschlägen

Die Spieler bieten zudem Methoden an, um Spielkarten zu entfernen und aufzunehmen, evtl. auch Punkte, Namen, etc und irgendwas wie [c]boolean istAmZug[/c]

Ich habe noch Probleme mit dem OOP-Aspekt von Java (komme aus dem Basic-Bereich). In den Tuts, die ich derweil "konsumiere" wird immer für alles und jeden eine Klasse erstellt und mit Beziehungen "vollgestopft". verwirrt ich bin...
Dass es Methoden geben muss, die a) Kartenobjekte von Array zu array schieben bzw. die Karten verwalten und b) die Auswirkungen von ausgespielten Karten darstellen, ist klar, aber in welche Klasse gehören solche Methoden? Karte? Spieler? Spielfeld? Maumau?

Ich dachte eigentlich, dass das Maumau eher eine Fingerübung für den Einstieg wäre, aus dem ich dann mein eigentliches Projekt weiterentwickle. hab ich mich wohl getäuscht.

Vielleicht sollte ich mich nochmal hinsetzen und zu Maumau ein Klassendiagramm und Objektdiagramme mittels UML erstellen, um mir über Aufbau, Ablauf und Zusammenhänge klarer zu werden.... oder?

 

[langhaar!]

Vielleicht sollte ich mich nochmal hinsetzen und zu Maumau ein Klassendiagramm und Objektdiagramme mittels UML erstellen, um mir über Aufbau, Ablauf und Zusammenhänge klarer zu werden.... oder?

Ob UML oder nicht, ist nicht so wichtig. Wichtig ist, dass du dir den Aufbau genau überlegst (und dich hier nicht von Implemetierungsdetails von Hash Funktionen verwirren lässt). Die Struktur ist das A und O.

Versuch, nicht in Begriffen wie Arrays etc. zu denken! Das ist für den strukturellen Aufbau zunächst nicht interessant.

Formuliere den Ablauf (ohne Java oder Programmierungsdetails!) in Worten und zieh die Klassen aus den Nomen und die Methoden aus den Verben.

Beispiel: Eine Anzahl von Spieler spielen das Spiel Mau Mau. Jeder Spieler bekommt Karten und legt sie, wenn er an der Reihe ist und die Karte passt, auf einen Stapel. Falls er keine Karte legen kann, muss der eine Karte von einem zweiten, umgedrehten Stapel ziehen.

Daraus könnte man ableiten, dass es eine Klasse Karte, Spieler, Spiel, Ablagestapel und Aufnahmestapel gibt.

Welche Beziehungen gibt es?
Ein Spiel besteht aus einer Anzahl von Spieler, in einer definierten Reihenfolge.
Ein Spiel besitzt einen Status: Spieler x am Zug oder Spiel beendet.
Zu einem Spiel gehört ein Satz Karten (dies muss nicht unbedingt ein 32 Karten Satz sein; es können doppelte vorhanden sein, Karten fehlen etc.)
Zu einem Spiel gehört ein Ablage- und ein Aufnahmestapel.
Das Spiel weist dem Spieler die anfänglichen Karten zu.

Ein Spieler besitzt eine Anzahl von Karten.
Er kann eine Karte spielen oder ziehen.

Eine Karte kann zu einer anderen Karte passen (Wert oder Farbe oder Bube aber kein Bube auf Bube ).

Der Ablagestapel besitzt eine Anzahl von Karten.
Es können Karten hinzugefügt werden.
Der Stapel kann - ausgenommen von der obersten Karte - entfernt werden und alle Karten verlieren.
(Dies ist der Fall, wenn der Aufnahmestapel leer ist)

Der Aufnahmestapel kann Karten verlieren.
Er wird zu Anfang gemischt.
Er kann neu aufgebaut werden; d.h. mit einer Anzahl Karten neu aufgebaut werden.
(Wenn er leer ist, wird er vom Ablagestapel neu gefüllt)

Bei den beiden Stapel lässt sich jetzt erkennen, dass nicht unbedingt eigene Klassen benötigt werden,
da es in Java bereits Datenstrukturen gibt, die über alle benötigten Eigenschaften verfügen,
aber prinzipiel kann man sich auf die oben skizzierte Weise überlegen, wie eine Zerlegung und ein Aufbau erfolgen kann.

Versuch auf diese Art ein Klassendiagramm zu entwerfen.
Und dann kann man sich irgendwann mal Gedanken machen, ob man z.B. die Karten eine Spielers in einer Liste einem Array oder sonstwie speichern möchte. Nicht beim Entwurf!

Obiger Entwurf ist natürlich nicht eindeutig oder ergibt sich zwangsläufig.
So könnte auch - statt dem Spiel - jeder Spieler einen Status 'ist am Zug' oder 'ist nicht am Zug' haben. Man könnte auch sagen, dass ein Spiel mit einem Set von Karten gespielt wird und jede Karte entweder einem Spieler oder einem Stapel zugeordnet ist.
Dann käme man zu einem ganz anderen Entwurf:
es gäbe eine Klasse Kartenset die alle Karten enthält und jede Karte hätte eine Zuordnung und könnte diese Zuordnung mitteilen oder ändern (Methoden der Karte).

 

[hdi]

wozu soll das gut sein? es gibt jede Karte nur 1x. und wenn eine Karte per Methode aus der Hand auf das Spielfeld gelegt werden soll (ausspielen), dann wird nur geprüft, ob sie gelegt werden darf. Voraussetzungen: gleiche Farbe ODER gleicher Wert wie oberste Karte des Spielfelds, oder es ist ein Bube (für dich Unter).
Analog dazu die Frage, wozu ich den HashCode brauche?

Spielt man Maumau nicht mit mehreren Kartenstapeln? Das ist doch quasi Uno, da gibt es mehrere Karten mit gleicher Farbe UND gleichem Wert?! Wenn es jede Karte (Farb-Wert-Konstellation) wirklich nur exakt 1x gibt, UND wenn du sicherstellst dass du über die gesamte Laufzeit des Programms jede Karte nur exakt 1x instantiierst (genau 36x new-Operator), dann brauchst du in der Tat weder equals() noch hashCode() zu überschreiben. Es ist nur so dass man equals() überschreibt wenn man eine eigene Gleichheit festlegen will (Standard ist Identität, d.h. genau das was auch == macht). Und wenn man equals() überscheibt sollte man analog dazu hashCode() überschreiben, so sieht es die API nun mal vor.

Nur so als Anmerkung: Ob du bei 20 oder 36 Karten merkbare Performanceeinbussen bei Collections stößt, egal wie schlecht die Hashfunktion ist wage ich zu bezweifeln

Ist natürlich richtig, es ging mir um's Prinzip.

Das Collections.shuffle() geht auf alle Collections? also auch auf ein normales Array? denn Mischen muss ich ja nur bei Spielbeginn ALLE Karten und später dann den Spielstapel (-die letzten 3 gespielten Karten), wenn der Zugstapel leer ist.

Nein, wie du der Methoden-Signatur entnehmen kannst geht es nur auf Listen. (List<?>)

Zuletzt noch die Frage zum Enum. Das hab ich noch nicht begriffen. aber wenn ich 1x alle 32 Karten erstelle, dann würden doch normale final string-Attribute reichen, oder? denn diese Attribute brauche ich doch später nur für den Abgleich, ob die Karte spielbar ist, oder?

Klar kannst du es mit String-Variablen machen. Aber enums bieten sich hier nun mal an. Ein enum impliziert u.a. nämlich dass es eine festgelegte Anzahl an verschiedenen Werten davon gibt, und dass sich diese auch nicht ändert. Du kannst enum-Werte genauso weiterverwenden wie Strings, z.B. eben für die Abfrage:

if(karte1.getFarbe() == karte2.getFarbe())

 

[langhaar!]

Spielt man Maumau nicht mit mehreren Kartenstapeln? Das ist doch quasi Uno, da gibt es mehrere Karten mit gleicher Farbe UND gleichem Wert?! Wenn es jede Karte (Farb-Wert-Konstellation) wirklich nur exakt 1x gibt, UND wenn du sicherstellst dass du über die gesamte Laufzeit des Programms jede Karte nur exakt 1x instantiierst (genau 36x new-Operator), dann brauchst du in der Tat weder equals() noch hashCode() zu überschreiben.

Mau Mau kann sowohl mit einem als auch mit mehreren Kartenspielen gespielt werden. Nichtsdestotrotz gibt es nach wie vor keinen Grund, Karten auf Gleichheit zu prüfen. Diese Erkenntnis wird im Spielgeschehen nicht gebraucht.

 

[Asgar13]

Es ist maumau, kein Poker

Bei maumau legt man die gleichen Zeichen oder die gleichen Werte übereinander.

ne das stimmt schon. Farbe heisst bei Kartenspielen die Sorte, also Pik, Kreuz, Herz, Karo sind Farben.

Wusste nicht, das du Zeichen, als Farbe meinst.

Spielt man Maumau nicht mit mehreren Kartenstapeln? Das ist doch quasi Uno, da gibt es mehrere Karten mit gleicher Farbe UND gleichem Wert?! Wenn es jede Karte (Farb-Wert-Konstellation) wirklich nur exakt 1x gibt, UND wenn du sicherstellst dass du über die gesamte Laufzeit des Programms jede Karte nur exakt 1x instantiierst (genau 36x new-Operator), dann brauchst du in der Tat weder equals() noch hashCode() zu überschreiben.

Mau Mau kann sowohl mit einem als auch mit mehreren Kartenspielen gespielt werden. Nichtsdestotrotz gibt es nach wie vor keinen Grund, Karten auf Gleichheit zu prüfen. Diese Erkenntnis wird im Spielgeschehen nicht gebraucht.

Ich glaube ihr redet aneinander vorbei.

hdi redet vom Stapel erstellen und
langhaar redet vom Spielen.

Wenn man den Stapel über

{stapelErstellen();}

public static stapelErstellen(){
for(int a=0;a<4;a++){//Zeichen
for(int i=0;i<13;i++){//Werte
Karte karte[i][a] = new Karte();
}
}
}

(Pseudocode, nur für die Logik)
erstellt, dann hat man pro "stapelErstellen()" jede Karte nur einmal drin. Dann brauchst du keine equals Methode, wie hdi schon geschrieben hat.

 

[hdi]

Es geht mir mehr um Präventivmaßnahmen. Stichwort Call by Value usw. Wenn man da nicht durchsteigt kann man vor allem bei Benutzung von Collections (er nimmt zB per remove() eine Karte aus dem Deck) schnell fehler machen. Klar, solange er darauf achtet dass er tatsächlich die Referenzen im Blick hat geht alles gut. Aber man sollte nicht denken dass zwei Karten gleich sind nur weil sie die selben Werte haben. Das sieht das Speichermodell halt nicht so wie man es intuitiv als Mensch sieht.