[Standards-JIG] New version of chess game protocol
mridul at sun.com
Wed Oct 18 20:00:17 UTC 2006
Robert B Quattlebaum, Jr. wrote:
> On Oct 6, 2006, at 2:14 AM, Richard Dobson wrote:
>> The game server component (games.jabber.org) will manage the games
>> and validate any turns people make and sending out the result of that
>> turn to all the players which the players will use to update their
>> copy of the board etc so they dont have to worry about checking
>> against the rules etc. Similar to how the workgroups protocol works
>> if a chat room is needed in a game the game server component will
>> create the room and give its address to all the participants (i.e.
>> chess34 at muc.jabber.org) so they can join if they want to, this seems
>> far more inline with xmpp/jabber to me as its using the various
>> components (i.e. MUC) for the purpose it was designed for rather than
>> trying to layer stuff like the sending of game moves etc ontop of it
>> which makes things far more complicated than above as you need to
>> have one of the people in the room acting as the master/validator of
>> any moves which just seems rather messy to me, it seems far better to
>> me to just move all the complexity to the server properly using a
>> proper component designed for the job.
> Using MUC for sending game moves does not seem complicated to me at
> all. It seems like the obvious choice.
> 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.
The client need not to be a single client - I could roll out a new
client which adheres to the protocol and start playing.
If this is opensource (or someone else writes one too :) ) , you could
modify it such that you remove validation , etc.
It could be willful maliciousness - or could be just plain bugs (most
newbie bots for example dont handle promotion , castling and enpassent
properly in chess - especially in frc).
Either way , the protocol should allow for validation of state.
This need not necessarily be enforced - for example : if a service
provider mandates a client , validates the version (disco , etc) and is
assured that it is 'his' client which has all client side validation
built in - then we could skip the server side validation.
This is an option - but most , if not all , online games have sevrer
side state validation for sanity purposes primarily , and to prevent
hacking/cheating/etc attempts alternatively.
> 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.
> 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.
Yep ,. muc makes perfect sense to me too.
It should be possible to leverage it and add minimal features to build
out what is required.
> 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
> Robert Quattlebaum
> Jabber: darco at deepdarc.com
> eMail: darco at deepdarc.com
> www: http://www.deepdarc.com/
More information about the Standards