Zitat:
Deckst du z. B. ab, ob eine große Rochade möglich ist und auch, wenn der Turm dann Schach bietet?
also meine brettklasse merkt sich welche rochaden noch möglich sind(genauso hat sie einen enpassant-merker) aber was meinst du mit "wenn der turm schachsagt"?
Wenn du eine Rochade machst, kann es vorkommen, dass der Turm danach dem anderen König Schach bietet. Was ich damit im Grunde nur sagen möchte: Es können recht komplexe Situationen entstehen und deshalb ist eine gute Programm-Struktur so relevant, weil ab einer gewissen Komplexitätsstufe rächen sich solche schnellen Hacks. Aber wenn dein Programm gut funktioniert, dann müssen wir das ja nicht mehr ausdiskutieren.
Zitat:
Die müssen nicht auf das ganze Brett zugreifen, die müssen ihren Standort kennen und daraus ermitteln sie die für sie erreichbaren Felder
aber welche felder für sie erreichbar sind, hängt doch vom brett ab.
Ich meine damit: Der Bewegungsradius gehört zur Figur, dass ein Turm nur gerade gezogen werden kann, ist sein Wissen, ob nach seinem Zug ein konsistenter Zustand erreicht wurde, ist das Wissen des Bretts oder der Schiedsrichter-Klasse.
Jetzt kodierst du das Spezialwissen der Figuren alles in der Brett-Klasse, wenn es jetzt nicht um Schach ginge, sondern um ein anderes Szenario und du müsstest eine Figur hinzufügen, müsstest du bei deinem Vorgehen die zentrale Brettklasse ändern und im worst case das ganze Programm an vielen Stellen anpassen und ändern. In meinem Szenario würdest du einfach eine neue Figurklasse hinzufügen, die genau ihren Bereich abdeckt und müsstest an dem Programm sonst im Grunde nichts ändern.
Ja, so in etwa. Die Frage ist, wie willst du es sonst machen? Bestimmte Zugmöglichkeiten unberücksichtigt lassen?
ich lasse keine möglichen züge unberücksichtigt, aber wenn man z.b. grade im schach steht, muss ich mir nicht angucken, wie eine figur ziehen kann, die am schach sein nichts ändert, wenn der zug dann nachher sowieso aus der liste der möglichen züge wieder rausgenommen werden muss.
Ja, aber das sind ja wirklich seltene Spezialfälle. Du musst ja aber schon irgendwie für jede Figur feststellen, dass sie an dem Schach nichts ändern kann. Ich sehe noch nicht so genau, dass das viel effizienter ist.
das Dilemma aller Schachprogramme ist das exponentielle Wachstum
das ist mir klar, aber grade deshalb sollten doch methoden, die man dann eben 2^80 mal ausführt, optimal sein. denn die haben doch einen entscheidenden anteil daran, wie lange er rechnen muss.
Der Clou am exponentiellen Wachstum ist halt, dass du eine Methode eben nicht 2^80 mal ausführen kannst, es sei denn, du überredest Google dir deren Rechenkapazitäten zu geben. Nehmen wir an, du hättest einmal ein sauber in Java codiertes Programm und ein in Assembler hoch effizient gecodetes Programm. Du würdest mit dem Java Programm vielleicht 13 Züge im Voraus berechnen und mit dem Maschinencode-Programm 14 Züge. Die Anzahl der Züge wächst so stark, dass es nicht so sehr auf das letzte Quentchen Effizienz ankommt.
Quasi Depth First Search statt BFS
das sagt mir beides nichts...kannst du das kurz erläutern, was damit gemeint ist?
DFS bedeutet, dass man erst in die Tiefe sucht, bis man am Ende anlangt oder bei einem Abbruchkriterium und Breitensuche (BFS) bedeutet, dass man parallel an jeder Stelle um eins weitergeht. Wenn du BFS anwendest und alle Züge checkst, auch wenn du z. B. sofort die Dame opferst und dennoch diese Weg weiterverfolgst, dann bleiben keine Ressourcen, um die erfolgsversprechenden Varianten in viel tiefere Bereiche zu berechnen. Anderseits verbaust du dir auch kreative Lösungen, wie sie Bobby Fischer in der zitierten Partie gefunden hat. So eine Lösung würde ein Computer wahrscheinlich nicht finden.
