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.

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.

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

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.

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.

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

Zitat von 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.

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?

Wollen wir eigentlich ein kleines Projekt draus machen?

Zitat von squeaker

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...

Zitat von squeaker

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 www.java-chess.de weiter zu machen. Das Open-Source-Projekt liegt u.a. bei Sourceforge und CVS ist dafür auch angelegt.

Zitat von Snape

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.

Gefühlsmäßig würde ich auch eine Klasse für Figur anlegen - sie aber bei Schach dann verwerfen, da die Funktionalität einer Figur doch arg beschränkt ist. Bei Civilisation (dem Computerspiel) hingegen ist es klar, dass eine Klasse für die Figur existieren muß (und ausserdem eine für das Feld auf dem es steht - diese würde ich beim Schachbrett auch weglassen, da nur die Farbe sich ändert, es aber sonst keine Eigenschaften hat).

Zitat von Snape

Meldekette sehe ich GUI (=Spieler) oder Engine an Board und das Board verarbeitet weiter.
Dahingegen bin ich noch unsicher, wo die Zugliste unterzubringen ist...

Das mit der Meldekette sehe ich genauso. Allerdings würde ich die Zugliste zwischen Spieler (ake Engine oder GUI) und Board legen. Damit bekommt die Zugliste jeden Zug mit und kann das Brett manipulieren. Am Ende des Spieles wechselt die Zugliste in den Bearbeiten/Erklären Modus und erlaubt es dem Spieler der das Bearbeitungsrecht anfordert beliebig in der Partie zurück zu gehen und verschiedene Variationen aufzuzeigen bzw. von einem beliebigen Punkt die Partie wieder vortzusetzen.
Das Board überwacht sozusagen ob die Züge "valid" also korrekt sind, die Zugliste kümmert sich um Beobachter, Chat, Variationen, Beobachtungsmodus usw. (daher ist Zugliste eigentlich ein falscher Name, es sollte mehr die Organisation und Protokollierung sein).

Gefühlsmäßig würde ich auch eine Klasse für Figur anlegen - sie aber bei Schach dann verwerfen, da die Funktionalität einer Figur doch arg beschränkt ist. Bei Civilisation (dem Computerspiel) hingegen ist es klar, dass eine Klasse für die Figur existieren muß (und ausserdem eine für das Feld auf dem es steht - diese würde ich beim Schachbrett auch weglassen, da nur die Farbe sich ändert, es aber sonst keine Eigenschaften hat).

Prinzipiell gibt es aber unterschiedliche Zugmöglichkeiten der einzelnen Figuren. Wo sollen die rein?

Das mit der Meldekette sehe ich genauso. Allerdings würde ich die Zugliste zwischen Spieler (ake Engine oder GUI) und Board legen. Damit bekommt die Zugliste jeden Zug mit und kann das Brett manipulieren. Am Ende des Spieles wechselt die Zugliste in den Bearbeiten/Erklären Modus und erlaubt es dem Spieler der das Bearbeitungsrecht anfordert beliebig in der Partie zurück zu gehen und verschiedene Variationen aufzuzeigen bzw. von einem beliebigen Punkt die Partie wieder vortzusetzen.

Eine Navigation durch die Partie/Zugliste sollte m.E. jederzeit möglich sein, Stichwort u.a. Zugrücknahme bei bemerktem Fehler.

Das Board überwacht sozusagen ob die Züge "valid" also korrekt sind,

Das ist eine weitere Frage. Die Engine muss ja sowieso alle legalen Züge bestimmen, oder soll sie diese vom Brett erhalten? Andererseits, wenn die Engine die legalen Züge bestimmt, wird vermutlich dennoch das Brett nicht umherkommen, ebenfalls die legalen Züge zu bestimmen. Damit wäre gewährleistet, dass bei einer Partieeingabe ohne Engine nur legale Züge eingegeben werden können.

die Zugliste kümmert sich um Beobachter, Chat, Variationen, Beobachtungsmodus usw. (daher ist Zugliste eigentlich ein falscher Name, es sollte mehr die Organisation und Protokollierung sein).

Also eine Art GameController.
(Kommt mir irgendwie bekannt vor diese Klasse. )

Die Zugmöglichkeiten der einzelnen Figuren würde ich in diesem Fall in die Validierung der Züge stecken. Sollte recht kurz und schmerzlos sein.

Das Board hat einen Zug und einen Positionierungsmodus. Der Zugmodus ist für das Spiel und validiert die Züge. Der Positionierungsmodus ist für die Erklärungen und wird von außen gesteuert -> Gamecontroller.

Zugrücknahme jederzeit möglich ist ja nicht ausgeschlossen, sollte aber in einem Turnier nur nach Absprache mit dem anderen Spieler möglich sein und nicht per default.

Im Prinzip muss nur das Board die Regeln können, für die Engine/den Spieler wäre es von Vorteil. Aber prinzipiell kann der Spieler beliebige Züge schicken die dann vom Board überprüft werden. Ist er korrekt, so wird der Zug ausgeführt und der andere Spieler erhält das Zugrecht. Ist er nicht korrekt, so wird er nicht ausgeführt und des Spieler erhält erneut das Zugrecht.

Zitat von squeaker

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?

Es wäre aber ooptechnisch sinnvoll.

Die kommunikation erfolgt über die Board klasse.
Die Board klasse sollte nicht wissen wie die figuren laufen, denn das ist kein Bestandteil des Boards.
Jede Figur sollte aber wissen wie sie laufen darf.

Das Board sollte aber wissen ob eine Figur ungehindert da drüber laufe darf.

der Code könnte so aussehen:

Code :

1 2 3 4 5 6 7 8 9 10 11 12

class Board ...    public boolean moveFigure(Figure figure, Coordinate target) {     if( figure.couldReach(target) &&         (getFigureOn(target).isEnemyTo(figure) == false) &&         (  clearWay(figure.getPosition(),target) || figure.isJumping) ) {              figure.setPosition(target);              Figure enemy = getFigureOn(target);              if(enemy!=null)                          killFigure(enemy);     } }

In diesem Code steckt somit folgende Logik:
Kann die Figur das Ziel erreichen, ist nicht eine eigene Figure auf diesem Zielfeld,
ist der Weg zum Ziel frei oder kann meine Figur zu Ziel springen.
Wenn das gegeben ist dann setze die Figure auf die Position und schlage falls vorhanden
die Gegnerfigure vom feld.


Es gibt also eine ganze Menge was eine Figur über sich wissen könnte.

- wo bin ich
- bin ich ein Springer
- wie laufe ich
- zu welchem Spieler gehör ich
- ist der Übergebene Figure Parameter ein Feind

usw

Das alles in Board zu kapseln wäre, nicht bös sein, ein OO Fehler.

Ein Tip wie mann zu guten Klassen kommt ist die UseCases aufzuzählen und jedes Supstantiv als Object zu sehen.
Use Cases wären in einem Schachspiel:

Ein Spieler meldet sich beim Spiel an. ( Objecte Player, Game)
Die Figuren werden über das Spielfeld verteilt ( Objecte Figure, Board)
Der Spieler 1 bewegt Figure auf Koordinate A4 auf Koordinate .. ( Object Coordinate und Methode move)
Der Weg wird geprüft ob frei von Spielern oder aber die Figur drüber springen kann ( Board#checkWay und Figure#isJumpable)
usw.

Das die Figuren OO-technisch Objekte sein müssten, ist eigentlich klar. Die Frage ist ob man mit einer Kanone nach Spatzen schießt. Ich meine ja - andere nein. Das ist sicherlich Geschmackssache. Um es etwas extremer zu gestalten: OO-technisch müßten bei einem GO-Spiel auch jeder einzelne Stein eine eigene Klasse sein, allerdings macht ein Stein während des ganzen Spieles nichts ausser daliegen (er kann nicht gezogen werden) bis er geschlagen wird oder das Spiel endet. Dafür aber dann 360 Einzelinstanzen der Klasse Stein je Ausprägung (Schwarz bzw. Weiß) zu machen ist auch übertrieben.