[Standards-JIG] New version of chess game protocol

Robert B Quattlebaum, Jr. darco at deepdarc.com
Wed Oct 18 19:12:16 UTC 2006

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.

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.

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