General question about chess engines.

[MattieShoes]

char[8][8] will work. If you're going for super-strongest-fastest, then you have to worry about what is *best*. And it won't be in java! But if you want something that plays reasonable and don't care about the strength, just about any representation will work.

I think char[64], char[128] (0x88), and char[120] (10x12) are actually simpler to code in the long run though. But if you've got it working and it works for you, by all means, stick with it

[Fguy64]

Sure strength matters, but like you say it doesn't have to be the best. I rather doubt I'll be competing with Crafty.

Anyways, it's the journey and not the destination. If I can learn something interesting along the way, it's worth trying.

[hgm]

OK, so you want to program your own engine now, not interface to an existing engine.

I would still highly recommend that you separate the AI part of your program (the 'engine') from the graphical user interface part (GUI), and let the two communicate through a standrd protocol. Integrated designs usually die a quick death, as they cannot automatically play against other engines, which makes it almost impossble to evaluate your changes for improving them.

At the very least, you should set it up such that everything having to do with the engine is concentrated in just a few subroutines (e.g. one for thinking up a move in the current positon, one for performing a given move, one to set up an arbitrary position, one to set time limits), and that these routines are completey fre of any reference to the outsde world (perhaps with the exeption of some print statements to a log file for debugging purposes). Then you can always fuce those routines to a simple WnBoard or UCI driver, to have your engine play automatically against others and evaluate it. Even if your am is to develop a stand-alone integrated GUI+engine; you can always plug the engine routines back into your orginal development.

[Fguy64]

hgm, I like your idea of separating the GUI from the engine, I haven't done that as well as I might, and it gives me a place to start. Also I will need to look at the standard protocols for linking the two.

Mostly I am interested in doing my own work. To learn. But it seems to me that part of what object oriented programming is all about is to learn how to interface what you have done with what others have done. So there is benefit to using the engines of others, as well as your own.

[MattieShoes]

The winboard and UCI protocols are really the only two going at present. The winboard protocol has been around forever, UCI is more recent. Both are text-only.

In either case, the engine communicates via stdin and stdout and must respond properly to a set of commands I think interfaces generally run the engine as a separate process and pipe the engine processes stdin and stdout appropriately.

Winboard protocol
UCI Protocol

[Fguy64]

The winboard and UCI protocols are really the only two going at present. The winboard protocol has been around forever, UCI is more recent. Both are text-only.

In either case, the engine communicates via stdin and stdout and must respond properly to a set of commands I think interfaces generally run the engine as a separate process and pipe the engine processes stdin and stdout appropriately.

Winboard protocol
UCI Protocol

Hmm... I was just looking over the UCI protocol I found on shredderchess.com, there's quite a bit of stuff that can get passed back and forth. The obvious question that comes to mind is how much of the protocol I would have to implement with my GUI in order to communicate with Shredder. I suppose it's not enough just to have a command that says to Shredder "here's a fen string, send me back the best move in 1 minute"

[MattieShoes]

It wouldn't be one command, but that should be possible... I dont know the UCI protocol but if i wanted to do that in winboard, I'd do something like this

force (so it doesn't try to make moves)
setboard fen_string (to set the position)
level 0 999 999 (to give it obscene amounts of time)
st 60 (to set the max time per move to 60 seconds)
go (to make it play the side to move)

That's fine for some sort of ad-hock analysis, but not a good way to do it inside the context of a game though. Engines take advantage of the fact that the game is continuous, and using setboard might clear the hash, etc.

[Fguy64]

Well that's encouraging. It kind of lets me know that even if a full implementation is a desireable goal, I don't have to go the full nine yards in order to have a little fun.

[Edmund]

The winboard and UCI protocols are really the only two going at present. The winboard protocol has been around forever, UCI is more recent. Both are text-only.

In either case, the engine communicates via stdin and stdout and must respond properly to a set of commands I think interfaces generally run the engine as a separate process and pipe the engine processes stdin and stdout appropriately.

Winboard protocol
UCI Protocol

Hmm... I was just looking over the UCI protocol I found on shredderchess.com, there's quite a bit of stuff that can get passed back and forth. The obvious question that comes to mind is how much of the protocol I would have to implement with my GUI in order to communicate with Shredder. I suppose it's not enough just to have a command that says to Shredder "here's a fen string, send me back the best move in 1 minute"

Some basic UCI communication for your example

GUI->Engine: uci ... tells the engine that it should be in uci mode
Engine->GUI: id name xy
id author yz ... identify oneself
uciok ... done with telling the GUI the available options

GUI->Engine: isready
Engine->GUI: readyok

GUI->Engine: ucinewgame ... just ignore this command

GUI->Engine: position startpos moves <moves>
GUI->Engine: go movetime 60000

(GUI->Engine) stop ... interrupts the search

Engine->GUI: bestmove <move>

[Fguy64]

Thanks Edmund. I like minimalist examples that just deal with what you are focusing on. That's something that Sun does very poorly with their Java Tutorial.

I suppose if I want to implement a simplifed UCI (or Winboard) protocol with just my own Java engine and GUI, will it be enough that they can ( if they can) communicate via stdin/stdout, or does the engine (if Windows based) have to be an exe file as the UCI document from shredderchess.com suggests.

http://www.shredderchess.com/download.html