What should I support, UCI or Winboard?

[hgm]

And what is this silly notion about "my stuff"?

For myself the word "stuff" has no negative meaning. It's just a definition about all things in the case of X-/Winboard (like i learned it on school).

Someone is asking for help, and I am trying to give him some useful advice.

You switching the "focus" on the fly now. We, namely you and me, have a "part thread" debate about Android and polyglot right now and nothing more. This is one of your nice "tricks".

BTW: "Help" is if you would do one post and explain pros about your wb protocol. What you did and currently do is responding on any message in this topic where people write pro stuff for UCI or if they simply tell they like or prefer UCI. This is no help, it's just spamming.

Subsequent to that one post, three people address me directly with an unprovoked question, and some ask follow-up questions. Answering those you apparently consider 'spamming'. Well, that is another difference between us, then: I would call it 'common courtesy'.

Or perhaps you think I should only answer such questions after asking money for it...

OK, so you are only prepared to give 'help' if you are payed. We took note of that. So you can butt out now.

We ? Well, this offer is a special one only for you of course and i'm sure you know that. But "playing" with the community voice, namely "we" is just another trick by yourself.

However, this talk make no sense at all (as expected).
End of story.[/u]

The question whether running an adapter through Polyglot would work on Android only comes up because it could be an option for the original poster, who wants to run UCI engines on its GUI. It is of zero importance to me. All discussion about it is only for the benefit of the OP.

So to associate that 'stuff' in any way with me, is... well, weird.

To suggest that I should pay you to help the OP is of course insane...

Get it now?

[abik]

If you support one of the protocols, you could support the other through an adapter. Especially for GUI engines to run UCI engines there are exellent open-source adapters.

As hopefully known by now, I implemented support for both the UCI Protocol and the Chess Engine Communication Protocol (XBoard/WinBoard) in Chess for Android, which is Java GUI running on the Dalvik Virtual Machine. I found some features easier to implement in former, and other features easier in the latter, so I am steering clear from a protocol war.

However, the question whether the polyglot approach would work is interesting, so I decided to give that a try. I compiled the polyglot sources for ARM-based Android devices (I had to make a few source changes to make that work). Then I edited a polyglot.ini file pointing to my own UCI engine bikjump1.8 compiled for ARM:

Code: Select all

[Polyglot]
EngineCommand=bikjump1.8
EngineName=BikJumpAsXBoard
EngineDir=./
[Engine]

And gave it a try directly from the command line:

Code: Select all

$ ./polyglot_for_android                         
PolyGlot 1.4.67b by Fabien Letouzey.
new
st 1
post
go
1 -1 0 1 h4
1 +0 0 3 h3
1 +2 0 6 g3
1 +12 0 20 Nh3
1 +17 0 22 Nf3
2 +0 0 46 Nf3 Nf6
3 +17 0 148 Nf3 Nf6 Nc3
4 +0 1 772 Nf3 Nf6 Nc3 Nc6
5 +2 2 1691 Nf3 Nf6 Nc3 Nc6 g3
6 +0 5 3120 Nf3 Nf6 Nc3 Nc6 g3 g6
7 +5 8 6163 Nf3 Nf6 Nc3 Nc6 g3 g6 Bg2
8 +0 14 13282 Nf3 Nf6 Nc3 Nc6 g3 g6 Bg2 Bg7
9 +5 49 57243 Nf3 Nc6 Nc3 Nh6 Nd5 Nf5 b3 g6 Bb2
9 +5 49 81920 Nf3 Nc6 Nc3 Nh6 Nd5 Nf5 b3 g6 Bb2
move g1f3

So far, so good! I then tried the same approach in Chess for Android. After installing the polyglot_for_android binary, polyglot.init file and of course bikjump1.8 to internal memory, I could start polyglot_for_android as XBoard engine, but underwater talking to the UCI engine bikjump1.8. So, in principle, one could simply implement one protocol in the GUI, and rely on the adapter to support the other protocol, even on Android.

[Daniel Mehrmann]

Hello Aart,

thanks for your test!

I never had any doubts that it could works technical, but what kind of solution is that. However, I implemented protocol support through Java as well. It was easier for myself and the best solution in my case.

I like your Apps. Keep up your good work.

Regards
Daniel

[hgm]

OK, so I guess we all agree now that using Polyglot is a good technical solution, that would save the GUI developer a lot of work, because he would only have to implement one of the two protocols, and get the other for free.

As was my original advice...

[Daniel Shawul]

No doubt Winboard. For one UCI is _old_ despite what many tell you here. Winboard is continuously being researched and you can play almost any board game you like with it. That should be the goal. Supporting the winboard alien protocol will give you a very powerful GUI without even knowing what type of game is being played. Take a look at a link in my signature for a Java GUI that can support winboard and also uci engines through polyglot. My engine Nebiyu can play 50 or more types of games and all can be played smoothly.
The key here is:

a) The only requirement on the engine's side is that it sends a FEN after each move. Actually this is a requirement only for the referee engine so one in a thousand. If you are up for it you can write an engine like Nebiyu to act as referee (basically part of the GUI) to completely remove this requirement. But the point is to give complete freedom to the enigne designerto do whatever the hell it wants to do with it so this is not necessary.

b) Don't try to recongnize move formats. "#4sfrws" can be a MOVE if the engines understand it. This means a move indicator like "usermove" is necessary.

(Not part of protocol discussion)

c) Design your GUI to accept different types of players : Winboard engines (Basic), Using adapters (polyglot and others), Java engines, remote engines (tcp), remote process AND Humans. Yes humans are also installed and it is the most troublesome for me because input from the GUI is meant for them.

d) Aim for a console and GUI interface, and multi-threaded as well. The console mode is very important when you want to use it as a game server. My ICS sever allows thousands of games to be played simultaneously so there is no need to use a GUI there but it still can do it.
The GUI class simply overrides the console mode and offers better functionality such as painting separate windows for each game I love my My GUI does so much stuff with little effort. I will post some pictures later.

[hgm]

I like the design with a referee engine. It means that only the author of the first engine for a certain game is burdoned with things like rule enforcement, result adjudication, (and optionally move highlighting). Any later engine could be 'light weight', and omit implementation of the parts of the protocol involved in these tasks. The GUI would use the heavy-weight engine as referee, consulting it to obtain the required rule knowledge.

I might convert WinBoard / XBoard to utilize this scheme. In fact these are already sort of using this method: the first engine is always following the currently displayed position, even in Edit Game mode, judging move legality. So the referee engine in fact is already there. But currently you cannot play against any other engine than the referee engine, and when two engines play, it is always the referee against another.

So what I would have to do is allow active use of the second engine (for analysis or human-engine play) where the first engine remains following the game in force mode silently (unless there are illegal moves, or it detects game end). It seems a good feature anyway to make it possible to analyze with two engines at once, which requires nearly the same code change (just refraining from silencing the referee). And for engine-engine games there would have to be a third engine. Although that would be less important, as the referee is mainly needed for implementing functions that involve humans. (Who make mistakes during move entry, want to see target squares highlighted, and one-click moving to be available.)

[Daniel Shawul]

I like the design with a referee engine. It means that only the author of the first engine for a certain game is burdoned with things like rule enforcement, result adjudication, (and optionally move highlighting). Any later engine could be 'light weight', and omit implementation of the parts of the protocol involved in these tasks. The GUI would use the heavy-weight engine as referee, consulting it to obtain the required rule knowledge.

It is the best design for board games IMO. It is basically part of the GUI in a separate executable. This separation gives great freedom to game inventors without the core GUI code (i.e painting stuff) not being touched. Rule checking (legal move or not) ,highlighting or any other fancy stuff could all be put there taking away much off the burdon for known games. You can even make the whole design of winboard (not only the alien edition) like this without anyone noticing it. Automatically loading a simplistic referee engine in the background should do it. If the user wants other games, he switches the referee engine. Even older engines which do not support alien protocol can be played with no problem. The design provides a neat template for future games...

I might convert WinBoard / XBoard to utilize this scheme. In fact these are already sort of using this method: the first engine is always following the currently displayed position, even in Edit Game mode, judging move legality. So the referee engine in fact is already there. But currently you cannot play against any other engine than the referee engine, and when two engines play, it is always the referee against another.

So what I would have to do is allow active use of the second engine (for analysis or human-engine play) where the first engine remains following the game in force mode silently (unless there are illegal moves, or it detects game end). It seems a good feature anyway to make it possible to analyze with two engines at once, which requires nearly the same code change (just refraining from silencing the referee). And for engine-engine games there would have to be a third engine. Although that would be less important, as the referee is mainly needed for implementing functions that involve humans. (Who make mistakes during move entry, want to see target squares highlighted, and one-click moving to be available.)

I think you should do it. For one nobody will notice the change (important for the mass user ), since the standard chess referee will be loded by default but it gives a simple way to add the alien stuff. The referee engine is loaded at startup and is blocked on input (no cpu time is lost). Then whenever an input is recieved from any of the two (or more) playing engines, it simply sends it to the referee FIRST, then the referee checks for legality, highlights, adjuncates and do other stuff, after which the next engine to play will be sent the same move info. This reminds me also about multi-player games where this design will also simplify. No white,black or red color. Existing winboard engines that have no idea of multiple colors can play multi-player games or other types of weird pairings. It is better if the engine doesn't try to figure whose turn it is to allow complex pairings. The refree can do such things and others we may not have thought about yet.

[Daniel Mehrmann]

OK, so I guess we all agree now that using Polyglot is a good technical solution, that would save the GUI developer a lot of work, because he would only have to implement one of the two protocols, and get the other for free.

As was my original advice...

My advice is:

Polyglot is a technical solution to get another protocol for free, but it's not recommend for Android through this reasons:

- Not direct MVC/MVP compatible
- BlackBox factor
- Maybe unkown consequences if 100% load (specialy on weak devices)