Developing a TMCI-GUI is proceeding

[Reinhard Scharnagl]

Hello WB forum!

Well, I hope for discussing this theme to be tolerated here. Otherwise please keep me informed and I will stay away with this new approach.

As some already will have noticed I work with the idea of playing with downwards compatible extensions of traditional chess, to avoid using huge look up tables but use the engine's own intelligence instead. One basic idea is to keep the engine's size (compressed) below 1/4 MB, to force its persistent data to be shrinked, see: http://www.chessbox.de/Compu/schachfair_e.html .

Within my combination of engine and GUI I try to cover following:
a) Fischer castlings (covering 8x8 and 10x8 boards)
b) traditional 8x8 board and 10x8 Capablanca board and piece set (covering all paired combinations of the elementary gaits of Knight, Bishop and Rook within Queen and added Archbishop and Chancellor)
c) shuffling FRC and CRC (Capablanca random Chess) positions
d) usage of a compatibly extended FRC-FEN / CRC-FEN
e) support of PGN files covering those variants

http://www.chessbox.de/Compu/fullchess1_e.html
http://www.chessbox.de/Compu/schachcrc_e.html

Because there has heen no existing GUI supporting 8x8 and 10x8, and because of missing a flexible protocol supporting such chess extensions, I had been forced to develop an own protocol, based on one single DLL intercface function, calling it the TMCI (Third Millennium Chess Interface).

The GUI is just about to be completed by integrating a matching FullChess engine Smirf.

Well, there is a problem within this forum, not to support HTML (this moment), therefore HTML produced by my FullChess position generator could not be shown here.

If someone is interested in that FRC/CRC / TMCI-GUI matter, please let me know.

Regards, Reinhard.

[Michael Yee]

Hello Reinhard,

A quick question: Why did you choose to use a DLL for your protocol? I don't have any experience with windows programming (it may be the case that using DLLs for communication is easy). But my hunch is that more people would write engines compatible with your interface if the protocol was text based.

Note that the above is just my (not-so-informed) opinion. In any case, good luck with your new interface and Smirf. I'm very interested in seeing how your position evaluation ideas work out.

Michael

[Reinhard Scharnagl]

Hello Michael,

A quick question: Why did you choose to use a DLL for your protocol?

though the concept of DLLs is widely spread (probably been called another name, when not using Microsoft OS) this concept is leaving the idea to use pure C++ language elements only. But multithreading in my view today is an unavoidable feature. I do not like to simulate such a behaviour by hand, where well tested libraries give us such possibilities by providing a lot of procedures.

Using one single interface function additionaly makes it totally unnecessary to parse any commands. Thus programming engines will become much more easy. I regard the task to create a DLL not that difficult as you might think it would be.

I'm very interested in seeing how your position evaluation ideas work out.

Me too!

Regards, Reinhard.

[Reinhard Scharnagl]

Let me introduce the TMCI idea and how simple it is constructed:

Code: Select all

//================================================
// PROJECT: SmirfEngine.dll (C) R. Scharnagl
//================================================

#ifndef SmirfEngineH
#define SmirfEngineH


// --- to be defined when included in its *.cpp ---
#ifdef  SmirfDLL
#define IMP_EXP dllexport
#else
#define IMP_EXP dllimport
#endif

// --- technical optimization (Borland) ---
#ifdef __BCPLUSPLUS__
#define __c /* */
#else
#define __c __cdecl
#endif

// the TMCI engine interface function: DoCmd()

extern "C" __declspec(IMP_EXP) const char * __c DoCmd(
  char MainCmd, char SubCmd, int nrIn = 0, const char *pIn = 0L);

/*
  TMCI protocol (Third Millennium Chess Interface) [ incomplete draft ]

  The protocol is intended to keep the GUI realy silly. The GUI
  gets all its knowlegde on chess moves from the engines. This
  makes those GUIs much easier to be extended to new variants,
  and also allows an easier writing of such GUIs. 
 

  COMMANDS (please discuss planned extensions with R. Scharnagl)

  How to perform any command:

  (DoCmd args)      (DoCmd answer)

   '*' '*' ** ** => char string "<answer>" rsp. "ok" at success
                    (and stop any engine run task, if necessary)
                 => otherwise 0L, if impossible or after errors
                    (query last error reason by: DoCmd('I','R'))

  (ALREADY DONE)

  Query:
   '?' '*' -- -- => list of all sub commands to any main command '*'
   '?' '?' -- -- => list of all main commands

  Info:
   'I' 'A' -- -- => name of the author
   'I' 'E' -- -- => name of the engine
   'I' 'V' -- -- => version of the engine
   'I' 'R' -- -- => reason (of the last error situation)

  FEN-Position:
   'F' 'S' -- -- => produce the FEN char string matching the
                    current situation
   'F' '8' nr -- => produce the FEN char string to a numbered
                    FRC starting position (<nr> 1...960)
                    (or else 0L, when not FRC aware)
            0 -- => produce the FEN char string to
                    the classical 8x8 chess starting array
                    (or else 0L, when not standard 8x8 aware)
   'F' 'C' nr -- => produce the FEN char string to a numbered (not
                    selected) CRC starting position (<nr> 1...48000)
                    (or else 0L, when not CRC aware)
            0 -- => produce the FEN char string to
                    the Capablanca 10x8 chess starting array
                    (or else 0L, when not Capablanca 10x8 aware)
           -1 -- => produce the FEN char string to
                    the Bird 10x8 chess starting array
                    (or else 0L, when not Bird 10x8 aware)
           -2 -- => produce the FEN char string to
                    the Carrera 10x8 chess starting array
                    (or else 0L, when not Carrera aware)
           -3 -- => produce the FEN char string to
                    the GothicChess 10x8 chess starting array
                    (or else 0L, when not GothicChess aware)

  Move:
   'M' 'A' nr -- => show the currently prepared move <nr> in
                    algebraic form (letter, digit, letter, digit, extra),
                    source before target, where extra is the lower promotion
                    piece code or 'k', when king's castling has to be
                    distinguished from another king's move.
                    (or else 0L, when move <nr> does not exist)
                    This codes are sent back to the engine in case that
                    moves would be selected.
   'M' 'T' nr -- => show the currently prepared move <nr> as text
                    (targeting on PGN encoding using English language)
                    (or else 0L, when move <nr> does not exist)
   'M' 'V' nr -- => show the evaluation to currently prepared move <nr>
                    (or else 0L, when move <nr> does not exist)
   'M' 'L' nr -- => show the search level of currently prepared move <nr>
                    (or else 0L, when move <nr> does not exist)

  Enter:
   'E' 'F' -- fs => enter a FEN char string <fs> as position
                    (and prepare a list of actual moves)
   'E' 'M' -- mv => enter a move <mv>
                    (as been encoded before by DoCmd('M', 'A', nr))
                    (and prepare FEN and a list of actual moves)
   'E' '-' -- -- => take back last move
                    (and prepare FEN and a list of actual moves)

  Licensing: (to be set before calculating or pondering)
   'L' 'N' -- nm => input the user name <nm>
                    (will answer a string truncated to < 255 chars)
   'L' 'K' -- ky => input the engine-key <ky>
                    (will answer "ok" when key matches or engine is not
                     protected at all, or 0L if necessary key was wrong)
                    (the procedure should not work after some bad trials)

  (TODO)
*/


Regards, Reinhard.

[Michael Yee]

Thanks for the explanations. I think I understand a little better now. It's almost like you're defining something similar to a java "interface" (in this case consisting of one method) that the engine must implement. I guess you could have also split up your interface into multiple methods (e.g., query(), info(), enter(), move(), etc.).

It seems like a nice clean approach.

Just a few other things I'm curious about (if you don't mind):

(1) I know WB has states, while UCI is almost stateless. Is your protocol stateless too?

(2) Does it include something like UCI's "go" command? From the code excerpt, it seems to me that the engine can't initiate communication with the GUI on its own and needs to wait for the GUI to poll it for search updates...

(3) [Related to (2)...] Does the engine need to manage it's own multithreading? Or do DoCmd() calls automatically interrupt the engine?

Thanks,
Michael

[Reinhard Scharnagl]

Hi Michael,

I guess you could have also split up your interface into multiple methods (e.g., query(), info(), enter(), move(), etc.).

One Problem is to secure the seqence and exact naming of the DLL entries, which is of course easier with that single interface approach.
Next argument is the stability of that interface, even when it would be extendend someday - an effect I have always now during developing the first TMCI GUI to engine connection.

It seems like a nice clean approach.

That is one reason for making it.

(1) I know WB has states, while UCI is almost stateless. Is your protocol stateless too?

UCI-2 or UCI+ is no more stateless (in my opinion). TMCI also is not stateless as you see from the ReMove command alone. In my opinion a stateless engine will make sense only when being used as an all purose chess server, what I do not intend to create.

(2) Does it include something like UCI's "go" command? From the code excerpt, it seems to me that the engine can't initiate communication with the GUI on its own and needs to wait for the GUI to poll it for search updates...

Having the goal to make things as easy as possible, both parts have to implement a kind of polling. Smirf GUI will poll about 10 times a second using a timer, Smirf Engine will run in a separate thread when calculating and check a special bool variable whether it is going to be stopped. Those are the things I am actually working on.

(3) [Related to (2)...] Does the engine need to manage it's own multithreading? Or do DoCmd() calls automatically interrupt the engine?

As I told, the calculating has to be done in a separate thread started by the engine. The DoCmd does not alwas interrupt, only in cases, where continuing calculating will make no sense, e.g. taking a move back. But the engine could answer questions on prepared moves or the actual FEN, because those values have to be prepared earlier by the engine and could be supported even during pondering.

Additionally you will have noticed the protocol to be not defined completly yet.

Interested persons could contact me for to get access to the post alpha GUI version, to see for what the whole effort should be good.

Regards, Reinhard.

[Reinhard Scharnagl]

If you want to have a link to follow those actual developments of the Smirf TMCI GUI and engine project, please use the following link to my Smirf beta page:

http://www.chessbox.de/beta.html

and contact me, if you would be seriously interested.

Reinhard.

[Michael Yee]

Thank you for the link (and for answering all of my novice-level questions)!

Right now I'm in the initial stages of trying to create a multithreaded engine with an interface that both a WB parser/controller and a UCI parser/controller can use (e.g., with generic think(), analyze(), ponder(), etc. that the parsers can map their commands to). It seems like this approach can be easily adapted to your future protocol, too, by simply writing a dll wrapper that maps your DoCmd() calls to my engine functions.

Thanks again for the explanations and good luck!