[Standards-JIG] New version of chess game protocol

Richard Dobson richard at dobson-i.net
Tue Oct 24 08:23:33 UTC 2006


> For starters, Chess and checkers both need referrees.  How else would
> you know a move is valid?  Am I supposed to trust you?  What happens
> when you refuse to accept my move because you will lose?  What about
> playing variants where the rules are new and you may not know them
> well enough to spot infractions?  Does the client check? If so, what
> happens if there is a bug and it refuses legal moves?
>
> All games have rule enforcement, and therefor all games need an
> impartial rule enforcer if there is more than one person involved.
Very good point, but in games like chess you can potentially not always 
need a referee, whereas in some games like the ones I pointed out in a 
previous email they are absolutely required for the game to function at all.
> What I am suggesting would actually simplify the chess/checkers
>
> We tried very hard with Chesspark to keep to the spirit of complexity
> on the server side.  The question of whether it's too hard to
> implement is already solved, as one implementation now exists
> (actually several because we wrote more than one client).  Albiet our
> server implementaiton is (at least for now) proprietary.  However, not
> requiring a server implementation is severely limiting (see previous
> and later comments).  Sure a toy protocol can be implemented quickly
> that requires hardly any work.  But is that something the JSF should
> be standardizing?
>
> Here's how we did the server-compoent-required type games:
>
> We chose to implement the rule enforcement in a component called
> arbiter.  Games are setup by a component called "match", and once
> terms are agreed upon, match hands off to "arbiter" and arbiter
> creates a room, invites the players, and the game is started.
>
> Game moves are sent directly to the arbiter via IQ stanzas.  If a move
> is invalid, you get an IQ error.  If a move if valid you get a result.
> Valid moves are broadcast by arbiter via normal MUC messages to all
> players/observers in the room.  Anyone joining a room after the game
> is started will get a message directly from arbiter that contains all
> the state they need to "catch up" to the current state.
>
> It's easy enough to expand this to multiple conference rooms (for
> teams or subteams or whatever complex configurations of players you
> can imagine) by having arbiter invite people to seperate rooms, etc.
>
> Private games which don't involve an arbiter are less interesting, as
> you would be limited only to very casual games with people you trust.
> Otherwise there is nothing to stop people from cheating or rule
> violation.  Just because an arbiter is involved doesn't mean the game
> needs to be public.  You can make muc rooms private and private games
> are still possible.
>
> You still have to trust the arbiter, but in the case of Chesspark,
> this is easy because we provide one that people should trust.  In the
> case of a more generalized game network, choice among various ones
> will probably be enough.  If you suspect one is rigged, you can stop
> using it.
How you have implemented it sounds exactly the method I was trying to 
explain would work, looks good, glad others are thinking along the same 
lines :)

Richard




More information about the Standards mailing list