Hidden hat folgendes geschrieben:

Is es denn besser, sie als konstante drin zu haben oder sollte ich sie zur Laufzeit erzeugen?

das ist eigentlich egal. Ich würde ja alle Werte usw. in eine extra Unit packen.

weshalb machst du denn nicht aus jeder figur ein objekt, welches weiss, wie es ziehen kann?

ausserdem solltest du auch an die sonderlocken denken, wie z.b. dass ein bauer beim ersten zug, zwei felder ziehen kann, und nachträglich kann er dann auch geschlagen werden (en passant).

für den könig gilt dann auch, kurze und lange rochade, unter der prämisse, dass er noch nicht bewegt wurde, der teilnehmende turm ebenfalls nicht, keine figur im weg steht und er sich nicht dem schach entzieht oder sich ins schach setzt. ausserdem darf der könig kein bedrohtes feld dabei überqueren.

dies wäre aber ein logikburch zu deinem bisherigen code. musst selbst entscheiden, ob du so besser zurande kämmst, oder du das procedureal abbilden möchtest, wie du bereits begonnen hast.

<HTH>

Edit: Rochade konkretisiert.

Hidden hat folgendes geschrieben:

Is es denn besser, sie als konstante drin zu haben oder sollte ich sie zur Laufzeit erzeugen?

wenn sich die konstanten nicht ändern, was spricht dagegen sie im code als konstanten zu deklarieren? dann kann der compiler auch besser optimieren...

Grenzgaenger hat folgendes geschrieben:

weshalb machst du denn nicht aus jeder figur ein objekt, welches weiss, wie es ziehen kann?

Da sind wir wieder beim selben Problem: Wie prüft das Objekt denn dann sein Zielfeld, per Array oder per Formel?

[qupte]ausserdem solltest du auch an die sonderlocken denken, wie z.b. dass ein bauer beim ersten zug, zwei felder ziehen kann, und nachträglich kann er dann auch geschlagen werden (en passant).

für den könig gilt dann auch, kurze und lange rochade, unter der prämisse, dass er noch nicht bewegt wurde, der teilnehmende turm ebenfalls nicht, keine figur im weg steht und er sich nicht dem schach entzieht oder sich ins schach setzt.[/quote]
Sonderfälle werden getrennt behandelt.

Zu deinem Edit: genau das meinte ich, danke!

Hidden hat folgendes geschrieben:

Grenzgaenger hat folgendes geschrieben: weshalb machst du denn nicht aus jeder figur ein objekt, welches weiss, wie es ziehen kann? Da sind wir wieder beim selben Problem: Wie prüft das Objekt denn dann sein Zielfeld, per Array oder per Formel?

hier würde ich ein objekt erstellen, TBrett, bei dem sich jede Figur registriert und bei verlassen sein feld als frei kennzeichnet. da sich je nach feld, unterschiedliche zugmöglichkeiten ergeben, auch im bezug auf die belegten felder, gäbe es für jedes tFigur objekt eine methode GetMoveableFields, welches ein Array oder eine Liste der Feldkoordinaten zurückliefert, auf welches gezogen werden kann. Diese Analyse würde ich algorithmisch implementieren. ausserdem weiss ja jede figur (type tSpringer = class (tFigure)) wie es ziehen kann.

neben der klasse tBrett, gäbe es auch noch eine klasse TList, in welcher alle Figuren aufgeführt wären. So bräuchtest du nicht jedes mal das tBrett durchgehen und alle felder abzufragen um die figuren aufzufordern zu ziehen, seine felder zu ziehen oder zu bewerten. hierfür kannst abstracte methoden in tFigure implementieren, welche für alle abgeleiteten figuren gelten.

<HTH>

BTW: der objektorientierte ansatz ist zwar langsamer, denke zum schluss aber auch übersichtlicher in der implementierung.

Grenzgaenger hat folgendes geschrieben:

Hidden hat folgendes geschrieben: Grenzgaenger hat folgendes geschrieben: weshalb machst du denn nicht aus jeder figur ein objekt, welches weiss, wie es ziehen kann? Da sind wir wieder beim selben Problem: Wie prüft das Objekt denn dann sein Zielfeld, per Array oder per Formel? hier würde ich ein objekt erstellen, TBrett, bei dem sich jede Figur registriert und bei verlassen sein feld als frei kennzeichnet.

Ist alles bereits so implementiert, nur einen Grund für den Umstieg auf Objekte sehe ich ehrlichgesagt nicht.


Erfüllt z.B. die Funktion deines Schachbrett-Objektes wunderbar.

Edit: Sollte ich dieses const Array dann global oder lokal deklarieren, wie setzt der Compiler das um? Deklariere ich es z.B. am anfang einer Methode, könnte es ja sein, dass es jedes Mal neu erzeugt wird. Mir geht es dabei explizit um Laufzeit zu ungunsten von Speicher, die KI soll ja schnell sein!

Edit:

Xion hat folgendes geschrieben:

Hidden hat folgendes geschrieben: Is es denn besser, sie als konstante drin zu haben oder sollte ich sie zur Laufzeit erzeugen? das ist eigentlich egal. Ich würde ja alle Werte usw. in eine extra Unit packen.

Also den Kopf der Unit mit den Deklarationen oder wie?

mfG,

Hi,

Mir ist heute klargeworden, wie kompliziert man/ich eigentlich schachspielt: Wir haben ein Array "RelevantFigures", das wir für unsere Züge durchgehen und, das wir nach bestimmten Mustern, bzw., wenn der Gegner mit der Figur zieht, aktualisieren. Grundsätzlich setzt sich dieses Array aus den Figuren in unserem Blickfeld zusammen, aber das wäre für einen Computer ziemlich kompliziert...

mfG,

Hidden hat folgendes geschrieben:

Ist alles bereits so implementiert, nur einen Grund für den Umstieg auf Objekte sehe ich ehrlichgesagt nicht. markieren Delphi-Quelltext     1: TFeldArray = array[0..7, 0..7] of FigurIndex; Erfüllt z.B. die Funktion deines Schachbrett-Objektes wunderbar.

naja der grund ist ganz einfach. dir fällt ziemlich viel verwaltungsaufwand weg. wenn du schön in OOP ein paar klassen bildest und diese dann noch sauber ableitest muss man sich nach dem implementieren der klassen um fast gar nichts mehr kümmern. deine objekte wüssten selber wohin sie dürfen und wo nicht. sie könnten sich selbständig vom spielfeld entfernen, etc...

gruß

Hi,

Der erste Unterschied deines Konzeptes wäre, dass sich ein Array[Bauer..Koenig, 0..7, 0..7] in ein Array [0..7, 0..7] verwandeln würde, das für jede Figur anders ist. Der restliche Part deiner(gegenüber
) wäre bei allen Figuren gleich: Prüfen, ob eigene Figur auf dem Feld, Prüfen, ob das Array an den Koordinaten den Wert true hat, auf Abzugsschach prüfen.

Beim, dann folgenden, seperaten Teil für die Sonderfälle werden zwei if-Abfragen gespaart: Prüfen auf König und Prüfen auf Bauern(die zwei Sonderfälle). Die Sonderfallbehandlung ist dann ja auch relativ kurz(13 Zeilen beim Bauern, 2 beim König), ansonsten wäre das ein klarer Übersichtsvorteil.

Die Geschwindigkeitsfrage kann ich nicht beurteilen, aber da du gesagt hast, dass das langsamer wäre, nehme ich mal an, dass diese zwei if-Abfragen da nicht den entscheidenden Trend geben werden. Wie gesagt kommt es bei allen Operationen, die die KI zum Vorrechnen benötigt, in erster Linie auf Schnelligkeit an.

mfG,