1

According to the UCI protocol, an engine implementing UCI should always be able to respond to stdin. I thought of two ways to accomplish this in an engine of my own:

  • Implement threads like Stockfish does, so search can be interrupted
  • While searching, pause and check stdin every so often

However I checked Sunfish's implementation and it seemingly doesn't bother implementing this (commands like stop and go infinite), yet it can still play on Lichess as a bot. This would obviously simplify my toy engine a lot. So is it necessary to implement these to be able to play the engine reasonably with a GUI like Cute Chess? Also, if I have two engines setup to play each other each given a time control, would they ever need to respond to stop, or would killing the engine be enough?

Improve this question
4
  • 1
    Why don't you think your question is answered by the UCI protocol? Are you going for a full implementation of UCI? If not, you could obviously not truthfully describe your engine a UCI-compliant.
    – user30536
    Sep 13, 2022 at 5:35
  • @user30536 clearly I'm not going for a full UCI implementation if I can get away with it. The question is, can I get away with it.
    – qwr
    Sep 13, 2022 at 5:45
  • would it really be simplified "a lot"? And it's possible that Lichess implemented some modifications to Sunfish to make it work for them.
    – user253751
    Sep 13, 2022 at 15:49
  • well I really don't want to implement threads or multiprocessing in python and I'm not sure how fast GUIs expect engines to respond. ex. Is responding in 0.5 sec considered responsive enough
    – qwr
    Sep 13, 2022 at 17:54

1 Answer 1

Reset to default
0

STDIN is buffered on any reasonable system, so unless you straight up discard UCI commands, you are (eventually) dealing with them. Taking a long time to respond may not be nice.

So how slow can you be? The UCI specification itself has no limits. Such limits would be up to the GUI.

You mentioned Cute Chess. While it may not be representative for all GUIs, Cute Chess limits should give you an idea of how fast you need to respond.

  • Engine startup: 35 seconds
  • Ping (isready): 15 seconds
  • Quit: 5 seconds.

Making a reasonably functional single threaded engine, the second alternative, "While searching, pause and check stdin every so often" would be perfectly reasonable, "every so often" meaning some seconds.

stop and go infinite:

So what would "not implementing" these even mean? in the specification:

  • stop
    stop calculating as soon as possible,

"As soon as possible" could very well be to just wait for the search to finish. This is not great but it's still implementing the communication protocol. If you consider the GUI timing out the engine and killing it if you try to stop it as "play the engine reasonably", this would be okay.

Same for go infinite. You could make your engine do a fixed length search, and then wait around for the corresponding stop command. Not a great use of the potentially extra time available, but not a communication protocol violation. (note: A GUI would ignore bestmove etc. in this move until it has sent a stop)

Also, if I have two engines setup to play each other each given a time control, would they ever need to respond to stop, or would killing the engine be enough?

An engine vs. engine match can be set up without using the stop command. The engines can reply with bestmove at their leisure, and it's up to the GUI to judge the games as lost on time and killing engines when they aren't needed anymore.

Improve this answer
1
  • Thanks for the thorough answer.
    – qwr
    Sep 17, 2022 at 23:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.