[Standards-JIG] New version of chess game protocol

Jack Moffitt jack at xiph.org
Mon Oct 23 21:31:25 UTC 2006


I will respond to some of the other mails in this thread as soon as I
can, but I figured I should jump in now.  (I've refrained from
participating before since I was already working on a gaming protocol
for commercial use: http://www.chesspark.com).
> Chess and checkers do not need referees, and thus I think
> requiring those games to use a game server for no other reason than
> to have them under the same roof is a serious flaw, IMHO.

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.

> What I am suggesting would actually simplify the chess/checkers
> protocol, and remove the dependence on some new server-side
> component--thus making it easier to use and adopt *right now*. Look
> what happened to pub-sub. Relying on new server implementations is
> dangerous for a protocol, and should be avoided if at all possible,
> and it is quite avoidable in this case. I see no reason to force
> chess and checkers (and other similar games) to use a game server
> when it is quite simply not necessary.
>
> Unless you want to abandon the ability for two people to conduct a
> private chess/checkers game between themselves (which would be a
> horrible idea, IMHO), it seems that the clients MUST implement some
> sort of validity checking anyway. So my suggestion would not increase
> client complexity, only decrease dependency on fancy new server
> components.

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.

jack.



More information about the Standards mailing list