Das deutsche Python-Forum

Hi.
Ich will jetzt mal ein Skat Spiel programmieren.
Das Problem das ich aber im Moment habe ist, wie ich das ganze am besten aufbaue.
Das fängt schon damit an, wie ich am besten die Karten repräsentiere.
Eine Karte braucht natürlich den Wert (König, Ass, ...) und ihre Farbe (Kreuz, Karo, ..).
Ich hatte mal ein ziemlich simples Kartenspiel programmiert, in dem jede Farbe einen festen Rang hatte. Ich hab einfach ein self.ranks definiert und schon hatte ich quasi die Regeln implementiert.
Aber bei Skat ist das ganze ein wenig komplexer, da sich der Rang der Karten je nach Wahl der Trumpffarbe ändert und auch je nach Wahl des Spiels, das gewählt wird (Null, Grand, Ramsch, ..).
Ich hab mir überlegt, hier ebenfalls ein self.ranks zu benutzen und dann für die vier verschiedenen Spielmodi (oder wie viele es auch sein mögen) einfach jeweils eine eigene Rangfolge zu schreiben. Das kommt mir aber alles irgendwie ein wenig umständlich vor und führt dann später auch zu relativ umständlichen Aufrufen (denke ich).
Hat jemand eine bessere Idee, wie man das realisieren könnte?

das würde ich eher nicht den karten überlassen.
implementier doch eine klasse "tisch" die weiss welches spiel gerade gespielt wird. die akzeptiert 3 karten (etwa tisch.vorhand_legt(karte), ... ) und gibt zurück wer den stoss geownnen hat.

was ist das ziel? willst du eine KI einbauen? über netz spielen?

Hi Nocta,

sehr interessante Aufgabe. Und ich würde sagen sehr schwierig, Da Skat ein Strategiespiel ist.
Diese Strategien zu implementieren sind sehr aufwendig. Ich denke da nur an eine potenzielle Funktion reizen().
Oder bist Du gerade Alleinspieler, oder spielst Du zu zweit. Spielst Du Farbe, Grand oder Null.

Dann brauchst Du auch noch ein Abrechnungssystem.

Also, wenn Du es gut machen willst schätze ich mal mehrere 10000 Zeilen Code.

In diesem Sinne sage ich schon mal 18.

/Hendrik

Das Ziel ist erst einmal ein funktionsfähiges Skat Spiel zu erstellen
Wenn das mal fertig ist, kann ich ja über eine GUI, Netzwerk und eine KI nachdenken. Aber erstmal muss natürlich das Spiel funktionieren.

Eine Tisch-Klasse? Hm, hört sich vernünftig an.
Kannst du vielleicht noch (grob) ausführen, wie du das Spiel in Bezug auf OOP designen würdest? Da hab ich im Moment mein Problem. So komplex ist das Spiel ja auch wieder nicht, aber ich steh da momentan auf der Leitung.
Ich frag mich immer, was dieses oder jenes Objekt können muss, aber ich kann mich nie wirklich einigen. Mir fehlt eben ein wenig die praktische Erfahrung beim Projekte planen.

Edit:
@hendrikS: Meinst du wirklich, dass es so kompliziert ist?
Mir ist klar, dass es einigen Aufwandes bedarf, dem Computer die grundlegenden Regeln zu vermitteln, aber als so schwer habe ich das ganze Projekt gar nicht eingeschätzt.
Das Reizen sollte eigentlich auch gut zu bewältigen sein, man kann sich die Werte doch alle errechnen. Das Abrechnungsystem ist ebenso nur ein wenig Mathematik und meiner Meinung nach auch kein großes Problem.
Also alles in allem zu bewältigen, aber vielleicht ändere ich meine Meinung auch, wenn ich damit angefangen habe Kann sein, dass ich mich hier total verschätze, weil mir wie gesagt auch die praktische Erfahrung in solchen Dingen (Projekten etc) fehlt und ich sonst nur kleinere Algorithmen schreibe, die einzeln für sich stehen.

zum schwierigkeitsgrad:

das kommt drauf an was dein ziel ist.
ein skat-spiel das nicht nur die entwickler spielen wollen ist ist mit deienm jetztigen wissenstand nicht umzusetzen.
wenn der weg das ziel ist, ist es zwar umfangreich, fordert durchhaltevermögen, scheint mir aber ganz interessant zu sein, da sich das problem schön in viele teilprobleme aufteilen lässt, von denen einige recht einfach umzusetzen sind.

zum design. mir erschliesst sich jetzt nicht wirklich, was es bringen soll, wenn ich das jetzt mache. das ist doch der kern der sache, also dein job.

ein anfang wäre zum beispiel mal - in deutsch - aufzuschreiben, was überhaupt passiert beim skatspiel, zb:

1. es wird festgelegt wer zuerst die karten ausgibt (=Hinterhand)
2. HH gibt karten nach schema: ...
3. es wird gereizt, dh. ...
4. wer das reizen gewonnen hat drückt und sagt das spiel an: das können sein: ...
5. VH legtz eine karte auf den tisch, MH bedient, HH bedient
6. der sieger ist nun VH, goto 5.
7. sind alle karten gelegt wird abgerechnet
8. wer bei 5. VH war ist jetzt HH. goto 2.

das machst du etwas genauer. jetzt schaust du mal was du da für substantive und verben benutzt hast, das sind deine kandidaten für klassen und methoden. schaue die dir dann mal genauer an (finde zb die eigenschaften der klassen).
in welcher relation stehen sie zueinander? es gibt da natürlich unendlich viele möglichkeite. das problem ist, dass sich nicht auf anhieb zeigt was zu einer klaren implementation führt.

Also das Problem ist, Du musst ja Deine Computerspieler (also gegen die willst Du ja spielen) implementieren.
Für diese mußt Du alle Strategien implementieren. Es wäre doch langweilig, wenn Deine Gegenspieler bei 18 immer gleich "weg" sagen. Oder Dir die 10 hinterherwerfen, wenn du das As ziehst.
Noch mal zum Reizen: Beide 10 Karten. Nun musst Du bewerten lassen, ob es überhaupt eine Gewinnaussicht mit einem Blatt gibt.
Welche Farbe hat die höchste Gewinnaussicht. Oder vielleicht doch besser Null. Vorhand, Mittelhand, Hinterhand sind oft von Bedeutung.
Wieviel Buben. Ohne einem, zwei,..? Mit einem, zwei,..? Etc.
Besteht die Gefahr des Überreizens, wenn plötzlich ein Bube im Skat liegt?

Und nicht vergessen: Der König zu dritt macht immer nen Ritt.

Vielleicht zeigst Du mal was im Showcase. Bin gespannt. Mitnichten einfach.

Ach so du sprichst von der KI.
Da bist du ein bisschen voreilig, ich habe (noch) nicht vor, eine KI zu implementieren. Erstmal spielt ein Mensch (an einem Computer) alle 3 Spieler. Hot Seat nennt man sowas in der Game-Fachsprache
Eine Netzwerkfunktion wird dann wahrscheinlich als erstes folgen, weil Skat an einem Computer einfach keinen Sinn macht. Aber ob ich eine KI implementiere, werde ich mir noch überlegen müssen.
Aber ich denke ohne eine KI, also ohne dass der Computer "denken" muss also nur die strikten Regeln befolgen muss, wird das ganze nicht so extrem aufwendig sein.

... ah so. Das relativiert das natürlich. Dann ist es nicht mehr so aufwendig. Aber um ehrlich zu sein, dann bevorzuge ich doch lieber richtige Karten.

Keine Ahnung was eine KI ist.

Künstliche Intelligenz (auf eng. AI). Sorry, ich dachte das wäre allgemein bekannt.
Klar sind da richtige Karten besser, aber hier gehts eben nicht um's RL sondern um Python Ich würde zum Beispiel auch gerne mal ein oder zwei Runden mit Freunden zocken, die nicht bei mir wohnen, wenn das Programm also gut wird, ließe sich das realisieren. Klar, es gibt auch schon fertige, kostenlose Programme (was wir zur Zeit auch nutzen), die einem das bieten. Aber man kann ja mal über ein eigenes Programm nachdenken. Außerdem find ich's interessant das mal zu programmieren.
Und eine KI kann ich ja immer noch einbauen, damit auch du zufrieden bist

Ich will jetzt mal ein Skat Spiel programmieren.

Gibt's schon:

http://www.xskat.de/

Da könntest Du auch die (C-)Quellen studieren.

Gruß

Dass es sowas gibt, weiß ich. Aber wenn hier jemand nen IRC-Clienten programmieren will, kommst du doch auch nicht mit: "Gibt's schon: [10.000 Links]", oder?
Und was soll ich jetzt mit 'nem in C programmiertem Spiel mit 999999999 Funktionen (die dann wohl in C und nicht in Python geschrieben sind) genau anfangen?

PS: Sorry, soll nicht so böse rüberkommen wie es tut

@Nocta: Je nach dem wie's geschrieben ist und wie gut Deine C-Kenntnisse sind, hättest Du Dir aus den Quellen vielleicht Anregungen holen können.

Naja meine C-Kenntnisse sind eher beschränkt. Verstehen würde ich das meiste wahrscheinlich aber naja ...
Klar kann man sich bei anderen Programmen (wenn sie Open Source sind) Anregungen holen, aber das Schreiben von Algorithmen (die ich da zB "abschreiben" könnte) ist ja auch nicht das Problem, um das es in dem Thread geht, sondern hauptsächlich das OOP Design. Und da C kein OOP unterstützt bringt das dann relativ wenig
Es war natürlich gut gemeint aber mir bringt es nichts.

Ich bin übrigens immer noch für Vorschläge offen. Da ich in der Zwischenzeit auch noch nicht weiter gemacht habe, stehe ich noch auf dem selben Stand wie vor einigen Stunden.

C unterstützt zwar kein OOP, aber deshalb können Programme trotzdem in einer Art OOP-Stil geschrieben sein/werden. Deswegen die Bemerkung, dass es auch darauf ankommt, wie das C-Programm geschrieben ist.

Nachdem das GNOME-Projekt C nun um einige Datenstrukturen erweitert hat (GLib), ein eigenes Typsystem draufgesetzt hat (GType) und auch ein Objektsystem in C hat (GObject) ists doch fast schon objektorientiert.

Ja, GTK+ ist schön objektorientiert. Mit allem Komfort, den eine nicht auf OOP ausgelegte Sprache dafür bietet...

Für Komfort gibts ja dann Vala.

Letztendlich hat ja CPython auch sein Objektsystem, mit PyObjects die man an Python-Code übergeben kann. Auch hier gibt es analog zu Vala Cython, das die ganze Sache etwas komfortabler macht.

man kann in C sehrwohl objektorientiert programmieren.

eine sehr interessante ausführung dazu:

http://www.state-machine.com/devzone/cp ... manual.pdf

(kapitel 3 und 4)


und, bist du inzwischen weitergekommen mit deinem design?

Leonidas hat geschrieben: Letztendlich hat ja CPython auch sein Objektsystem, mit PyObjects die man an Python-Code übergeben kann.

Klar, irgendwann muss man ja von nicht-OOP auf OOP überspringen, wenn man eine OOP-Sprache implementiert. Aber GTK ist ja eigentlich keine Sprache...

Gut, Vala scheint ja wirklich brauchbar zu sein. Und sinnvoller als ganz GTK auf C++ umzustellen, allemal.

birkenfeld hat geschrieben:Klar, irgendwann muss man ja von nicht-OOP auf OOP überspringen, wenn man eine OOP-Sprache implementiert. Aber GTK ist ja eigentlich keine Sprache...

Aber GTK+ ist eben genauso wie Python ein System in dem Objektorientierung einiges an Vorteilen bringt. Ein Windowing-System ist ja das Vorzeigeobjekt für OOP.

Und GTK+ nutzt ja auch nur die Funktionalität die inzwischen in andere Komponenten ausgelagert wurde, so dass auch andere davon profitieren können. Das ist vielleicht auch irgendwie vergleichbar mit dem Moose-Objektsystem in Perl 5.

Letztendlich hat man zwei Möglichkeiten wenn man eine nicht-OOP-Sprache hat aber OOP will: man implementiert die Sprache als eine eigene Sprache oder als Präprozessor (C++, Vala, Cython) oder man tackert OOP eben an die Sprache an, mehr order weniger gelungen (GObject in C, die >16 Objektsysteme die es für Scheme so gibt).