[Standards-JIG] New version of chess game protocol
richard at dobson-i.net
Wed Oct 18 20:31:13 UTC 2006
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.
> 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.
More information about the Standards