✔ Klassenkonzept Schachprogramm

[Snape]

Moin,
sind ja bisher nicht so viele Themen seit Eröffnung.
Gut, fange ich eben selbst an.

Hat jemand Vorschläge, wie die Klassenstruktur eines Schachprogramms aussehen sollte/kann? Sicherlich ist das Brett eine eigene Klasse, aber wie sieht es mit den Figuren aus. Sollten sie auch eine eigene Klasse darstellen? Wenn nein, warum nicht, wenn ja, warum. Welche weiteren Klassen sollte es geben? Wie ist datentechnisch eine Kapselung des Rechenmotors ("Engine") zu realisieren, vor allem in Hinblick darauf, fremde (UCI/Winboard) Engines einzubinden?

Bin gespannt, was es hier für Vorschläge gibt.

 

[squeaker]

Ich würde eine Player-Klasse konstruieren. Diese sieht das Brett und die Züge und ihr kann das Zugrecht erteilt werden - dann kann sie auch ziehen. Für einen Menschlichen Spieler ist das dann eine GUI, für eine Engine ist es einfach nur eine API zum Aufrufen, für fremde Engines ein Netzwerkinterface oä. Mittels einer einfachen Übersetzungsklasse können dann fremde Engines via Netzwerk angebunden werden. Das Netzwerkinterface bzw. der Netzwerkplayer kann dann auch dazu verwendet werden einen Spectator zu erschaffen, so dass Fremde dem Spiel zuschauen können - ihnen wird dann nie ein Zugrecht erteilt.

 

[Snape]

OK, aber was ist mit dem Brett? Eine Klasse "Board", die auch die Figuren beinhaltet? Was ist mit einer Zugliste?

 

[squeaker]

Da die Figuren keine eigentlichen Statistiken haben und auch nicht modifiziert werden (wie z.B. in einem Computer-Strategiespiel) würde ich sie gleich in das Brett integrieren. Das Brett ist also das Spiel an sich. Es liefert alle Informationen über die Stellung und es nimmt die neuen Züge an bzw. weist sie zurück.

Für nach der Partie ist es sinnvoll, die komplette Partie als Zugliste zur Verfügung zu haben und beliebig zwischen den einzelnen Knoten der Liste springen zu können. Ausserdem sollen sich Variationen also Abspaltungen machen lassen um andere Möglichkeiten in der Besprechung aufzeigen zu können. Zum Abspeichern bietet sich das SGF-Format an, welches auch z.B. für GO definiert ist.
Das Board würde ich in einer Klasse verstecken, welche die Zugliste unterhält und die eigentlichen Manipulationen am Board vornimmt, d.h. die Spieler-Züge entgegen nimmt, das Zugrecht verteilt, zwischen Besprechungs und Spielmodus unterscheidet. So ist es prinzipiell möglich andere Spiele in der selben Klasse zu verstecken z.B. GO und hat ebenfalls Zugliste, Besprechungsmodus usw.

 

[Christian Fein]

Ich würde die Figure ebenso als Klasse bereitstellen. Denn dann kann jede Figur überprüfen ob sie mit ihren zugfertigkeiten sprich 3+2 2+3 fürs Pferd den angeforderten Zug überhaupt durchführen kann.

Dann eine Klasse die FigurePositionRepository z.b heisst welche dafür verantwortlich ist nach einem Zug zu prüfen ob eine Figure geschlagen wird. Und welche von der Figur aufgerufen wird wenn sie ein zug machen muss ob jemand im weg steht.

usw.

 

[Vincentius]

Hallo,

wie wäre es damit: Es gibt eine Klasse Board und eine Klasse Figure. Die Board-Klasse bietet unter anderem Methoden addFigure() und removeFigure(). Beim starten des Spiels werden Figure-Instanzen erzeugt und dem Board-Objekt übergeben (über die addFigure Methode). Das könnte z.B. ein GameInitializer durchführen.

Die Klasse Figure stellt dabei folgende Methoden zu Verfügung:
- getPosition() - liefert die aktuelle Position der Figur auf dem Brett
- setPosition() - setzt die aktuelle Position der Figur, speichert dabei den Zug in der Zugliste
- getMoves() - liefert Liste aller Züge der Figur im Verlauf des Spiels
usw.

Das Board-Objekt kann dann alle Figuren, die es in eine Liste hält, nach ihrer Positionen abfragen, und sie entsprechend auf dem Brett platzieren.

Gruß
Vincent

 

[squeaker]

Ich würde die Figure ebenso als Klasse bereitstellen. Denn dann kann jede Figur überprüfen ob sie mit ihren zugfertigkeiten sprich 3+2 2+3 fürs Pferd den angeforderten Zug überhaupt durchführen kann.

Dann eine Klasse die FigurePositionRepository z.b heisst welche dafür verantwortlich ist nach einem Zug zu prüfen ob eine Figure geschlagen wird. Und welche von der Figur aufgerufen wird wenn sie ein zug machen muss ob jemand im weg steht.

usw.

Ich fände das übertrieben. Schach ist nicht so kompliziert, als dass man wirklich jede einzelne Figur eine eigene Klasse geben müsste. Ausserdem wie soll da die Kommunikation gestaltet werden?

Zugbefehl an Figur, die an Board, das an die geschlagene Figur?
oder Zugbefehl an Board, welches die Figur befehligt?

 

[squeaker]

Wollen wir eigentlich ein kleines Projekt draus machen?

 

[Snape]

Ich fände das übertrieben. Schach ist nicht so kompliziert, als dass man wirklich jede einzelne Figur eine eigene Klasse geben müsste. Ausserdem wie soll da die Kommunikation gestaltet werden?

Zugbefehl an Figur, die an Board, das an die geschlagene Figur?
oder Zugbefehl an Board, welches die Figur befehligt?

Figur als eigene Klasse finde ich auch etwas übertrieben. Ich fragte mich nur, ob es prinzipiell eine Klasse "Figur" geben soll oder ob man sie gleich ins Brett/Board integriert. Gefühlsmäßig würde ich eine Klasse Figur anlegen. Dem Brett würde ich die Stellungskontrolle und Verarbeitung überlassen, also Ziehen, Schlagen mit den dafür notwendigen Überprüfungen. Ob auf dem Zielfeld eine Figur steht, wenn ja, ist es eine Figur der eigenen Farbe oder des Gegners, handelt es sich um den König usw.
Meldekette sehe ich GUI (=Spieler) oder Engine an Board und das Board verarbeitet weiter.
Dahingegen bin ich noch unsicher, wo die Zugliste unterzubringen ist...

 

[Snape]

Wollen wir eigentlich ein kleines Projekt draus machen?

Hehe, ich wäre natürlich dafür. Aber: Eigenes Projekt from-a-scratch oder an einem bestehenen weiter basteln? Mit etwas Glück/Pech habe ich demnächst Zeit, wieder bei http://www.java-chess.de weiter zu machen. Das Open-Source-Projekt liegt u.a. bei Sourceforge und CVS ist dafür auch angelegt.