[Standards-JIG] New version of chess game protocol

Mridul 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 
> Guidelines.
> __________________
> Robert Quattlebaum
> Jabber: darco at deepdarc.com
> eMail:  darco at deepdarc.com
> www:    http://www.deepdarc.com/

More information about the Standards mailing list