Klassenkonzept Schachprogramm

Als Speicherformat würde ich wie schon gesagt SGF bevorzugen, da es offen ist. Alternativ bietet sich auch Latex an - zum ausdrucken.

Rochade ist ein nettes Beispiel. Wie wäre das korrekt ObjektOrientiert zu programmieren? Ich bin auf der feinen Seite. Mein "fauler" Ansatz schenkt mir das quasi - das Brett macht ja alles.

Ein Link zum Thema SGF:

http://www.wordiq.com/definition/Smart_Game_Format

Es scheint allerdings keine Definition für Schach zu geben. An sich ist das Format gut - aber vielleicht sollte man dann doch PGN wählen (siehe auch obiger link).

In der Definition des Formats habe ich dann doch noch Schach gefunden.
 
Zuletzt bearbeitet:
melmager hat gesagt.:
eine Methode um den Spielstand zu sichern und eine zum laden
hier würde ich sogar xml einsetzen denn dann könnte man das Schachspiel so aufbohren das man
mit anderen online (bzw via email) spielt - man tauscht einfach die xml dateien aus :)

Seit geraumer Zeit hat sich das PGN-Format als Standard durchgesetzt. Allerdings ist ein PGN Parser nicht gerade trivial zu implementieren. Deshalb wäre es möglicherweise durchaus an der Zeit, Vereinfachungen zu definieren und gleich nach XML zu gehen. Aber das ist ferne Zukunftsmusik...
 
Snape hat gesagt.:
Seit geraumer Zeit hat sich das PGN-Format als Standard durchgesetzt. Allerdings ist ein PGN Parser nicht gerade trivial zu implementieren. Deshalb wäre es möglicherweise durchaus an der Zeit, Vereinfachungen zu definieren und gleich nach XML zu gehen. Aber das ist ferne Zukunftsmusik...


Die Macht ist mit uns :)

ich würde auf xml gehen und einen konverter einbauen der auf SGF und PGN umsetzt.

denn die Formate sind nicht gerade einfach gestrickt
ich habe sie zwar nur überflogen sieht aber schwierig aus
- vermutlich brauchen die Konverter 50% des Codes :)

:) Beginn doch die Zukunftsmusik -smile-
auch bei PGN hat sich eines Tages ein Programmierer hingesetzt und hat sich ein paar Gedanken gemacht,
und die andren haben gesagt -> cool benutze ich auch
 
Was mir halt an SGF so gut gefällt ist die Unterstützung für Varianten. Ich selber spiele eher Go als Schach und da ist SGF DER Standart. Nach einer Partie kann man dann die Fehler besprechen und mit anderen Zugfolgen ab der Fehlerstelle erklären was man meint. Sehr praktisch, möchte ich nicht missen.
 
Ok, dann wäre es jetzt an der Zeit eine Definiton des Schnittstellen einer Figur abzugeben inklusive der Aufgaben die sie erfüllen können muß.
 
mein Vorschlag:
Code:
class Figur {
char farbe,type;
// A  - H wird zu 10 - 80 und 1 -8 wird addiert C4 ist dann 34
public boolean zugerlaubt(int von,int nach,boolean schlage); 
public char getfarbe();
// Typ B=Bauer T=Turm S=Springer L=Läufer K=König M=Königin 
public char gettype();
Figur (char color,char art) {
}
}

Leider fangen Ja König und Königin mit K an darum bei Königin ein M für Majestät :)
und die Umwandlung in Integerwerte für die Felder um Zugrichtungen besser bewerten zu können
von C4 ein schräger Zug für den Läufer währe ein vielfaches von +-11 und +- 9
 
Zuletzt bearbeitet:
Nachdem es bei der Figur, dem Brett nicht so auf Speed ankommt, würde ich der Klarheit wegen mit Strings arbeiten, d.h. den Bauer tatsächlich "Bauer" nennen und mit x/y Koordinaten arbeiten (0-7, 0-7).
 
Hmm dann würde ich beides machen beim Typ
string = Bauer und Char B und zwar um in der Methode zugerlaubt mit switch und case arbeiten zu können.

Und bei den Kordinaten, denke ich, kommt es drauf an, ob man das Brett mit eindimesonalen Array oder zwei Dimensonalen Array arbeiten möchte. Und im Moment hätte ich keine Idee wie man ein zweidimensonales Array mit Objekten anlegen kann :)
 
OO wäre aber: Klasse Figur->Unterklasse Bauer. Jede Unterklasse implementiert nur für den eigenen Figurtyp, ob der Zug erlaubt ist. Es gibt also für jeden Figurtyp eine eigene Klasse die von Figur erbt (hauptsächlich die Schnittstelle).
 
squeaker hat gesagt.:
Einfache Antwort: wenn es aufwändiger ist, aber keinen zustätzlichen Nutzen bringt, dann keine zustätzliche Klasse (ich weiß, diese Ansicht ist eher Ketzerisch), sonst ja. Eine zustätzliche Klasse später einfügen wenn sie benötigt wird ist nicht so schwer (wenn doch, hätte es von Anfang an eine gebraucht) und Refactoring gehört zum Geschäft.

Aufwendig? Nein eine eigene Klasse ist nicht aufwendiger, sondern gleichaufwendig.

Zusätzlichen Nutzen? Viel, modularität, erweiterbarkeit, korrektes OOP, leichter Verständliche Programmierunug

Zusätzliche Klassen einzubauen ist sogar sehr aufwendig, weil du dann das Refactoring direkt in der Logik betreiben musst. Wenn du richtig gekapselt hast, kannst du das Refactoring besser betreiben weil du einfach die Klasse austauschen kannst.

Sorry ich sehe nur nachteile :)
 
Zurück