ChessBits is a German Computer Chess Magazine by ELVIS Pordzik and Marcus Kästner. For me (FQ) the most interesting German computer chess magazine with interesting articels about new computer chess software, chess databases, live videos on CD from chess tournaments, interviews with programmers and much more excellent facts and reviews, the NUMBER 1 ChessBits

INTERVIEWS RUND UM WINBOARD
mit Prof. Dr. Robert Hyatt, Tim Mann und Martin Blume
von Frank Quisinsky für ChessBits 18

"In ChessBits 18 finden sich auch Hinweise zu Ikarus und IsiChess sowie ferner ein größerer Bericht über WinBoard und Amateurschach. Bei der Präsentation auf den Arena Webseiten möchten wir "lediglich" die Interviews aus ChessBits 18 frei veröffentlichen".

Im Folgenden nun die drei kleinen Interviews, die ich mit den genannten Herren geführt habe. Hauptthema bilden die Engine-Protokolle "WinBoard" und "UCI". Auch habe ich mich auf Fragen, die sich mit der weiteren Entwicklung von WinBoard und Arena beschäftigen, konzentriert.

Frank Quisinsky: Als vor mehr als einem Jahr Stefan Meyer-Kahlen das zusammen mit Rudolf Huber entwickelte UCI-Protokoll im CCC Forum vorstellte, startete eine teilweise hitzige Diskussion. Für mich als Anwender stellt sich die Frage, ob neue Engine-Protokolle nicht besser von einer Gruppe aus interessierten und diesbezüglich auch erfahrenen Programmierern im Vorfeld diskutiert werden sollten. Im wesentlichen begründet durch den Umstand, dass ja auf eine rege Unerstützung gehofft wird und durch Teambildung mehr erreicht werden könnte. Mit diesen Äußerungen möchte ich natürlich nicht die Fähigkeiten von Rudolf Huber und Stefan Meyer-Kahlen in Frage stellen, allerdings halte ich es persönlich für besser, mehrere Personen zu hören, um evtl. direkt dafür zu sorgen, dass mögliche Ideen für Verbesserungen einfließen können, unabhängig von dem Umstand, daß natürlich jeder ein Engine-Protokoll entwickeln kann. Wie beurteilst Du diesen Sachverhalt?

Prof. Dr. Robert Hyatt (Crafty): Ich mag UCI einfach nicht. Es fasst ALLE Engine-Kontrollparameter zusammen. Es sagt der Engine, wann sie pondern (Permanent Brain) soll, wann suchen, wann stoppen usw. Das ist gegen mein Design, und ich habe kein Interesse daran, Crafty zu hacken, um etwas zu unterstützen, das sich so stark vom WinBoard-Protokoll unterscheidet, welches für eine lange Zeit da gewesen ist und welches perfekt funktioniert.

Frank Quisinsky: Bist Du überhaupt der Meinung, daß verschiedene Engine-Protokolle für den Anwender von Schachsoftware hilfreich sind, oder sollte vielmehr versucht werden, ein bestehendes Protokoll (WinBoard) zu unterstützen bzw. unter Umständen zu verbessern oder weiter auszubauen?

Prof. Dr. Robert Hyatt (Crafty): Das ist mein Plan. WinBoard funktioniert und ich habe bereits die Unterstützung für die Protokoll-Version 2 in Crafty eingebaut. Ich sehe keinen Grund, jetzt ein anderes Protokoll zu unterstützen, wenn das gegenwärtige perfekt funktioniert. Der Autoplayer (Auto232) ist ein gutes Beispiel. Es ist ein Stück Abfall.

Frank Quisinsky: Aufgrund Deiner damaligen Äußerungen im CCC-Forum mußt Du das UCI-Protokoll sehr genau geprüft haben. Wo liegen Deines Erachtens Schwachpunkte im direkten Vergleich zum WinBoard Protokoll?

Prof. Dr. Robert Hyatt (Crafty): Beachte dazu meine vorherige Antwort. Es entfernt mehrere kritische Entscheidungsmöglichkeiten der Engine, die am besten von der Engine und nicht von der GUI gemacht werden sollen.

Frank Quisinsky: Für mich als Anwender bietet das UCI-Protokoll interessante Optionen: Die Engine ist in der Lage, ein Eröffnungsbuch, welches über die GUI angesteuert wird, zu nutzen. Die Anbindung zu einer GUI wurde gerade für den Anwender einfacher gestaltet. Engine Optionen können in einem Dialogfeld in der GUI selbst eingestellt werden, mithin sind Konfigurationsdateien nicht notwendig. Auch sind die Engine-Ausgaben umfangreicher als im direkten Vergleich zu WinBoard. Der Anwender kann mehr Ausgabeinformationen entnehmen wie z.B. die Auslastung von Hashtabellen. Sollte demnach UCI nicht - so gut es geht - von allen Seiten unterstützt werden? Wird es zukünftig vielleicht nicht doch einen UCI-Crafty geben?

Prof. Dr. Robert Hyatt (Crafty): Es wird nie einen UCI-Crafty geben, denn ich mag das Protokoll nicht. Ein gemeinsames Buch ist (für mich) keine lohnende Idee. Warum dann nicht auch eine "gemeinsame Suche" oder eine "gemeinsame Bewertung" oder sonst irgendwas?

Frank Quisinsky: Du genießt aufgrund Deiner nimmermüden Hilfestellungen in Schachforen unter den Amateuren einen besonderen Ruf. Ich denke, daß Du indirekt und natürlich auch direkt viele Amateurprogrammierer animiert hast, nicht zuletzt aufgrund Deiner sehr gelobten und übersichtlich auskommentierten Quellcodes. Ferner ist Dein Programm Crafty nach meiner Meinung nun schon viele Jahre die Nummer eins unter den frei zur Verfügung stehenden Schachprogrammen (wenngleich Programme wie z.B. Yace und viele andere nicht nur immer spielstärker werden, sondern gar zu Crafty aufgeschlossen haben). Andere Amateurprogrammierer messen sich nur zu gerne mit Crafty und freuen sich über jeden erbeuteten Punkt. Hättest Du jemals vermutet, daß einmal ca. 130 Programme, die das WinBoard Protokoll unterstützen, zur freien Verfügung stehen würden? Besteht nicht die Gefahr, daß freier Quellcode als Programmteile Einzug in die verschiedensten Entwicklungen finden?

Prof. Dr. Robert Hyatt (Crafty): Ich habe immer gehofft, daß wir eine große Zahl an freien Engines sehen werden. Die aktuelle Anzahl ist ein wenig erstaunlich, aber es ist eine gute Sache. Das Verteilen des Quellcodes hat natürlich seine Risiken. Ich bin mir sicher, daß es ein paar wenige Programme gibt, die hauptsächlich auf Crafty basieren. Wir haben das in der Vergangenheit mehrmals gesehen, von Bionic über Voyager zu La Petite usw. Ich zweifle, daß die Aufzählung vollständig ist. Dennoch: Ohne Ideen zu teilen, ist der Fortschritt langsam. Auch die kommerziellen Programmierer nehmen die Ideen der Amateure, weil viele dieser Ideen gut sind. Natürlich geben sie im Gegenzug wenig zurück, aber das ist dann eher eine Feststellung über ihre Integrität als darüber, wie Open-Source funktioniert.

Frank Quisinsky: Immer mehr interessante Entwicklungen zum Thema Computerschach, speziell zum Thema Amateurschach, finden sich im WWW. Ich möchte jetzt nicht von einer Übersättigung an Informationsvielfalt sprechen, aber kein Anwender kann sich mit mehr als 10 Programmen intensiver beschäftigen. Glaubst Du, daß aufgrund dieser Tatsache der kommerzielle Bereich langfristig gesehen völlig aufgelöst wird?

Prof. Dr. Robert Hyatt (Crafty): Möglich. Aber das wäre nicht schlimm. Es wird immer Platz haben für eine kommerzielle GUI mit Features, die frei verfügbare GUIs nicht haben. Aber kommerzielle Engines bringen Computerschach nicht weiter, weil sie so geheimnistuerisch sind, was sie machen. Die Amateure auf der anderen Seite veröffentlichen und diskutieren ihre Ideen die ganze Zeit.

Frank Quisinsky: Persönlich interessiert mich Deine Meinung zum Thema Schachserver. Schachserver erfreuen sich seit vielen Jahren einer immer größeren Beliebtheit. Verflacht das Schachspiel nicht als solches, wenn immer mehr Personen diesen durchaus denkbaren "Suchtgefahren" ausgesetzt werden und die Realität zum Spiel durch diese virtuelle Welt verlieren könnten? WinBoard unterstützte als erste Multi-Engine-GUI seit vielen Jahren die verschiedensten Schachserver. Hältst Du den Bereich "Schachserver" für wirklich wichtig bzw. siehst Du hier im wesentlichen den Erfolg von WinBoard begründet? Sind die immer größeren Zahlen an Anwendern, die das Internet als Basis für den Informationsaustausch nutzen, für den Boom im Amateurschachbereich verantwortlich, oder glaubst Du eher, daß WinBoard der Auslöser für den heutigen Stand der Entwicklungen im Amateurschachbereich ist?

Prof. Dr. Robert Hyatt (Crafty): Ich kann das nicht beantworten. Im Allgemeinen macht das Spielen auf einem Server genauso viel Spaß wie das Spielen in Person. Und es bietet großartige Möglichkeiten, mehr Partien zu spielen wann immer man will, statt auf ein wöchentlichen Clubtreffen zu warten oder auf ein monatliches Turnier.

Frank Quisinsky: Wo liegt das Geheimnis von Programmen, die schier unglaublich gute Ratings erreichen? Welche Programmiertechniken könnten für so hohe Spielstärken im Wesentlichen verantwortlich sein? Gibt es überhaupt Grenzen, unabhängig von Hardwareleistungen, Eröffnungsbüchern und Endspieldatenbanken, um Programme in den bisherigen Schritten bzw. auf höchster Ebene weiter zu entwickeln? Welche der letzten Programmiertechniken ist aus Deiner Sicht als "atemberaubend" zu werten?

Prof. Dr. Robert Hyatt (Crafty): Da gibt es wirklich nur wenige Geheimnisse. Die kommerziellen Programmierer benutzen eine Art von Forward-Pruning die sie nicht erläutern wollen. Abgesehen davon sind die Techniken gut bekannt. Bewertung, Sucherweiterungen, Datenstrukturen, Suchtricks wie Nullmove, EGTB und solche Dinge. Die Hardware spielt wegen der Geschwindigkeit eine kritische Rolle. Und natürlich geben SMP-Programme durch die Nutzung mehrerer Prozessoren noch mehr Geschwindigkeit her.

Frank Quisinsky: Wird es in naher Zukunft eine WinBoard-Protokollversion 3 geben? Welche Änderungen bzw. Ergänzungen sind für eine evtl. vorgesehene neue Protokollversion geplant?

Tim Mann (WinBoard): Nein, nicht in naher Zukunft, vielleicht später. Meine neue Arbeit und meine anderen Aktivitäten beschäftigen mich zu sehr, als dass ich für die Weiterentwicklung von xBoard und WinBoard derzeit Zeit hätte. Recht viele Protokoll-Änderungen sind für Version 3 vorgeschlagen worden, aber ich denke, daß es keine gute Idee wäre, eine neue Protokoll-Spezifikation ohne Implementation herauszugeben. Die Zahl der Änderungen, die schließlich in das Protokoll eingehen, wird also davon abhängen, wie viel implementiert wird. Oder umgekehrt wird vielleicht der Zeitaufwand, um es herauszubringen, von der Anzahl der Änderungen abhängen!

Es gibt eine Liste mit vorgeschlagenen Änderungen für die Protokollversion 3 in den Archiven der Schachprogrammierer-Mailingliste der Yahoo-Groups.

Siehe: http://groups.yahoo.com/group/chess-engines/message/306 für die ursprüngliche Liste und spätere Nachrichten der darauf folgenden Diskussion.

Frank Quisinsky: Wird es neben evtl. neuen Protokollversionen auch Ergänzungen in Deiner unter Amateurprogrammierern sehr beliebten Benutzeroberfläche geben?

Tim Mann (WinBoard): Ich plane momentan nicht, weitere Optionen als die Protokoll-Erweiterungen hinzuzufügen. Ich habe einige Funktionen, die mir andere Leute geschickt haben, für die ich aber (zu meiner Schande) noch keine Zeit gefunden habe, sie auszuprobieren. Wenn sich herausstellt, daß sie gut designed und implementiert sind, werde ich sie in einer zukünftigen Version einbauen.

Frank Quisinsky: Tim, mal ganz ehrlich: Hättest Du bei der Entwicklung von WinBoard jemals vermutet, daß Du eine solche Welle der Begeisterung auslöst? Neben dem ICS Support begeistert sich die Masse an Anwendern für Engine-Engine-Vergleiche. Hättest Du jemals vermutet, dass über 130 Engines frei und kompatibel zu WinBoard zur Verfügung stehen?

Tim Mann (WinBoard): Nein, niemals. Als ich damit begann, hätte ich nicht gedacht, daß so viele Leute an einem ziemlich abstrusen Gebiet wie der Schachprogrammierung interessiert sein könnten.

Frank Quisinsky: Wirst Du auch weiterhin versuchen, eigene Ideen bzw. Ideen von Amateurprogrammieren in WinBoard zu implementieren oder möchtest Du das Projekt auf längere Sicht aus privaten oder zeitlichen Gründen eher abschließen?

Tim Mann (WinBoard): Ich möchte das Projekt sehr gerne aufgeben und mich anderen Interessen zuwenden. Nach 10 Jahren habe ich nun eher genug davon. Gibt es vielleicht irgendwelche Leser, die daran interessiert sind, das zu übernehmen?

Frank Quisinsky: Neben WinBoard gibt es bekanntlich ein weiteres freies Engine-Protokoll. Meines Erachtens lässt das UCI-Protokoll dem Engine-Programmierer zu wenig Freiräume bzw. Möglichkeiten, eigene Ideen einzubringen. Dennoch hat UCI Vorteile, wie z.B. ein Multivariantenmodus, mehr Ausgabeinformationen (z.B. Belegung der Hashtabellen), und auch die Anbindung einer Engine ist für viele Anwender einfacher im direkten Vergleich zu WinBoard kompatiblen Engines (WinBoard.ini und Konfigurationsdateien der Engines selbst). Interessant wäre die Frage, ob durch ein neues WinBoard-Protokoll solche Erweiterungen möglich werden?

Tim Mann (WinBoard): Man kann ein Protokoll nicht einfacher machen, indem man Dinge hinzufügt, also ist die relative Einfachheit von UCI nicht übertragbar auf WinBoard, ohne daß man inkompatible Änderungen macht. Aber Änderungen zu machen, welche die 130 existierenden Engines übergehen wäre eine dumme Idee. Gewiss, dort wo UCI zusätzliche Möglichkeiten bietet, könnte man dies in Zukunft dem WinBoard Protokoll hinzufügen. Ehrlich gesagt, verstehe ich die Anforderungen für einen Multi-Varianten-Modus nicht, somit wird wahrscheinlich jemand anderes die Entwicklung des Protokolls übernehmen müssen, bevor dies passiert. Die WinBoard.ini hat nichts mit dem Protokoll zu tun - es ist lediglich eine spezifische Möglichkeit von WinBoard. Ich vermute, daß mehr der unsauberen Konfigurationen der Engines, welche jetzt in WinBoard.ini durchgeführt werden müssen, ins Protokoll übernommen werden könnten. Das Hinzufügen neuer Engines zur WinBoard.ini ist genau deshalb kompliziert, weil ich nie gedacht hätte, dass das Schreiben von Engines so beliebt werden würde! Also habe ich mich nicht darum gekümmert, einen einfachen Weg anzubieten Engines zu installieren.

Frank Quisinsky: Viele Anwender wünschen sich, dass WinBoard-Engines Eröffnungsbücher über WinBoard selbst ansteuern können. Dies würde bedeuten, daß ein eigenes Buchformat und ein Bucheditor entwickelt werden müssen. Sicherlich eine sehr zeitaufwendige Sache. Ist eine solche Option in einer zukünftigen WinBoard-Version vorgesehen?

Tim Mann (WinBoard): Ich werde sicher nicht ein Buch-Format oder einen Buch-Editor entwickeln. Dennoch, eine der vorgeschlagenen Eigenschaften für die Protokoll-Version 3 ist eine "Buch-Engine": Das ist ein Plug-in, das im Grunde das gleiche Interface wie eine Engine benutzt, mit der Ausnahme, daß es nur die Eröffnung spielt. WinBoard würde automatisch zu einer anderen Engine wechseln, um den Rest der Partie zu spielen, wenn die Buch-Engine meldet, sie habe das Buch verlassen. Damit könnte jeder eine Buch-Engine schreiben - tatsächlich wäre es leicht, eine Engine mit eigenem Buch so zu modifizieren, daß sie eine Buch-Engine wäre. So könnte man Buch-Engines mixen und Engines spielen lassen wie es einem gefällt. Ein paar wenige Schachprogrammierer haben Interesse daran bekundet, Buch-Engines zu schreiben, als dieser Vorschlag gemacht worden ist. Was aufhält, ist, daß ich noch keine Zeit gefunden habe, überhaupt damit zu beginnen, es in WinBoard zu implementieren.

Frank Quisinsky: Derzeit sorgen drei Engine-Protokolle für Verwirrung: WinBoard und UCI als frei verfügbare Protokolle sowie das hauseigene Engine-Protokoll von Chessbase (die Spezifikation zu diesem Protokoll stehen bekanntlich nicht frei zur Verfügung).
Denkst Du, daß drei Engine-Konzepte wirklich notwendig sind oder würdest Du es als GUI Entwickler lieber sehen, wenn es hier einen einheitlichen Standard geben würde?

Martin Blume (Arena): Natürlich letzteres, aber wirklich schlimm ist das auch nicht. Wir haben ja z.B. auch verschiedene Formate für Textverarbeitungen.

Frank Quisinsky: Selbst nach mehr als einem Jahr UCI unterstützen nur verhältnismäßig wenige Programmierer dieses Protokoll. Interessant ist der Umstand, dass selbst der neue Hiarcs 8 nicht kompatibel zu UCI ist. Es stellt sich daher die Frage warum UCI noch nicht den Durchbruch geschafft hat! Worauf führst Du das bedingt fehlende Interesse zurück?

Martin Blume (Arena): Für die Entwicklung eines guten Schachmotors ist es notwendig, Partien automatisch gegen andere Motoren (Engines) zu spielen. Das ging bislang mit UCI nicht, es sei denn man kaufte sich Shredder. Viele Programmierer werden es aber nicht wollen, ein kommerzielles Produkt zu kaufen, wenn sie selber ihre Entwicklungen frei zur Verfügung stellen. Aber die Basis ist mit Arena (frei) und Chessbase (stark verbreitet) ja jetzt erheblich verbreitert worden, sodass viele Leute keine zusätzlichen Investitionen tätigen müssen.

Frank Quisinsky: Ist es für Dich einfacher, UCI oder WinBoard in Arena zu implementieren? Siehst Du Probleme mit GUI-Optionen, wenn beide Protokolle unterstützt werden und diverse Optionen unter Umständen nicht von beiden Protokollversionen angesteuert werden können? Wenn ja: Wo genau liegen die Probleme? In diesem Zusammenhang wäre es interessant, zu erfahren wieviel Zeit Du ca. - prozentual gesehen - bislang für Protokoll-Anbindungen und Anpassungen in Arena investiert hast.

Martin Blume (Arena): Also WinBoard ist im Ganzen schon komplizierter. Allerdings wird ja bei UCI das Pondern (Permanent Brain) von der GUI gesteuert, was auch nicht ganz einfach in der Programmierung war. Prinzipiell liegen die Probleme nur in Randbereichen. Die Levels etwa sind in WinBoard relativ schlecht gelöst, z.B. 1 Stunde für 40 Züge, Rest in 30 Minuten ist nicht möglich. Auch einige spezifische Informationen, die UCI-Engines ausgeben können, sind bei WinBoard nicht vorhanden, Hashtable-Belegung oder Tablebase-Statistik etwa. Meiner Meinung nach ließen sich die Probleme aber relativ einfach durch eine Erweiterung des WinBoard-Protokolls aus der Welt schaffen. Ich weiß es nicht genau, aber vielleicht haben mich die Protokoll-Anbindungen 25% der Arbeit an Arena gekostet.

Frank Quisinsky: Der wesentliche Nachteil des UCI-Protokolls im direkten Vergleich zu WinBoard ist, daß der Engine zuviel Steuerungen genommen werden. Würdest Du es begrüßen, wenn Programmierer mehr Spielraum beim Implementieren von eigenen Ideen unter UCI hätten (in verschiedenen Schachforen gab es hinsichtlich UCI einige Kommentare und Verbesserungsvorschläge. Als jüngstes Beispiel führe ich einen Link aus dem WinBoard Forum auf http://f11.parsimony.net/forum16635/messages/25871.htm ?

Martin Blume (Arena): Ja, sehr. Also, eine Engine sollte schon selbsttätig aufgeben können. Diese Funktion kann ja in der Engine deaktiviert werden, wenn mit Rechentiefe unendlich gerechnet, also analysiert wird. Auch Remis anbieten, annehmen und ablehnen sollte möglich sein. Auch müsste es wohl wirklich möglich sein, der Engine das Resultat einer Partie mitzuteilen, und zwar BEVOR eine neue beginnt. Nur damit kann eine effektive Lernfunktion realisiert werden. Ansonsten haben Programmierer wirklich viele Möglichkeiten, Suchinformationen auszugeben etc.

Frank Quisinsky: Interessant an UCI ist der Multivariantenmodus, die vielen Anzeigen von Suchinformationen und die Möglichkeit, ein "Einheitsbuch" über die GUI selbst anzusteuern. Für Anwender erscheint die Anbindung von UCI einfacher, weil hier Engine-Optionen in einem Dialogfeld zu konfigurieren sind und nicht über Einträge in einer speziellen Konfigurationsdatei. Die Anbindung von WinBoard- und UCI-Engines wurde unter Arena vorzüglich gelöst und gefällt mir gerade hinsichtlich WinBoard wesentlich besser als bei allen anderen zur Verfügung stehenden kommerziellen oder freien Benutzeroberflächen, die WinBoard-Support leisten. Es ist beachtlich, daß Du meines Erachtens gerade in diesem Bereich Maßstäbe setzt. Denkst Du, daß die beschriebenen Vorteile von UCI ausreichend sind um mehr oder weniger von einem neuen "Standard" zu sprechen? Hoffst Du evtl. auf Erweiterungen im UCI Protokoll? Welche Vorschläge würdest Du den Programmieren von UCI unterbreiten um Verbesserungen zu erzielen?

Martin Blume (Arena): Ja, wie ich gerade schon sagte, UCI muß unbedingt um die genannten Punkte erweitert werden. Dies geht im Übrigen auch ohne das Grundkonzept von UCI zu brechen, nämlich ein zustandsloses Protokoll zu sein. Ja, ich hoffe auf Erweiterungen im UCI Protokoll, ich werde dazu mal Stefan Meyer-Kahlen ein paar Vorschläge unterbreiten.

Frank Quisinsky: Herr Meyer-Kahlen meint, daß WinBoard zukünftig keine wesentliche Rolle mehr spielen werde. Diese Aussage wurde von vielen Amateurprogrammieren eher skeptisch aufgenommen, denn nach einem Jahr UCI gibt es außer Shredder und SOS keine UCI-Engine die "nur" bzw. alleine kompatibel zu UCI ist. Vielmehr sind alle verfügbaren UCI Engines auch kompatibel zu WinBoard. Aus E-Mails, die wir gewechselt haben, weiß ich, daß Du den Löwenanteil Deiner Arbeit hinsichtlich Engine Protokolle zukünftig auf UCI ausrichten möchtest und dennoch hast Du eine 1:1 native Anbindung nach Tim Mann, ohne Verwendung eines Adapters, umgesetzt. Denkst Du, daß UCI schlechthin das Protokoll der nächsten Jahren werden wird oder zweifelst Du nach dem Stand der Engine-Entwicklungen eher an der Aussage von Stefan?

Martin Blume (Arena): Also ich habe da keine so eindeutige Meinung dazu. Es ist auch recht einfach, WinBoard "aufzubohren" und allerlei schöne Features dort einzubauen. Das hat ja schließlich mit der Einführung von WinBoard-Protokoll Level 2 auch schon gut funktioniert. Ich denke da nicht ideologisch, sondern praktisch. Ich glaube eher, daß es eine (hoffentlich) friedliche Koexistenz geben wird. Beide Protokolle sollten zum Nutzen der User und der Programmierer an unterschiedlichen Stellen verbessert werden. Ich werde da sicher zu gegebener Zeit praktische Vorschläge unterbreiten.

Frank Quisinsky: Durch Arena haben Engine-Entwickler die Möglichkeit, UCI auszuprobieren, denn nicht jeder möchte finanzielle Mittel aufbringen, um letztendlich einen Test durchzuführen, um etwas frei zur Verfügung zu stellen. Zumal testen die Mehrzahl der Amateurprogrammierer Ihre Programme verstärkt unter WinBoard, nicht nur aufgrund von sehr gutem ICS-Support. Die bisherige Resonanz zum Thema Arena ist sehr positiv. Indirekt unterstützt Dein Projekt die UCI-Entwicklung. Eine Frage, die sich viele Anwender stellen: Warum wird Arena von Dir frei zur Verfügung gestellt bzw. wird Arena auch zukünftig frei angeboten?

Martin Blume (Arena): Ich möchte, wie gesagt, nicht nur UCI unterstützen, sondern beide Protokolle verbessern. Ich halte es bei der Entwicklung von Schachprogrammen für wichtig, ein gutes Analyse-Instrument zu haben. Es spart jede Menge Zeit für einen Programmierer, wenn er oder sie mal eben schnell eine Stellung aufbauen kann oder eine Stellung oder Partie aus dem Internet in seine Oberfläche laden kann, um zu sehen, wie seine Engine die Stellung bewertet. Auch die Benutzer sind häufig für die Schachprogrammentwicklung von großem Wert. Auch sie brauchen eine schöne und einfach zu bedienende Oberfläche. Sie liefern Bug-Reports, entdecken versteckte Fehler, liefern Anregungen etc. Persönlich macht mir das Programmieren Spaß und warum sollte ich dies nicht mit einem anderem schönen Hobby (Schach) verbinden?

Frank Quisinsky: Du hast Dir kürzlich das wenig verbreitete MCS-Protokoll angesehen und bist zu dem Entschluss gekommen, daß der Aufwand, auch dieses Protokoll über Arena anzusteuern, zu zeitaufwendig ist bzw. der Nutzen zu gering ist. Mit anderen Worten: Hast Du ein Interesse, Arena zu allen möglichen Protokollen kompatibel zu gestalten? Würdest Du versuchen, das Chessbase-Protokoll in Deine GUI zu implementieren, sofern es frei zur Verfügung stehen würde?

Martin Blume (Arena): Das wäre natürlich möglich, wenn der Aufwand nicht allzu groß ist. Andererseits, warum? Chessbase hat auch eine schöne Oberfläche.

Frank Quisinsky: Abschließend würde mich interessieren, welche Engine Dich am meisten fasziniert bzw. mit welcher Engine Du Dich am meisten beschäftigst (unabhängig von Deiner eigenen Engine, welche zur Zeit nicht zur Verfügung steht)? Spielst Du z.B. selbst Engine-Engine-Matches oder analysierst Du mehr mit Schachprogrammen? Welchen Computerschachteilbereichen schenkst Du am meisten Zeit?

Martin Blume (Arena): Am meisten fasziniert mich wohl Little Goliath. Ich habe wirklich keine Ahnung, wieso dieses Ding so rasend schnell ist. Das Programm benutze ich für taktische Analysen. Aber auch Crafty verwende ich gerne, da es sehr sauber läuft und sehr gut balanciert ist. Darüberhinaus gefällt mir die positionelle Solidität von SOS sehr gut. AnMon mag ich wegen der manchmal sehr originellen Spielweise - häufig stark, aber leider nicht immer.

Hervorheben möchte ich die Bemühungen von "Wilhelm"-Programmierer Rafael B. Andrist, der die Interviews mit Prof. Dr. Robert Hyatt und Tim Mann übersetzte.

Wilhelm von Rafael B. Andrist

start of page

INTERVIEWS about engine protocols
with Prof. Dr. Robert Hyatt, Tim Mann and Martin Blume
by Frank Quisinsky for ChessBits 18

"In ChessBits issue 18 can be found also information about Ikarus engine and GUI and IsiChess engine and GUI. Furthermore, a bigger review about WinBoard and amateur chess. On Arena webpage we added only the interviews with many important information for the group of interesting engine users.

Not a 1:1 translation of little new German text, but my English ... my English :-)

Frank Quisinsky: More than a year ago, as Stefan Meyer-Kahlen and Rudolf Huber presented the UCI protocol in the CCC forum, a partly temperamental discussion started. For me as a user, there's the question if it wouldn't be better to let interested and experienced programmers discuss new engine protocols in the forefield - mainly justified by the circumstances, that one could hope for a bigger support and that a team can achieve better results. I do not intend to question the abilities of Rudolf Huber and Stefan Meyer-Kahlen, but personally I think it's better to include more persons to take care directly that possible ideas for improvement can be included - independent from the fact, that everyone can develop its own engine protocol. What do you think about this?

Prof. Dr. Robert Hyatt (Crafty): I simply don't like UCI. It subsumes _all_ engine control parameters. It tells the engine when to ponder, when to search, when to stop, etc. That is contrary to my design and I have no interest in hacking Crafty to support something that is so different from the Winboard protocol that has been around for a _long_ time and which works _perfectly_. My intent is to continue to use the winboard protocol exclusively and not try to support other protocols that offer no increased functionality and which actually hurt some of the design features in the current Crafty chess engine.

Frank Quisinsky: Do you think that it is helpful for the user if there are several engine protocols, or should we try to support one existing protocol (WinBoard) and to develop it further?

Prof. Dr. Robert Hyatt (Crafty): That is my plan. Winboard works. I already have support for protocol version 2 in Crafty. I see no reason to support yet another protocol when the present one works perfectly. Auto232 is a good example. It is a piece of trash.

Frank Quisinsky: Based on your comments in the CCC forum, you must have studied the UCI protocol very accurately. Where are in your opinion possible weak points compared to the WinBoard protocol?

Prof. Dr. Robert Hyatt (Crafty): See above. It removes several critical engine-decisions that are best made by the engine, not the GUI.

Frank Quisinsky: For me as a user, the UCI protocol offers interesting options: the engine has the possibility to use a GUI-controlled opening book. The integration in a GUI is much easier for the user, engine options can be changed in a dialog box, individual configuration files aren't necessary. The engine output contains more info too, e.g. the usage of hash tables. So, shouldn't all - as far as possible - support the UCI protocol? Will there be an UCI Crafty in the future?

Prof. Dr. Robert Hyatt (Crafty): There will never be a UCI crafty. I don't like the protocol. A common book is (to me) not a worthwhile idea. Otherwise, why not a "common search" or a "common evaluation" or something else?

Frank Quisinsky: Because of your never ending help in chess fora, you have very good fame under the amateurs. I think that you have animated much amateur programmers to start with a chess program, also because of your very good commented source code. Furthermore, your program is IMO the number one of the freely available chess programs (though other programs like Yace also have achieved this level). Other amateur programmers often compare the strength of their programs with Crafty and enjoy each point the gain. Did you ever suspect that there would be 130 freely available programs which support the WinBoard protocol? Isn't there the danger that free source codes are implemented in various other engine developments?

Prof. Dr. Robert Hyatt (Crafty): I always _hoped_ we would see a large number of free engines. The current number is somewhat surprising, but it is a good thing. Distributing source has its risks. I am certain that there are a few current programs that are mainly based on Crafty. We have seen several in the past, from Bionic, to Voyager, to Le Petite, etc. I doubt that will end the list. However, without sharing ideas, progress goes slow. Even the commercial programmers take ideas from the amateurs, because lots of the ideas are good. Of course, they give little back in return, but then that is a statement about their integrity rather than about how open source works.

Frank Quisinsky: More the more, interesting developments in computer chess, especially in amateur chess, can be found in the WWW. I don't like to call this over-saturation, but no user can intensively use and know more than 10 programs. Do you think that, based on this fact, the commercials will die out - from a long-term point of view?

Prof. Dr. Robert Hyatt (Crafty): Possibly. But this won't be a _bad_ thing. There will always be a place for a commercial GUI with features not available in public GUI programs. But commercial engines are not furthering computer chess whatsoever, because they are so secretive about what they do. The amateurs, on the other hand, publish and discuss their ideas all the time.

Frank Quisinsky: Personally, I'm interested in your opion concerning the topic of chess servers. They enjoy a big popularity since many years. Won't the chess game level out, if more the more persons are exposured to this really existing danger of obsession and may lose the reality of the game by these virtual realities? Since many years, WinBoard supports as the first multi-engine GUI various chess servers. Do you think that the section "chess servers" is really important respectively do you think that this is the cause for the success of WinBoard? Is the still increasing number of users, who use the Internet for information exchange, responsible for the boom in the section of amateur chess, or do you think that rather WinBoard was the stimulus for today's situation?

Prof. Dr. Robert Hyatt (Crafty): Can't answer that. Playing on a server is just as much fun as playing in person, in general. And it offers far greater opportunities to play more games whenever you want, rather than having to wait for a weekly club meeting or a monthly club tournament.

Frank Quisinsky: Which is the secret of programs to achieve the unbelievable high ratings? Which programming techniques can be responsible for such a high level of playing strength? Are there any limits - independent of hardware power, opening books and endgame databases - to further develop programs at highest level and with the same tempo as in the past? Which of the last programming techniques is in your opinion breathtaking?

Prof. Dr. Robert Hyatt (Crafty): There are really few secrets. The commercial programs are using some form of forward pruning that they won't discuss. Other than that, things are pretty well-known. Evaluation. Search extensions. Data structures. Search tricks like null-move, EGTBs and the like. Hardware is playing a critical role due to speed. And, of course, SMP programs are providing even more speed using multiple CPUs.

Frank Quisinsky: Will there be a WinBoard protocol version 3 in the near future? Which changes and additions are planned for a probably new protocol version?

Tim Mann (WinBoard): No, not in the near future, but perhaps later. My new job and my other activities have kept me too busy to spend time on xboard and WinBoard. Quite a few protocol changes have been proposed for version 3, but I don't think it would be a good idea to release a new protocol specification without an implementation, so the number of changes that actually get into the protocol may depend on how much gets implemented. Or perhaps the amount of time it takes to come out will depend on the number of changes!

There is a list of proposed features for protocol version 3 in the archives for the chess engine authors' mailing list on Yahoo Groups.
See http://groups.yahoo.com/group/chess-engines/message/306 for the initial list, and later messages for the discussion that followed.

Frank Quisinsky: Are you planning additions in your own, by the amateurs much liked user interface, beside probably new protocol versions?

Tim Mann (WinBoard): I'm not currently planning to add any features other than protocol additions. I do have some contributed features that other people have sent me, which (to my embarrassment) I haven't found time to try out yet. If they turn out to be well designed and implemented, I'll include them in a future release.

Frank Quisinsky: Tim, honestly: Did you ever suspect that your development of WinBoard causes so much enthusiasm? Apart the ICS support, the mass of the users are enjoying engine-engine matches. Did you ever suspect that there would be 130 free and WinBoard-compatible engines?

Tim Mann (WinBoard): No, never. I had no idea so many people would be interested in the relatively esoteric field of chess programming when I started out.

Frank Quisinsky: Will you try to implement your own ideas and the ones of amateur programmers in WinBoard also in the future or do you prefer to finish this project because of private circumstances or of the time it consumes?

Tim Mann (WinBoard): I'd very much like to give up the project and move on to other interests. After 10 years I've gotten rather tired of it. Are any readers interested in taking over?

Frank Quisinsky: As you now, beside WinBoard, there's also another free engine protocol. In my opinion, the UCI protocol lets too less free space and room for own ideas to the programmer. But UCI has also advantages, e.g. a multi-variant mode, more status information (e.g. usage of Hash tables) and the handling of the engine is - compared to WinBoard (WinBoard.ini and the configuration files itself) - simpler for the user. The interesting question is, if such additions and improvements would be possible in a new WinBoard protocol.

Tim Mann (WinBoard): One can't simplify a protocol by adding to it, so the relative simplicity of UCI is not attainable in WinBoard without making incompatible changes. But making changes that leave behind the 130 existing engines would be a foolish idea. Certainly where UCI has additional capabilities, something similar could be added to the WinBoard protocol in the future. Frankly, I don't understand the requirements for multi-variant mode, so someone else will probably have to take over development of the protocol before that can happen. WinBoard.ini has nothing to do with the protocol -- it's just a specific feature of WinBoard. I suppose that more of the messy configuration of engines that now has to be done in WinBoard.ini could be moved into the protocol. Adding engines to WinBoard.ini is complicated exactly because I never expected writing engines to become so popular! So I didn't get around to designing a nice way to install new engines.

Frank Quisinsky: Many users wish that the opening books would be controlled directly by WinBoard. This means that an own book format and a book editor would have to be developed. This is surely a very time consuming option. Is such an option intended in future WinBoard versions?

Tim Mann (WinBoard): I will certainly not be developing a book format or book editor. However, one of the proposed features for protocol version 3 is a "book engine". This is a plug-in program using basically the same interface that engines use now, except that it only plays the opening. WinBoard would automatically switch to another engine to play the rest of the game when the book engine reports that it is out of book. With this feature, anyone could write a book engine -- in fact, it would be easy to modify any existing engine that has its own book to be a book engine -- so you could mix and match book engines and playing engines as you please. A few engine authors expressed interest in doing book engines at the time this proposal was made. What's holding it up is that I haven't found time to even begin implementing it in WinBoard.

Please use the Google Translator
At the moment I haven`t a good English translation!

Many thanks for the efforts by Wilhelm programmer Rafael B. Andrist.
Rafael translated for 3 months my questions of the interviews with Prof. Dr. Robert Hyatt and Tim Mann.

Wilhelm by Rafael B. Andrist