UCI Communicator engine that can work between different GUIs

[Juan P. Naar]

Hello,

I wonder if it would be technically possible to program a UCI engine that would allow to play matches between different GUIs (such as Chessbase, Arena, Lokasoft) in a single PC. It would work like this: UCI_Engine_A is installed in GUI-A and UCI_Engine_B is installed in GUI-B, then the Engine_A would send messages to Engine_B and vice-versa so that they can play matches in between the different GUIs.

Would that be technically possible to code?

[hgm]

I once made a program that did this for WB engines. The different instances passed messages through a socket, so they could also run on different computers. The main application was to run the in human-vs-engine mode, so that two humans could play against each other over the internet, each using their own GUI on their own machine.

[phhnguyen]

Hello,

I wonder if it would be technically possible to program a UCI engine that would allow to play matches between different GUIs (such as Chessbase, Arena, Lokasoft) in a single PC. It would work like this: UCI_Engine_A is installed in GUI-A and UCI_Engine_B is installed in GUI-B, then the Engine_A would send messages to Engine_B and vice-versa so that they can play matches in between the different GUIs.

Would that be technically possible to code?

If you are a skilled programmer and have the time, you can certainly do what you want. Thus, the answer is definitely YES!

However, in real life, you need to solve multiple problems:
- UCI is a protocol to communicate between a chess engine and a chess GUI. It is not for communication between engines or between chess GUIs. In other words, there is no standard for two different chess GUIs to talk to each other. The solution is that you should create a new standard to communicate between chess GUIs and then ask some of their authors to apply it. Or you create your own two different chess GUIs with that standard. I don't think you will be successful with either way. (A solution is to connect two chess GUIs to a chess server such as Lichess or ICS, which can help to play a few games, but is not suitable for tournaments)

- Your thinking is so complicated. Why do you want to run two different GUIs on one computer to play chess tournaments? Typically, we need only one chess GUI (one instance) on a computer to create tournaments with multiple chess engines. When using multiple computers, we need to run multiple instances of ONE chess GUI only on those computers. Some chess GUIs (e.g., Banksia GUI) can help you create tournaments using multiple computers.

Authors of chess GUIs can make their chess GUIs "talkable" or playable to other chess GUIs, but it looks like they don't see any reason to do that.

The answer is NO!

[hgm]

You are too pessimistic about this. You don't need to have a separate GUI-GUI protocol and connect the GUIs directly. The GUIs can each connect to a 'pseudo-engines', and these can communicate with each other in a custom protocol that needs not be supported by anyone but themselves. (In theory you could do with a single intermediate communicating with both GUIs, but as GUIs launch their engines as daughter processes this cannot be achieved.)

The trick is that the intermediate receiving a move (in UCI that would be the last move in the position command) from its 'opponent' (say engine A), this move should be relayed like an engine played it (in UCI through a bestmove command) to the other GUI. With two communiicating intermediate processes this can be easily achieved by letting each pseudo-engine handle the UCI startup handshake (uci/uciok, isready/readyok). After that they only have to pass moves between each other, which they strip off the position commands coming from the GUI, and wrap in a bestmove when they send a move received from their partner intermediate to the GUI.

[Juan P. Naar]

Hello,

I wonder if it would be technically possible to program a UCI engine that would allow to play matches between different GUIs (such as Chessbase, Arena, Lokasoft) in a single PC. It would work like this: UCI_Engine_A is installed in GUI-A and UCI_Engine_B is installed in GUI-B, then the Engine_A would send messages to Engine_B and vice-versa so that they can play matches in between the different GUIs.

Would that be technically possible to code?

If you are a skilled programmer and have the time, you can certainly do what you want. Thus, the answer is definitely YES!

However, in real life, you need to solve multiple problems:
- UCI is a protocol to communicate between a chess engine and a chess GUI. It is not for communication between engines or between chess GUIs. In other words, there is no standard for two different chess GUIs to talk to each other. The solution is that you should create a new standard to communicate between chess GUIs and then ask some of their authors to apply it. Or you create your own two different chess GUIs with that standard. I don't think you will be successful with either way. (A solution is to connect two chess GUIs to a chess server such as Lichess or ICS, which can help to play a few games, but is not suitable for tournaments)

- Your thinking is so complicated. Why do you want to run two different GUIs on one computer to play chess tournaments? Typically, we need only one chess GUI (one instance) on a computer to create tournaments with multiple chess engines. When using multiple computers, we need to run multiple instances of ONE chess GUI only on those computers. Some chess GUIs (e.g., Banksia GUI) can help you create tournaments using multiple computers.

Authors of chess GUIs can make their chess GUIs "talkable" or playable to other chess GUIs, but it looks like they don't see any reason to do that.

The answer is NO!

The answer as to why it's needed is simple: There are multiple GUIs with propietary engines but which do support external engines (such as UCI or Winboard). Propietary engines are locked to their own GUI and can't play against other propietary engines of different GUIs. Let me give you a few examples:

Lokasoft: It supports both Winboard and UCI, but the engines LCHESS and Chess Tiger 12, 13 and 2004 can only run in Lokasoft.
Chessbase: It supports both Winboard and UCI, but there are several propietary only engines that can only run there (Fritz, Hiarcs, Junior, etc).
Genius: It supports Winboard, but only the Chess Genius engines will run in that GUI.

So the only way to play engine matches between propietary engines is to either play the games by hand, or have another PC and figure out the deep mess that Auto232 is, and some of the GUIs don't even support it. What if you just want both GUIs to interact in a single PC?

[phhnguyen]

You don't need to have a separate GUI-GUI protocol and connect the GUIs directly. The GUIs can each connect to a 'pseudo-engines', and these can communicate with each other in a custom protocol that needs not be supported by anyone but themselves. (In theory you could do with a single intermediate communicating with both GUIs, but as GUIs launch their engines as daughter processes this cannot be achieved.)

The trick is that the intermediate receiving a move (in UCI that would be the last move in the position command) from its 'opponent' (say engine A), this move should be relayed like an engine played it (in UCI through a bestmove command) to the other GUI. With two communiicating intermediate processes this can be easily achieved by letting each pseudo-engine handle the UCI startup handshake (uci/uciok, isready/readyok). After that they only have to pass moves between each other, which they strip off the position commands coming from the GUI, and wrap in a bestmove when they send a move received from their partner intermediate to the GUI.

Are you designing a new UCI protocol/version 3? IMHO, let the UCI protocol alone. On one hand, we should respect its authors, only its authors have the right to modify it. On the other hand, I guess many engine programmers don't want any modification of that protocol, which does not link directly to their chess engines.

IMO, there is no difference between designing a new standard way to connect GUI-GUI or extending an existing protocol for that job. 2 in 1 may not be a good idea, especially when very few people want it.

BTW, no one can limit you from modifying other protocols, say the Winboard protocol, or creating a new one for your tricks!

You are too pessimistic about this.

The sounds like you are optimistic about this. Why don't you start with the Winboard protocol and the Winboard program right now?
Hope your chess GUI will get some more users with that work!

[phhnguyen]

The answer as to why it's needed is simple: There are multiple GUIs with propietary engines but which do support external engines (such as UCI or Winboard). Propietary engines are locked to their own GUI and can't play against other propietary engines of different GUIs. Let me give you a few examples:

Lokasoft: It supports both Winboard and UCI, but the engines LCHESS and Chess Tiger 12, 13 and 2004 can only run in Lokasoft.
Chessbase: It supports both Winboard and UCI, but there are several propietary only engines that can only run there (Fritz, Hiarcs, Junior, etc).
Genius: It supports Winboard, but only the Chess Genius engines will run in that GUI.

So the only way to play engine matches between propietary engines is to either play the games by hand, or have another PC and figure out the deep mess that Auto232 is, and some of the GUIs don't even support it. What if you just want both GUIs to interact in a single PC?

As I said, your thinking is complicated (at least in my view). Why don't you ask/request the authors of those chess GUIs to support other chess engines? It is easier and more logical than asking them to connect to other chess GUIs. If they don't want to support other chess engines, why do they want to support other chess GUIs

You may ask the authors of those chess engines to support other protocols too.

BTW, I guess they all have reasons for not supporting some things. Some chess GUIs (such as Fritz) support only Windows but not other OSs. Some support only UCI. Banksia doesn't support Winboard protocol 1 (because I think it is not safe/good enough), but supports Winboard protocol 2 and UCI. Winboard (chess GUI) supports only Winboard protocol, but not (directly) UCI (I am sure HGM can support UCI directly, but he does not want to). Auto232 is too old a thing to support.

[Juan P. Naar]

The answer as to why it's needed is simple: There are multiple GUIs with propietary engines but which do support external engines (such as UCI or Winboard). Propietary engines are locked to their own GUI and can't play against other propietary engines of different GUIs. Let me give you a few examples:

Lokasoft: It supports both Winboard and UCI, but the engines LCHESS and Chess Tiger 12, 13 and 2004 can only run in Lokasoft.
Chessbase: It supports both Winboard and UCI, but there are several propietary only engines that can only run there (Fritz, Hiarcs, Junior, etc).
Genius: It supports Winboard, but only the Chess Genius engines will run in that GUI.

So the only way to play engine matches between propietary engines is to either play the games by hand, or have another PC and figure out the deep mess that Auto232 is, and some of the GUIs don't even support it. What if you just want both GUIs to interact in a single PC?

As I said, your thinking is complicated (at least in my view). Why don't you ask/request the authors of those chess GUIs to support other chess engines? It is easier and more logical than asking them to connect to other chess GUIs. If they don't want to support other chess engines, why do they want to support other chess GUIs

You may ask the authors of those chess engines to support other protocols too.

BTW, I guess they all have reasons for not supporting some things. Some chess GUIs (such as Fritz) support only Windows but not other OSs. Some support only UCI. Banksia doesn't support Winboard protocol 1 (because I think it is not safe/good enough), but supports Winboard protocol 2 and UCI. Winboard (chess GUI) supports only Winboard protocol, but not (directly) UCI (I am sure HGM can support UCI directly, but he does not want to). Auto232 is too old a thing to support.

There's absolutely no way that will happen, especially because some of these GUI's development stopped decades ago.

By the way, I stumbled upon this exact concept: a communicator between Lokasoft and Chessbase which was released by Christophe Drieu, T.Rex's author:
https://web.archive.org/web/20060202213 ... 3/ct15.htm

I tested it and it does work. Sadly, it only works between Lokasoft and Chessbase.

[hgm]

You don't need to have a separate GUI-GUI protocol and connect the GUIs directly. The GUIs can each connect to a 'pseudo-engines', and these can communicate with each other in a custom protocol that needs not be supported by anyone but themselves. (In theory you could do with a single intermediate communicating with both GUIs, but as GUIs launch their engines as daughter processes this cannot be achieved.)

The trick is that the intermediate receiving a move (in UCI that would be the last move in the position command) from its 'opponent' (say engine A), this move should be relayed like an engine played it (in UCI through a bestmove command) to the other GUI. With two communiicating intermediate processes this can be easily achieved by letting each pseudo-engine handle the UCI startup handshake (uci/uciok, isready/readyok). After that they only have to pass moves between each other, which they strip off the position commands coming from the GUI, and wrap in a bestmove when they send a move received from their partner intermediate to the GUI.

Are you designing a new UCI protocol/version 3? IMHO, let the UCI protocol alone. On one hand, we should respect its authors, only its authors have the right to modify it. On the other hand, I guess many engine programmers don't want any modification of that protocol, which does not link directly to their chess engines.

IMO, there is no difference between designing a new standard way to connect GUI-GUI or extending an existing protocol for that job. 2 in 1 may not be a good idea, especially when very few people want it.

BTW, no one can limit you from modifying other protocols, say the Winboard protocol, or creating a new one for your tricks!

You are too pessimistic about this.

The sounds like you are optimistic about this. Why don't you start with the Winboard protocol and the Winboard program right now?
Hope your chess GUI will get some more users with that work!

You did not pay attention. Above I posted that I did exactly what you propose already many years ago. In order to allow users in different locations to use WinBoard to play against each other (in self-designed variants). This is why I know how easy this was. Main problem in using it was that the pseudo-engine that connected to the socket first had to open the socket as a server. With all resulting firewall problems if you really wanted to play a remote opponent. That opponent then could simply connect his pseudo-engine to that server as a client.

To facilitate that I was even running a 'relay server' on my website. Both players could then connect to that as client, and if they were using the same password for that, the server would pass any messages between them, like they were connected directly.

You also misunderstood that I wanted to modify UCI. The pseudo-engines present themselves as perfectly normal UCI engines to the GUI. Only when communicating to each other (through TCP/IP, not through a pipe) they use a (very simple) custom protocol.

[phhnguyen]

You also misunderstood that I wanted to modify UCI. The pseudo-engines present themselves as perfectly normal UCI engines to the GUI. Only when communicating to each other (through TCP/IP, not through a pipe) they use a (very simple) custom protocol.

I am still confused in your post that UCI and "when communicating to each other" are one or two different things? If they are two different things, it is not the answer for the topic (UCI Communicator engine that can work between different GUIs).

BTW, as I mentioned above, we don't have a standard for GUI-GUI communication, regardless of how complicated or simple it is! It is not a problem for two instances of your GUI to communicate with each other, because you can do what you want. However, for two different GUIs, they should know and talk in the same language.

Perhaps, at the moment, only you and WinBoard are the hope of the author of this topic. Could you start first?