Mzinga
Mzinga copied to clipboard
jonthysell
UHP: Facilitating remote play between two Viewers on the same Engine
Suppose we have an instance where two viewers, V1 and V2, representing two players playing remotely (e.g. online) want to play a game together on the same engine E
V1 <==> E <==> V2
This isn't really supported by UHP, since the only way a viewer can receive a move from the engine is by requesting it via bestmove, which is more like the engine suggesting a move rather than stating a new gamestate.
Assuming the engine maintains two separate UHP sessions for the viewers, a command like playandwait MoveString could be added which submits the move, and then only replies when the other viewer submits their move. This reply should include the other player's MoveString as well as the new GameString.
I suppose an alternative is that both remote Viewers submit UHP commands to the same session, although this implies some control logic on the Engine's side to ensure that V1 can't make plays for V2.
I wrote up a little proposal for the new command here https://github.com/wgreenberg/roach/blob/master/UHP.md. Chances are I'll roll with it for now to get my Hive server off the ground, but I'm curious if you have any thoughts @jonthysell.
In my imaginings of online play with the UHP, I imagined one running Engine which "hosts" the game, then two or more Viewers can receive the output of that engine.
The Viewers could also send commands, and it would be up to the hosting engine to decide whether to accept that command or not. And in theory, that hosting Engine might have no AI at all, so as not to burden the server with any tree search from bestmove.
There would just need to be some kind of network protocol for encapsulating the UHP input and output, and session management for creating/joining a game. Standardizing that network interface might be worthwhile.
Even despite using a shared code-base, MzingaViewer is architected such that the Engine is in running the game, and the Viewer is just there to facilitate input and UI.
It uses an EngineWrapper base class to interface with a engine - with InternalEngineWrapper and CliEngineWrapper subclasses - there's not reason why it there couldn't be a NetworkEngineWrapper.
