Author: Lance Perkins
Date: 22:53:25 03/14/05
Go up one level in this thread
Yes you are correct. I am more interested in documenting the requiremens and motivations. As you can see, my definition of the 'chess agent' is incomplete, and the list of scenarios is even more incomplete. My intention in jotting them down is to get started on completing them - not just for the new scenarios but hopefully for the scenarios that are already supported by the current protocols. You will also notice that I did not even mention the GUI in my definitions. The reason for that is, that I see the GUI as just a ficility for the chess agent to interpret the protocol, because the protocol itself is not readily consumable by the chess agent. In the case of a human agent, it cannot readily visualize the board from just a series of text strings. Even a chess engine has to parse a string to interpre it (which makes the parser the equivalent of a GUI for chess engine agents). Consider the situation where we define the protocol such that the chess agent is required to send a 'java applet' as part of the protocol. This 'java applet' will display the board in a human-recognizable display. In this case, you don't need a GUI. An example of this http://chess.delorie.com/ where you get an HTML page when you play chess against it. This of course is a very simplistic approach. I forsee that the human use of a GUI will still drive many of the requirements. Again, I hope we document these. And just to be clear, I am not advocating the embedding of any UI-related items in the protocol. In fact, there should be none. The protocol must have no displayable items at all. The reason is simple: we don't want to get into localization issues. Here's one example of a bad design (from UCI): the engine sends the string "option name Style type combo default Normal var Solid var Normal var Risky". Now, how will the GUI translate this to other languages? What is 'Solid'. That could mean 'Strong', or some thing that is not 'Fluid' (because I can also add a Fluid style of play). I myself have no additional requirements or scenarios. I'm fine with the current protocols. However, I want to make sure that we nail the core scenarios and don't break them as we add new features. To me, the chess engine is a chess player - it knows the game and is interested in chess. This to me is a core requirement. The UCI protocol has broken this and has reduced the chess engine to a position solver. I guess the summary of this is that I am interested in formalizing the process so that we don't have to redo this next year. --- On March 14, 2005 at 22:24:12, Michael Yee wrote: >Thanks for this start... I've never done an analysis like this for a protocol >before, although it sounds similar to making/discovering a requirements spec, >coming up with "use cases", etc. > >For clarification, are you simply saying that we should keep an explicit record >of scenarios like these (as a kind of "motivation" in the spec)? Or are there >particular scenarios that you think are currently unsupported? > >Most of the scenarios you listed (although as you mentioned, not nec a complete >list) can be satisfied by a either WB or the proposed XCI (each with help from a >GUI). (UCI doesn't seem to allow draw by agreement.) Even Scenario 5 could be >supported since an engine could request the path to other engines and then >manage them through whatever protocol it wanted. > >Since the proposed XCI is essentially a hybrid/superset of xboard and uci (that >also aspires to be extensible and easier for the user/programmer), it seems like >it would support most imaginable scenarios. So maybe your point is that it's >*too* flexible and thus not parsimonious or clean enough? > >Thanks, >Michael
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.