Three ideas for the next Winboard...
Posted: 22 Mar 2005, 00:30
Hi folks,
here's three things I'm missing from the current Winboard, and how I think they could be implemented... let me know what you think!
1) GUI improvements (move list, full engine PV's, game stats, etc.)
2) GUI for engine options (a la UCI);
3) learning tools for human players (e.g. coaching, training, etc.)
Ok, let's see implementations now.
1) GUI improvements.
My idea is: let's give anyone the possibility to improve the GUI by registering a "boardlet". In practice, a boardlet would be a DLL that has its own window and is automatically loaded and managed by the main program. This design opens many interesting scenarios: displaying the move list, full PV's, graphical game statistics, game broadcasting and so on... they could be each managed by a dedicated boardlet. As boardlets are separated from the main program, they can be written with any language from Visual Basic, to Delphi, to C++, thus bypassing the limits of Winboard itself.
2) GUI for engine options
This shouldn't require a new protocol version. Rather, an engine declares support for this feature using the standard "feature" command and then the GUI proceeds accordingly. The idea is: make the protocol similar or identical to UCI (to help engine authors) and then update PolyGlot... suddenly, there will be many engines to play with until the others catch up.
3) I'm too bad to play against a computer, but I've had great fun playing against my old copy of Fritz 6 in one of its training modes. My favorite is when the engine blunders on purpose and creates mini-combinations for you to discover. I miss this feature a lot, and would really like to see it in Winboard (or another GUI). No particular ideas on this... feedback would be very welcome!
Uhmmm... comments?
here's three things I'm missing from the current Winboard, and how I think they could be implemented... let me know what you think!
1) GUI improvements (move list, full engine PV's, game stats, etc.)
2) GUI for engine options (a la UCI);
3) learning tools for human players (e.g. coaching, training, etc.)
Ok, let's see implementations now.
1) GUI improvements.
My idea is: let's give anyone the possibility to improve the GUI by registering a "boardlet". In practice, a boardlet would be a DLL that has its own window and is automatically loaded and managed by the main program. This design opens many interesting scenarios: displaying the move list, full PV's, graphical game statistics, game broadcasting and so on... they could be each managed by a dedicated boardlet. As boardlets are separated from the main program, they can be written with any language from Visual Basic, to Delphi, to C++, thus bypassing the limits of Winboard itself.
2) GUI for engine options
This shouldn't require a new protocol version. Rather, an engine declares support for this feature using the standard "feature" command and then the GUI proceeds accordingly. The idea is: make the protocol similar or identical to UCI (to help engine authors) and then update PolyGlot... suddenly, there will be many engines to play with until the others catch up.
3) I'm too bad to play against a computer, but I've had great fun playing against my old copy of Fritz 6 in one of its training modes. My favorite is when the engine blunders on purpose and creates mini-combinations for you to discover. I miss this feature a lot, and would really like to see it in Winboard (or another GUI). No particular ideas on this... feedback would be very welcome!
Uhmmm... comments?