Author: Robert Hyatt
Date: 08:24:30 12/03/03
Go up one level in this thread
On December 03, 2003 at 10:04:25, martin fierz wrote: >On December 03, 2003 at 09:45:16, Robert Hyatt wrote: > >>On December 03, 2003 at 07:48:21, martin fierz wrote: >> >>>On December 03, 2003 at 05:08:14, Matt Thomas wrote: >>> >>>>I want to create a chess engine and am starting with the input/output routines. >>>>I can handle output, but am not sure about how to implement input. I am >>>>thinking to use ReadFile() to be unbuffered, and for pipes. I could implement a >>>>loop to poll for input, but wouldn't that be a drag on CPU cycles? I want to be >>>>able to use pondering, but if the user decided to cancel the game I need to >>>>listen for the command. I am going to use the Winboard protocol and understand >>>>the commands. I am using VC6 to create a console app and am familiar with >>>>creating a basic program in Windows/console/DOS. Any help would be much >>>>appreciated. Examples would go a long way. I have looked at some code for >>>>other chess programs, but there is so much to sift thru and I want to focus >>>>specifically on understanding the basics of implementing std input. Thanks, >>>>Matt >>> >>>haven't you got this the wrong way round? write engine, then worry about input >>>once it makes it's first legal moves. at least that's what i did :-) >>> >>>cheers >>> martin >> >> >>Actually this is not a bad idea to start here. How are you going to handle >>console input and pondering? That probably should be answered first, because >>it will affect the design of everything below it. IE two threads? one for >>input, one for searching/pondering? One thread with sporadic polling? One >>thread using an alarm() to trigger a poll? Two processes, talking through a >>pipe? Etc... > >you can do all of this later. of course you can start out with this stuff, but i >wouldn't do it that way. what if you never finish your engine? My point was that how you check for input influences how you design your basic engine. IE if it has to poll, you have to include code to do that and the resulting spaghetti stuff to allow moves to be entered while a search is in progress, without re-starting the search, etc... If you decide to use a separate thread, then you have to decide how to handle the engine thread. Ken Thompson simply started a search thread, and if the expected move was made, he waiting for the result. If the wrong move was made (not predicted) he just killed the search thread and started a new one. All of that influences how things will work. You don't necessarily have to write all the code first, but you really ought to have an overall design of how the system will operate, before _anything_ gets written. It is easier to design and then write, than to write, then design, then re-write and debug again. >of course, if you decide today that you are going to make a chess engine and are >100% certain you will see it through, then you can start out with that kind of >stuff. If you just start writing an engine, you are guaranteed to have to re-do some of it multiple times. you can start writing whatever part you want, engine included, but you ought to have some idea of how you plan to handle pondering, before you start, so that you don't start down a path that won't work without lots of (later) modifications and debugging. > >my engine has a single thread with sporadic polling and no pondering. i will >worry about those things once i believe that it's worth doing so. which is when >my engine is playing chess rather than chinese checkers on a chess board :-) >as long as that doesn't happen i'm not going to waste any time with such >details... > >cheers > martin You don't have to write the code, as I said, but you ought to know how you are going to write it, before you start on anything, from a software engineering perspective. That is a major design decision.
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.