programming engine, programming GUI

[EricLang]

Hello, I'm currently trying to decide how to write my engine and GUI.

I'm writing my own graphical interface for my chess-engine and want to know what's the best way to seperate these two.

When the engine is thinking, it starts a neverending loop, of course.
The GUI must be able to respond while the engine is searching.
Should I write a seperate thread for the search, or should I call some "ApplicationProcessMessages" procedure once in a while?

I also have to write an UCI engine to be able to link it with other GUI's.
If anyone knows good source code in Delphi for that I would be glad.

Other tips and tricks are welcome too!
I'm interested how other programmers solve this kind of stuff.

[Zlaire]

Separate thread hands down.

But why not write your GUI so it is UCI compatible as well, and just connect your engine by default. That way you can extend it to other engines if you like.

[EricLang]

"Seperate thread hands down"?
What do you mean?

I'm thinking of a GUI that can handle UCI yes.

[Zlaire]

I mean I really think you should use threads, it's by far the easiest way.

[Onno Garms]

In my opinion you should decide if you want to write a GUI or an engine. Both need considerable amount of time. Only if you write chess software as a fultime job like SMK you can write both a good engine and a good GUI.

If you try to write both in your spare time, both will stay at a mediocre level for lack of time. For an engine this might be OK if you consider writing an engine as sports like playing human chess, but the world certainly doesn't need another mediocre GUI. Do one thing and do it well!

If you still want to write both, you definitely don't want to invent a new way how to comunicate between engine and GUI. Use UCI only. You save the time to implement two protocols in your engine (you plan to implement UCI anyway) and your GUI will be accepted more widely if it supports UCI.

UCI implies that GUI and engine run in separate processes.

In the engine process, it's sufficient to do a nonblocking check for new input once a while during search. See Fruit for an example. One thread in the engine to read input and another for the search would be a more polished solution.

I have not written a chess GUI, but I think messages from the engine should raise events that are handled in the GUI.

[hgm]

From my work on WinBoard I learned that writing a GUI is enormously more work than writing an engine.

Of course I would advice against using UCI, and recommend WinBoard protocol in stead. It is far simpler, and as adapters exist both ways, you still would be able to play against any other engine that uses either WB or UCI protocol.

[ilari]

I would follow the Unix philosophy of modularity, that a tool should do one thing and do it well. Of course there's also the Windows philosophy of "combine everything into one huge mess", but I wouldn't recommend that.

One of the big advantages of writing just a chess engine, is that it can be easily ported to many platforms, and GUIs generally can't.

From my work on WinBoard I learned that writing a GUI is enormously more work than writing an engine.

Partly it's because writing GUIs is generally hard. But part of the blame must go to Winboard/Xboard. It's just very hard to expand or even maintain a cross-platform desktop application which has separate codebases for the GUI parts. And if that wasn't enough, it has to use the horrible win32 API on the Windows side, and the even more horrible X11 on the *nix side.

I tip my hat to you for being able to work with that.

[Zlaire]

Partly it's because writing GUIs is generally hard. But part of the blame must go to Winboard/Xboard. It's just very hard to expand or even maintain a cross-platform desktop application which has separate codebases for the GUI parts. And if that wasn't enough, it has to use the horrible win32 API on the Windows side, and the even more horrible X11 on the *nix side.

I tip my hat to you for being able to work with that.

Or use Java.

[Tord Romstad]

From my work on WinBoard I learned that writing a GUI is enormously more work than writing an engine.

So it is. I've been trying to make the same point in the "Iphone Chess Apps" thread in the "General Topics" sub-forum, but it seems that hardly anyone believes me.

Of course I would advice against using UCI, and recommend WinBoard protocol in stead. It is far simpler,

Here I don't agree. To me, the Winboard protocol looks much more difficult to implement. The Winboard protocol leaves too many things unspecified, like the sign of the evaluation and the format of the PVs. Even something as basic as writing a program that successfully parses the PVs of all available Winboard/XBoard chess engines seems extremely hard.

Tord

[Steve Maughan]

...If anyone knows good source code in Delphi for that I would be glad.

Hi Eric,

As far as a UCI engine the best Delphi source is Delfi which comes with source code (Google it to find the link).

As far as the GUI is concerned take a look at the Jedi Controls (JVCL). There is a component that enables you to start a DOS process and communicate via methods and events. Delphi is definitely the most productive GUI development environment (IMHO) so good luck!!

Cheers,

Steve

BTW Arena (www.playwitharena.com) is also written in Delphi but is not open source