Author: Michael Yee
Date: 12:06:40 03/15/05
Go up one level in this thread
On March 15, 2005 at 01:53:25, Lance Perkins wrote: >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. > >--- Okay, I agree that the core requirements/scenarios should be articulated as part of the spec. I don't think we can totally get around having displayable items as part of the protocol, though, since they could be an essential part of some scenario (e.g., human user wants to get description of static eval in "words"). 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.