[Standards-JIG] New version of chess game protocol

[Richard Dobson]

Robert B Quattlebaum, Jr. wrote:

> Using MUC for sending game moves does not seem complicated to me at all. 
> It seems like the obvious choice.

I wasnt saying using MUC for relaying game moves is complicated if you 
read the whole thread (yes I know its big) you will see I was refering 
to his thing to do with the referee bots validating game moves rather 
than the server handling this itself directly.

> Why is it necessary for a room to have a master/validator? I do not 
> think this is necessary at all because any client which supports the 
> protocol must have validity checking built in (for non-spectator 
> person-to-person games). This would make it very obvious to a client 
> when someone is cheating.

A game validator/management component is not needed for all games, but 
it is required for others, offhand games like monopoly, scrabble, poker, 
battleships among im sure lots of others, basically games where the 
clients do not know the full state of the game (i.e. stuff like the 
cards in a hand, letter tiles each player has), also where a single 
entity needs to provide services for the game like dealing cards, 
dealing letter tiles (for scrabble), these are things were the server 
needs to maintain what cards are unused from a pack / letter tiles. 
These are things where you need a game server component, and they are 
things that dont cleanly map onto MUC due to things like all players 
shouldnt always being given certain parts of the game state.

If you look at my idea of having the game server that directly deals 
with the game moves/turns, which also inturn (like the workgroups XEP) 
uses MUC rooms for things like in-game chat, and any broadcasts to all 
users (i.e. game state that all users should see), that is a far cleaner 
solution rather than trying to hack this all completely on top of MUC 
even where certain aspects do not really fit in with it.

> If anything I think this game component should be an extension of MUC to 
> allow for some niceties, like avoiding cropping the history of a game 
> for new spectators arriving in the middle of a game.

See above.

> I'm not saying that there isn't a need for a game-specific component, 
> I'm just stating that:
> 
>     1) The protocol (and the clients) should not prevent the use of a 
> MUC for sending game moves. MUC should be a baseline.

Sure, and thats fine for some games like chess and checkers, but as 
detailed above, not all.

>     2) If you need to create a custom protocol for game serving 
> components to distribute game moves, it should be a logical extension of 
> the MUC protocol.

Sure, but only where it actually fits in with MUC.

> Again, I refer you to sections 2.3 (Re-Use Existing Protocols) and 2.7 
> (Stay Flexible) of XEP-0134 
> <http://www.xmpp.org/extensions/xep-0134.html>, Protocol Design Guidelines.

I also refer you to 2.2 (Keep clients simple), using MUC as is requires 
clients to implement the validity checking rather than just using a 
server component that can do it.

Richard