Logo "blaue" Seiten

 
 
 
 
- Anzeige -
Für den Erwerb von Schachartikeln empfiehlt Ihnen der SC Leinzell den
 Schachversand Dreier 
 
 
Testen Sie Ihr Schach!
 
Diagramm 19-2006
 
Diagramm 19 – 2006
Die schwarzen Figuren stehen äußerst aktiv. Nun gilt es loszuschlagen. Haben Sie eine Idee, wie Schwarz seinen Gegner zur Aufgabe zwang?
 zur Lösung 
 
 
 
 
zur Startseite
 News | Sitekalender | Sitemap | Team | Kontakt 
Rochade-EuropaPeter Schreiner
 
 
Shredder 5.0 - das Weltmeister-Programm!
besprochen von Peter Schreiner - Dezember 2000 - Teil 2
 
 
Das Multi-Engine-System
Die wohl gravierendste Änderung von Shredder 5.0 gegenüber dem Vorgänger war die Konzeption des Multi-Engine-Systems. Wie bereits die Beispiele Fritz und ChessGenius gezeigt haben, erfreuen sich vor allem Programme, die eine Schnittstelle zu Schachengines bieten, größter Beliebtheit bei den Anwendern. Im Vorfeld stand als erster Schritt die Entwicklung eines neuen Standards zur Einbindung von externen Engines. Die dafür erforderlichen Spezifikationen und vor allem die nicht triviale Realisierung des Konzeptes haben Stefan Meyer-Kahlen sicher einiges Kopfzerbrechen verursacht.
 
Zuerst musste ein Protokoll entwickelt werden, das anderen Autoren einen hohen Anreiz bietet, eine entsprechende Engine für das neue Multi-Engine-System zu entwickeln. Nach etlichen Experimenten und entsprechendem Entwicklungsaufwand entstand dann das brandneue UCI-Protokoll. UCI ist ein Kürzel für die schlüssigere Bezeichnung Universal Chess Interface, dem neuen Interface für die Anbindung von Engines unter Shredder 5.0. Die UCI-Schnittstelle orientiert sich eng an dem Protokoll des Winboards, im Grunde genommen kann man es als gestraffte, deutlich verbesserte Version ansehen, das einige Vorzüge gegenüber dem WB-Protokoll bietet:
  1. Ein Autor, der bereits eine Winboard-Engine entwickelt hat, kann mit relativ geringem Zeit- und Arbeitsaufwand seine Engine für das UCI-Protokoll anpassen. Davon profitiert natürlich der Programmierer, der die Weiterentwicklung seiner Engine unter einer weitaus professionelleren Entwicklungsumgebung als unter dem funktionsreduzierten Winboard austesten kann.
  2. Die Akzeptanz einer UCI-Engine dürfte weitaus höher als bei einer Winboard-Engine sein. Zum einen werden die UCI-Engines von Shredder 5.0 automatisch erkannt und es bedarf keinerlei aufwendiger Konfigurationseinstellungen, um die Engine zum laufen zu bringen. Wichtige Grundoptionen und enginespezifische Optionen müssen nicht wie bei den Winboard-Engines über externe Konfigurationsdateien eingestellt werden.
  3. Eine UCI-Engine unterstützt sämtliche Ausstattungsmerkmale und Funktionen des neuen Interfaces von Shredder 5.0.
Die UCI-Schnittstelle weist noch eine weitere Gemeinsamkeit mit dem Winboard-Protokoll auf: die Schnittstelle ist frei zugänglich und darf von jedem interessierten Autoren einer Schachengine auch zu kommerziellen Zwecken ohne Lizenzgebühr genutzt werden! Natürlich ist es klar, dass der Pragmatiker Stefan Meyer-Kahlen diese Vorarbeit nicht ganz uneigennützig geleistet hat: je mehr Engines letztendlich für das System zur Verfügung stehen, um so größer natürlich auch die Akzeptanz bei den Anwendern. Interessierte Autoren können direkt unter support@computerchess.com die Spezifikationen und weitere Unterstützung erhalten.
 
Auf der CD findet man übrigens neben der Original WM-Version der Shredder-Engine ein schönes Beispiel für eine brandneue UCI-Engine: das Programm SOS von Rudolf Huber, das bei der Mikro-WM in London den Titel des Amateurweltmeisters errang und mit relativ geringem Zeitaufwand an das neue Protokoll angepasst wurde. Nach Ansicht des vorliegenden Programms sind wir davon überzeugt, dass über kurz oder lang mit einer ganzen Reihe von Engines zu rechnen ist, die unter dem Interface von Shredder 5.0 laufen.
 
 
Winboard-Support
In der Computerschachszene erfreut sich die Freewareoberfläche Winboard von Dr. Tim Mann großer Beliebtheit. Dafür gibt es im wesentlichen zwei Gründe:
  1. Das Winboard ist Freeware und bis auf die Downloadkosten fallen für den Anwender keinerlei Kosten an.
  2. Für das System gibt es eine mittlerweile fast unüberschaubare Anzahl von Schachengines, die bis auf wenige Ausnahmen fast alle ebenfalls kostenlos sind.
Da die meisten Schachprogrammierer Amateure sind, haben viele neben dem eigentlichen Hauptberuf wenig Zeit, noch eine eigene Benutzerschnittstelle mit dem entsprechenden Funktionsumfang zu entwickeln. Es ist klar, dass man bei der Beurteilung von Freeware nicht die gleichen Maßstäbe wie bei kommerziellen Produkten anlegen darf. Als Haupthürde beim Einsatz von WB-Engines erweist sich für viele Schachspieler die unnötig komplizierte Einbindung der Engines unter dem Winboard, die wohl als einer der Hauptgründe dafür anzusehen ist, dass diese Freeware bis auf eine kleine Minderheit unter den Computerschachfans kaum auf Akzeptanz beim "normalen" Schachspieler trifft.
 
Ein weiterer Grund für die relativ geringe Verbreitung der WB-Engines sehe ich auch darin, dass die Engines hinsichtlich der Spielstärke gegenüber den kommerziellen Top-Programmen wie Fritz oder eben auch Shredder deutlich abfallen. Auch wenn einige fanatisierte Anhänger der WB-Engines noch so oft mit Elozahlen aus dem Fabelbereich um sich werfen, die wohl eher Wunschdenken als der Realität entsprechen, ist dies Fakt und wurde meiner Ansicht nach bei der letzten Mikro-WM in London nachhaltig untermauert.
 
Auf den vorderen Rängen fanden sich durchweg kommerzielle Top-Programme, während z.B. das Programm Crafty von Robert Hyatt, das als eine der stärksten WB-Engines gilt, deutlich abgeschlagen auf dem zwölften Platz landete. Trotzdem empfinden sehr viele Computerschachfreunde die WB-Engines als Bereicherung ihres Hobbys und würden diese sicher gerne häufiger einsetzen, wenn für die Einbindung und Konfiguration eine anwenderfreundliche Lösung bereit stehen würde.
 
Zwischenzeitlich gibt es diverse kommerzielle Oberflächen, die über einen Adapter die Möglichkeit anbieten, WB-Engines einzubinden. Da man nicht unbedingt davon ausgehen konnte, dass alle Winboard Programmierer das UCI-Protokoll unterstützen, bietet Shredder 5.0 als Multi-Engine-System solch eine Option, die im Rahmen der Möglichkeiten des WB-Protokolls sehr anwenderfreundlich realisiert wurde. Schauen wir uns einmal an, wie die Anbindung einer Winboard-Engine unter Shredder prinzipiell funktioniert.
 
Das Einbinden einer WB-Engine ist im Vergleich zum Original sehr einfach. Sie können die WB-Engine in einem beliebigen Verzeichnis auf einer beliebigen Partition speichern und trotzdem unter Shredder einbinden. Dies bedeutet, dass die Engines übersichtlich nach eigenem Gusto auf der Platte gespeichert und verwaltet werden können. Wenn Sie unter OPTIONEN/ENGINES den Eintrag Engine installieren auswählen, können Sie in der Dialogmaske festlegen, welchen Enginetyp (UCI oder Winboard) Sie unter der Gui von Shredder 5.0 einsetzen wollen.
 
Die Pfadangabe zu der WB-Engine kann komfortabel mit der Maus erledigt werden, das mühselige Editieren der sonst üblichen Konfigurationsdateien für den Adapter entfällt damit schon einmal im Unterschied zu anderen Programmen. Wie bei den UCI-Engines wird eine WB-Engine unter der Gui von Shredder durch eine Datei mit der Endung *.ENG repräsentiert. Das Feintuning der WB-Engines, vor allem die Konfigurationseinstellungen der Engines, müssen aber nach wie vor über die entsprechenden Konfigurationsdateien vorgenommen werden.
 
Hier zeigt sich deutlich der Vorzug des UCI-Protokolls, wo der Anwender diese Einstellungen benutzerfreundlich über einheitliche Dialogboxen mit der Maus einstellen kann. Im Grossen und Ganzen laufen die spielstärksten WB-Engines wie z.B. Crafty, Nimzo oder Gandalf absolut zufriedenstellend unter der GUI von Shredder 5.0. Kleinere Ungereimtheiten sind aufgrund des "toleranten" Winboard- Protokolls nicht immer auszuschließen. Zum besseren Verständnis der Schwierigkeiten bei der Implementierung einer funktionierenden Winboard-Schnittstelle einige Ausführungen.
 
Das Winboardinterface ist zwar recht gut dokumentiert, doch war es ursprünglich nur als grafische Oberfläche für Gnuchess konzipiert, so dass viele wichtige Punkte nicht berücksichtigt sind und erheblichen Spielraum für kleinere Ungereimtheiten bieten. Ein typisches Problem ist, dass sich nicht alle Programmierer streng an die definierten Regeln halten. Laut WB-Protokoll muss z.B. die Bedenkzeit in 1/100 Sekunden geschickt werden, doch sehr häufig kommt es bei diversen WB-Engines vor, dass man 1/1000 oder gar ganze Sekunden zur Gui sendet, was zu merkwürdigen Anzeigen im Benutzerinterface führt. Führt man sich vor Augen, wie die Informationen aufgebaut sind, die zur Oberfläche geschickt werden, wird beim Ablauf der WB-Engines unter den diversen kommerziellen Oberflächen klar, dass mancher Programmierer seine Ausgaben etwas zu eigenwillig implementiert hat. Nehmen wir z.B. eine normale Hauptvariante, die so ausschaut:
5       141       54   5568   1. Nf3 Nc6 2. O-O e5 3. e4
 
Die Bedeutung der Spalteneinträge ist zwar im WB-Protokoll definiert, offensichtlich haben aber nicht alle Autoren der WB-Engines bei der Implementierung der Übermittlung der Informationen die notwendige Sorgfalt walten lassen. Es kommt also immer wieder vor, dass eine Verwechslung vorkommt und dementsprechend merkwürdige Anzeigen im Infofenster angezeigt werden. Ein weiteres Problem stellt die Anzeige der Hauptvariante dar, dort kann nämlich ein beliebiger Text stehen.
 
Wenn man nun als Autor die Hauptvariante schön formatiert und einheitlich anzeigen will, dann muss man schon in der Lage sein, fast jeden beliebigen Text auf eine sinnvolle Hauptvariante hin zu untersuchen. Es kann passieren, dass eine Engine "XY" deutsche, englische, kurze oder die lange Notation benutzt. Kommt dann noch eine Kombination dieser Möglichkeiten und die Darstellung der Zugnummern (manche Autoren implementieren wiederum keine Zugnummer!) dazu, wird klar, welche Probleme damit bei der Implementierung einer funktionierenden WB-Schnittstelle auf den Autoren zukommen. Damit aber noch nicht genug.
 
Viele Autoren fügen eigenwillig weitere Informationen über die Suche oder den aktuell berechneten Zug hinzu, da dies beim Protokoll des Winboard ohne diese Tricks nicht möglich ist. Beim Interpretieren der Hauptvarianten muss man sich also auch noch mit Sonderzeichen wie ++, !!, ?!, ..., 9.: etc. herumschlagen. Einen klar definierten Weg gibt also nicht, deshalb ist vor allem die Implementierung korrekter Anzeigen des aktuell berechneten Zuges oder gar detaillierteren Informationen über den Suchvorgang kritisch.
 
Ein weiteres Problem von WB-Engines besteht darin, das oft genug nicht eindeutig klar ist, was die aktive Engine gerade tut, ob sie z.B. wartet oder an einem Zug pondert. Es gibt leider keine Möglichkeit sicherzustellen, dass die Engine angehalten ist und damit nicht im Hintergrund wertvolle CPU-Zeit "verbrät". Auch dies ist ein typisches Beispiel, wie sich jeder Autor an seine "eigenen Regeln" hält Schwierigkeiten bereiten häufig Programme, die mit dem Befehl "exit" anstatt "quit" beendet werden. Laut WB-Protokoll sollte "exit" eigentlich nur den Analysemodus beenden. Manche WB-Programme wiederum führen einfach keine Züge mehr aus, wenn sie eine Partie aufgeben wollen. Viele schicken keine oder nur sehr unregelmäßig ihre Suchinformationen, so dass der Benutzer häufig viele Züge nacheinander ohne Hauptvariante oder Stellungsbewertung sehen muss.
 
Zum Abschluss noch ein weiteres Problem mit WB-Engines, dem Aufbau von Stellungen, dass mit WB-Engines nur mit etlichen Klimmzügen lösbar ist. Der Urvater des Winboards, GnuChess, konnte nämlich das Zugrecht nicht verändern, die Befehlsfolge, die deshalb zum Aufbau einer Stellung mit Schwarz am Zug geschickt werden muss, wollen wir unseren Lesern hier ersparen. Einige unter unseren Lesern werden sich vielleicht fragen, warum wir diese technischen Details so ausführlich beschreiben. Ganz einfach: unmittelbar nach unserem Artikel über die WB-Engine Gandalf wurden wir von vielen Lesern gefragt, warum denn jede Winboard-Engine mit eigenen, unterschiedlichen Konfigurationsdateien daherkommt und keine einheitliche Konfiguration möglich ist.
 
Die Kurzbeschreibungen möglicher Probleme mit dem WB-Protokoll sollten jetzt verständlich machen, warum dies der Fall ist und viele Autoren die Nichteinhaltung von Standards mit ihren eigenen Konfigurationsparametern umgehen. Unter Shredder 5.0 steuert ein Adapter die Anbindung der Winboard-Engines, der versucht, die bekanntesten der zuvor beschriebenen Ungereimtheiten aufzufangen. Ein weiterer Vorzug des neuen Adapters besteht darin, dass man Autoren, deren WB-Engine unter Shredder 5.0 nicht zufriedenstellend laufen will, detaillierte Lösungsvorschläge anbieten kann.
 
 
zum Seitenanfang zurück | Teil 3