Logo "blaue" Seiten

 
 
 
 
- Anzeige -
Für den Erwerb von Schachartikeln empfiehlt Ihnen der SC Leinzell den
 Schachversand Dreier 
 
 
Testen Sie Ihr Schach!
 
Diagramm 17-2006
 
Diagramm 17 – 2006
In dieser Stellung verspeiste Weiß ohne Argwohn den Bauern auf e5. Dieser war jedoch vergiftet. Was hatte Weiß übersehen?
 zur Lösung 
 
 
 
 
zur Startseite
 News | Sitekalender | Sitemap | Team | Kontakt 
zu www.chessbase.dePeter Schreiner
 
 
Multi-Engine-System Fritz 7
besprochen von Peter Schreiner - Februar 2002 - Teil 2
 
 
Die ersten Adapter
Gegen Ende 1998 gab es die ersten Adapter für kommerzielle Benutzeroberflächen. Im Computerschach bezeichnet man damit ein Programm, das ein bereits existierendes Kommunikationsprotokoll von Engine-Systemen erweitert. Die ersten Adapter für Winboard-Engines wurden von Stefan Meyer-Kahlen für das damalige MCS-System und von Mathias Feist für die Fritz-GUI entwickelt. Damit war es erstmals möglich, die speziell für das Winboard entwickelten Schachengines unter den deutlich komfortabler zu bedienenden, professionellen Guis zu betreiben. Zwischenzeitlich haben andere Hersteller nachgezogen.
 
Problem: auch diese Form der Anbindung einer Winboard-Engine ist immer noch für viele Interessenten zu kompliziert. Ein weiteres Manko: nicht jede Winboard-Engine läuft über eine Adapteranbindung ohne Probleme. Wenn man das Grundkonzept verstanden hat, wie native Engines unter kommerziellen Oberflächen wie Fritz, Shredder oder dem MCS-System funktionieren, wird die Problematik bei der Einbindung von Winboard-Programmen klarer.
 
 
Wie funktioniert das Grundkonzept?
Im Grunde genommen ist eine Engine unter Fritz oder Shredder ein "dummes" Modul, das nur auf Anforderung eine Arbeit erledigt und dann sofort wieder aufhört. Anforderungen, die für Engines identisch sind, werden grundsätzlich von der Benutzeroberfläche gesteuert. Vorteil dieser Lösung: die Basisfunktionieren müssen nur ein einziges Mal programmiert werden. Nehmen wir z.B. das Eröffnungsbuch, das von jedem Schachprogramm benutzt wird. Alle erforderlichen Funktionen und die Kommunikation werden über das Interface gesteuert. Das gleiche gilt z.B. für das "Permanent Brain", wenn also das Programm weiterrechnet, während der Gegner am Zug ist.
 
Auch hier enthält das Interface die komplette Logik, um diese wichtige Funktion zu steuern. Alle Schachprogramme verwalten eine Schachuhr, auch dies wird von dem Interface gesteuert. Die Züge einer Partie, Aufgeben, Remis anbieten, Speichern, Laden usw. - alles wird unter Guis wie Fritz, dem MCS-System oder Shredder über das Interface gesteuert und kontrolliert. Dieses Prinzip ist für das Verständnis, warum die Einbindung von Winboard-Engines unter diesen im Vergleich zum Winboard bedeutend komfortableren Top-Guis problematisch ist, sehr wichtig.
 
 
Probleme für die Adapter
Kommen wir nun zur Funktionsweise der Winboard-Engines. Die Bezeichnung Engine ist eigentlich nicht korrekt, weil sie für sich genommen vollständige, komplette Programme sind. In vielen Bereichen übernehmen die Winboard-Programme Funktionen, die unter den Multi-Engine-Systemen Fritz oder Shredder prinzipiell von der Benutzerschnittstelle gesteuert werden. Dies ist eine der Hauptursachen für die grundsätzliche Problematik beim Einbinden von Winboard-Programmen per Adapter unter ein Multi-Engine-System.
 
In der Praxis bedeutet dies, dass der Adapter in die Funktionalität der Oberfläche eingreifen muss, damit das Winboard-Programm "seinen Willen" durchsetzen kann. Unter einem echten Multi-Engine-System gilt das Prinzip: "You are on a need to know Basis, and you don't need to know." Das gestaltet die Einbindung schwierig, weil sich manche Vorgänge nur aufwendig, andere überhaupt nicht mehr rekonstruieren lassen.
 
Ein weiteres Problem für einen voll funktionsfähigen Adapter: das Interface der WB-Programme wurde nicht für den automatischen Betrieb entwickelt. Ursprünglich wurde es vor einigen Jahren als reines Userinterface für die Kommunikation zwischen Anwender und Computer entwickelt, mit den entsprechenden Ecken + Kanten und vielen historischen Fehlern. Es fehlen z.B. elementare Funktionen, die für ein Engine-System zwingend notwendig sind.
 
Man kann z.B. eine Suche nicht einfach anhalten, ohne dass ein Zug ausgeführt wird. Es ist ebenfalls sehr schwierig, den Status des Programms abzufragen. Bis vor kurzem konnte man noch nicht einmal die Rochade- und En Passant-Rechte in Stellungen setzen. Problematisch wurde es bei der Bestimmung, welche Seite nach einer Stellungseingabe am Zug sein soll. Zwischenzeitlich wurden einige der gröbsten Mängel behoben, das Interface ist aber nach wie vor weit von professionellen Standards entfernt.
 
Prinzipiell wäre es aber mit einigen Kniffen und Klimmzügen möglich, diese Probleme in den Griff zu bekommen, wenn die Winboard-Programme sich darauf beschränken würden, ausschließlich Partien zu spielen. Ein modernes Interface stellt aber ganz andere Anforderungen, die unter dem Winboard überhaupt nicht zur Verfügung stehen. So bieten z.B. moderne Guis die Option für automatische oder interaktive Analysen.
 
Gerade bei interaktiven Analysen klickt der Anwender beliebig in die Notation, um die entsprechende Brettstellung auf das Brett zu holen und mit Hilfe der Engine zu analysieren. Bei dieser praxisorientierten Funktion machen Winboard-Programme in der Regel große Probleme, während der Adapter versuchen muss, den internen Zustand des Winboard-Programms zu erraten. Wenn dies schief geht, ist auf einmal die schachliche Verbindung weg.
 
 
Was muss ein Adapter leisten?
Aufgrund der zuvor gemachten Ausführungen sollte klar geworden sein, dass ein Adapter für Winboard-Programme vor allem zwei Dinge leisten muss:
  1. Häufig muss er einen Großteil der normalerweise vom Interface gemachten Arbeit revidieren, bzw. rückgängig machen.
  2. Zudem kommt es häufig vor, dass der Adapter einfach "raten" muss, wie der aktuelle Status des Winboard-Programms aussieht.
Diese Problematik wird zudem verkompliziert, weil viele Autoren von Winboard-Programmen etwas salopp mit den Spezifikationen des Winboard-Protokolls umgehen. Häufig genug ist nicht eindeutig klar, was die aktive Engine gerade tut, z.B. ob sie wartet oder an einem Zug pondert. Es gibt keine Möglichkeit sicherzustellen, dass die Engine angehalten ist und nicht im Hintergrund wertvolle CPU-Zeit "verbrät." Auch dies ist ein typisches Beispiel, wie sich jeder Autor an seine "eigenen Regeln" hält.
 
 
Ein Beispiel mit dem Winboard-Adapter
Betrachten wir uns nun einmal anhand des kommerziell vertriebenen Winboard-Programms Gandalf 4.32, wie das Programm mit Hilfe des Winboard-Adapters unter der weit verbreiteten Fritz-Oberfläche eingebunden wird. Damit eine Winboard-Engine unter Fritz laufen kann, muss man die prinzipielle Vorgehensweise verstehen: Der von Mathias Feist entwickelte Winboard-Adapter muss entsprechend der eingesetzten Winboard-Engine umbenannt werden, im Fall von Gandalf lautet die Bezeichnung Gandalf_432f.eng.
 
Der Adapter muss im Unterverzeichnis ENGINES von ChessBase stehen. Hier muss dann wiederum ein Unterverzeichnis mit der Bezeichnung der Schachengine, hier in unserem Beispiel mit dem Namen Gandalf_432f angelegt werden. Der Teilpfad von dem Unterverzeichnis im ChessBase-Ordner sollte also wie folgt ausschauen: \ENGINES\Gandalf_432f\. In dieses Unterverzeichnis gehören nun die zum Betrieb von Gandalf entsprechenden Dateien. Die Parameter für das eigentliche Schachprogramm werden wie unter dem Winboard über die spezielle Konfigurationsdatei Gandalf.res gesteuert.
 
Damit aber noch nicht genug. Damit eine Winboard-Engine unter der ChessBase-Gui läuft, muss der Kommandoparameter der Winboard-Engine in einer Datei mit dem Suffix *.init definiert werden. Entscheidend ist in den meisten Fällen die Zeile CommandLine= ..................xxx.
 
 
Zwischenfazit
Es bleibt festzuhalten, dass mit Hilfe dieses Verfahrens die meisten Winboard-Programme mehr oder weniger gut unter Fritz laufen. Aus den zuvor gemachten Ausführungen sollte klar geworden sein, dass ein stabiler, möglichst robuster Adapter dem Winboard-Programm einen bestimmten Zustand aufzwingen muss. Nur so entfällt das leidige Rätselraten über den aktuellen Status des Programms und die Arbeit der Oberfläche muss in diesem Fall nicht mehr rückgängig gemacht werden.
 
Genau dieses Verfahren wurde bei den Multi-Engine-Systemen Fritz und Shredder angewandt. Hauptvorteil ist einfach die Robustheit des Winboard-Adapters, der dem Anwender dieser Programme eine größtmögliche Laufstabilität garantiert. Wo viel Licht ist, da gibt es natürlich auch Schatten. Der Nachteil des Verfahrens besteht vor allem darin, dass etliche Programme dem Adapter seine "Robustheit" übel nehmen und dann nicht mehr mit voller Spielstärke spielen.
 
Im Grunde genommen wird dies lediglich von einigen wenigen Spezialisten wahrgenommen, die aber in Unkenntnis der technischen Sachverhalte und der realen Probleme ihrem Unmut und Frust über die "miserablen" Adapter in erhitzten Diskussionen in den gängigen Internetforen freien Lauf lassen. Andererseits ist klar, dass dieses Verfahren immer noch viel zu umständlich ist und nicht einmal annährend als anwenderfreundlich bezeichnet werden kann.
 
 
zum Seitenanfang zurück | Teil 3