front-ending

[mvanthoor]

The stand-alone version of micro-Max uses such a minimalistic protocol: it only accepts moves, and to make it think and play a move you have to send it an empty line. After every input it responds with an ascii board.

I have the same thing in my engine as well, for testing. It accepts moves:

e2e4
g1f3
e1g1
a7a8q (r/b/n)

and some commands such as:

fen <position>
perft <depth) (in the current position)
m (search/make the next move)
t (take back last move)
quit and exit (self-explanatory...)
clear (which does nothing and only exists because I incessantly type "clear" in a console and I want to prevent "unknown command" errors)

After each change it prints an ASCII-board.

It's nice to have for testing

In the end I'll make it a feature alongside UCI and XBoard and include it with a conditional compile.

[odomobo]

If you would abandon the requirement that input moves must be legal, it becomes much easier to set up a given position. Just move pieces that are not yet where they are supposed to be to the square where they should go. If that square is occupied, just move the occupant to an empty square first. You start with capturing all pieces that are not needed.

I see your logic, but it won't always be easy to implement this for all engines, depending on how they do move processing. In particular, my engines would not be able to easily implement this. Also, it feels kind of like a hack, which might not be appropriate for a simplified protocol.

and some commands such as:

fen <position>
perft <depth) (in the current position)
m (search/make the next move)
t (take back last move)
quit and exit (self-explanatory...)

Fen and perft are crucial for testing an engine, which is the next step after getting the move generator working. Takeback is useful when playing from command line, but not necessary for a protocol (which could reset and perform all the moves again).

It might be an excellent idea if fen and perft were flagged as optional commands -- frontends would need to gracefully handle if they aren't supported.

[hgm]

Funny, none of my engines has a perft command. Most of them would not get the numbers correct anyway. Because they do not do all under-promotions.

I do usually put in a command to print the internal board. (And when they get an illegal move as input, print that automatically, as well as the move list.)

When you do want to have a function for position setup in a minimal protocol, rather than using moves or illegal moves, you could add understanding of drop moves, like P@e2, and a command for clearing the board. A bit like the old CECP 'edit' command, except that you would not have a special mode for it, but interpret it in the main command loop.

[mvanthoor]

Fen and perft are crucial for testing an engine, which is the next step after getting the move generator working. Takeback is useful when playing from command line, but not necessary for a protocol (which could reset and perform all the moves again).

I use "m", "t" and move input to "play" on the commandline while I'm writing my first version of the search function.

In the end this commandline will be stripped from the engine and become an optional feature that can be enabled during compiling. I'll probably have "uci", "console", and "winboard", with UCI being the default (it'll be used if none of the features are included). I'll have to see what Rust has to offer in this department.

[odomobo]

When you do want to have a function for position setup in a minimal protocol, rather than using moves or illegal moves, you could add understanding of drop moves, like P@e2, and a command for clearing the board.

I like this idea. You'd also probably want some commands for handling castling rights, en passant.

However, it might just be simpler to implement fen than to implement drops (or roughly as simple). Fen has the advantage of being easy to use from the command line, and being an existing standard. It would make sense to build the commands around what someone would enter at the command line, because that's the natural starting point for an engine.

[odomobo]

In the end this commandline will be stripped from the engine and become an optional feature that can be enabled during compiling.

The protocols start with identification commands (uci starts with "uci", cecp starts with "xboard"). Your engine can support all of them, and just dynamically select the appropriate interface at runtime.

[Dann Corbit]

Other than (perhaps) dumping a board image to the screen, I do not see how these things are easier to play chess with than a regular winboard/xboard/cecp interface.
In fact, once you have cecp implemented you can instantly play using Winboard and have a lovely board.
It seems like a very, very small win to me.

[mvanthoor]

When you don't even have a search, there is nothing to play against. In the console, i can just dump anything I want to see, be it some result in a variable, or an entire line.

Arena has a debug window, but I like to interact with the engine directly in the early stages (same when writing a micro-service or an embedded system for example).

And I don't like UCI to do that. I haven't ever used a Winboard engine to be honest. I went from native Chessbase to UCI directly, and only recently installed Arena for its debug window which may come in useful.

After the system/engine is complete in a bare bones but known good state, I'll start to use front-ends.

[Dann Corbit]

I have to admit that the UCI interface is hard to play a game with from the command line.
It used to be that the UCI interface was just plain better because of the ease of configuration compared to Winboard.
But HGM has closed that gap and now Winboard can do anything that UCI can.

[mvanthoor]

In the end this commandline will be stripped from the engine and become an optional feature that can be enabled during compiling.

The protocols start with identification commands (uci starts with "uci", cecp starts with "xboard"). Your engine can support all of them, and just dynamically select the appropriate interface at runtime.

I know, but I'd like to have the least amount of dead code in the engine as possible. I assume 90% of the users would use UCI, the others would use Xboard out of principle, and only a few (if any, besides myself) developers would do anything with the console interface.

Thus the default version will only have UCI, and maybe perft as a special UCI command.