Frivolous Engine Feature Ideas

[jtwright]

In between working on Elo improving changes, I've been thinking about other ways to engage with and have fun with my engine as the developer. One thing I did to that end in a dev version of Mantissa is implementing Brain & Hand chess capabilities. https://www.sparkchess.com/hand-brain-chess.html

I extended Mantissa's UCI interface to include some new commands which alter her behavior for future queries. Notably, the bhmode command, which takes brain, hand, or none. Being in one of the first two modes alters Mantissa's behavior, hides infos (so you don't cheat), and so on so one could partner with Mantissa as the brain or hand in a game. I played some games alongside Mantissa in this way. I definitely dragged her down, but it was a lot of fun. I could document further the exact way to do the rest of the commands if people want, but I'll wait on that (subject to change anyway).

This feature is incredibly frivolous, likely no one but me will ever use it, but I'm totally going to include it (polished up) in the next official release (whenever that happens). It was very gratifying to have a new way to engage with Mantissa and my work on Mantissa and a good break from chasing Elo.

I also used to have a fork of Mantissa for playing antichess called Antissa, I might revive that project.

I'm curious what other things any of you might have done that were interesting ways to use or engage with your engines, or if there are any you've thought of but haven't done.

[Ovyron]

Frivolous ideas? Here's one: The engine starts with more time than the human. However, if the human manages to cause a ponder hit seconds are added to the human's clock. That is, the engine thinks for a while and makes a PV that starts Move 1.A B - if the human plays B, she gets rewarded with more time on the clock.

This works because the engine hides the PV from the human.

Could be fun trying to guess the move the engine predicts you will play to gain an edge on the clock, because it'll be worthwhile to spend more time thinking about it and get rewarded than playing faster and not get the clock's time.

[hgm]

Problem is that engines do not control the clocks. The GUI does that. I did not quite get the bhmode idea, but hiding thinking output from the user is normally also a GUI function.

[jtwright]

Problem is that engines do not control the clocks. The GUI does that. I did not quite get the bhmode idea, but hiding thinking output from the user is normally also a GUI function.

True. Given that this was for personal use, I "teamed up" with Mantissa via communicating back and forth directly through the command line, just as you would normally type UCI commands. A flow would go like this for if Mantissa was the brain:

Code: Select all

<- bhmode brain
//anything else you wanted to set
//example move, given position is set correctly
<- go movetime 10000
-> info depth X nodes Y nps Z // doesn't display the rest to prevent cheating
-> bestpiece e2 //indicates that I, the hand should move the piece on e2

Or if Mantissa was hand:

Code: Select all

<- bhmode hand
//...
// assuming position set up
// I select the piece on e2
<- go movetime 10000 piece e2
-> info depth X nodes Y nps Z // omits the rest to prevent cheating
//...
-> bestmove e2e4

The clocks are an issue. This isn't feasible really for any actually quick time control. I arbitrarily was giving Mantissa 10 seconds to think and playing these games as casual correspondence matches. For any faster time controls, etc, and probably for user friendliness, you'd really want to integrate this with some GUI (e.g. modifying cutechess or something) to handle these extensions and such, but as an experiment this worked fine.

[hgm]

What you are doing goes against the design philosophy of UCI. There is no need to define new UCI commands for this, because UCI has engine-defined options. You should just have the engine print

option name bhmode type combo var hand var brain var none

and have it react to

setoption name bhmode value brain

Then you could use in in any GUI without the need for modification.

[hgm]

As to frivolous things I have done with engines:

I have added an engine-to-GUI command 'click', with a square as argument, which would make the GUI act like the user had clicked that square. One of the applications would be to implement one-click moving, in response to a 'lift' command from the GUI that tells the engine which piece the user selected.

Also interesting is the 'highlight' command, which indicates to the GUI which squares it should highlight and how, by means of a color FEN.

The 'setup' command can be used to send a position to the GUI. E.g. for playing from a non-standard initial position.

[jtwright]

option name bhmode type combo var hand var brain var none

and have it react to

setoption name bhmode value brain

Yeah, agreed this is how I'd probably do it for an official release. I think that applies well to this specific situation, but I think there are cases for extensions to the "UCI" command line interface in an engine (though agreed you can't expect GUIs or other engine authors to respect idiosyncratic additions).

For example, Stockfish (and Mantissa and many others) implement an "eval" command, which doesn't exist in the UCI spec to my knowledge and is not intended for the GUI to use. Usually it just outputs the static eval of the current position, super useful for debugging.

In the brain-hand case, such a thing comes to pass when the engine is playing as the hand. This requires you to specify a piece to the engine which it might not otherwise be a big fan of using. It's true that one could probably finagle something ridiculous with options for this (e.g. an option value for each tile on the board), but it would be much more straightforward to extend the "go" command or something similar to take another argument ("piece" or "pieceat" or something). I think the hard limit though is if one breaks compatibility with a specified UCI behavior and your engine can no longer work with normal GUIs.

As to frivolous things I have done with engines:

I have added an engine-to-GUI command 'click', with a square as argument, which would make the GUI act like the user had clicked that square. One of the applications would be to implement one-click moving, in response to a 'lift' command from the GUI that tells the engine which piece the user selected.

Also interesting is the 'highlight' command, which indicates to the GUI which squares it should highlight and how, by means of a color FEN.

The 'setup' command can be used to send a position to the GUI. E.g. for playing from a non-standard initial position.

Those are pretty cool actually, `setup` seems especially interesting to me.

[Ovyron]

The engine should not depend on a GUI to control its time for something like this. The engine could have internal clocks that are shown to the user instead of the PV, the engine could send the information with its remaining time and the opponents' every second just like it sends any message. It'd work as long as autoflagging is off in the GUI.

What you are doing goes against the design philosophy of UCI.

That philosophy depends on people implementing new features on GUIs. I continue to use the Shredder Classic 3 GUI and it's not getting updated, so it'll be great if people implement new features on their engines that can be used in any GUI no matter how old and without having to think of updating the GUI.

Self-sufficient engines.

[hgm]

The engine should not depend on a GUI to control its time for something like this. The engine could have internal clocks that are shown to the user instead of the PV, the engine could send the information with its remaining time and the opponents' every second just like it sends any message. It'd work as long as autoflagging is off in the GUI.

What you are doing goes against the design philosophy of UCI.

That philosophy depends on people implementing new features on GUIs. I continue to use the Shredder Classic 3 GUI and it's not getting updated, so it'll be great if people implement new features on their engines that can be used in any GUI no matter how old and without having to think of updating the GUI.

Self-sufficient engines.

It sounds as if you would like UCI engines to be WB engines.

Having an option that controls the amount and kind of infos the engine sends to the GUI is well within the UCI specs, and would work perfectly on Shredder Classic 3.

In the brain-hand case, such a thing comes to pass when the engine is playing as the hand. This requires you to specify a piece to the engine which it might not otherwise be a big fan of using. It's true that one could probably finagle something ridiculous with options for this (e.g. an option value for each tile on the board), but it would be much more straightforward to extend the "go" command or something similar to take another argument ("piece" or "pieceat" or something). I think the hard limit though is if one breaks compatibility with a specified UCI behavior and your engine can no longer work with normal GUIs.

The UCI 'go' command supports a 'searchmoves' specification with which you can restrict the moves the engine can chooese between. This is actually more versatile than what you propose, as you could restrict the choice to any subset of moves. To do what you want you should just pass it all the moves of a single piece.

[Ovyron]

It sounds as if you would like UCI engines to be WB engines.

My only problem with WB engines was the lack of some searchmoves/exclude best move/MultiPV feature which made them being used for analysis impractical because there was no way to quickly make it show an eval for its second favorite move.

I now even wonder how people used WB engines for analysis at all.