[Standards-JIG] New version of chess game protocol
Michal 'vorner' Vaner
michal.vaner at kdemail.net
Tue Oct 24 09:03:48 UTC 2006
On Mon, Oct 23, 2006 at 03:31:25PM -0600, Jack Moffitt wrote:
> 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?
If there is a bug, then it should be fixed and not presented to the
public. If a client makes such things, people should know about it and
not use such client.
What if the server rule checker has a bug? Is there any difference?
> All games have rule enforcement, and therefor all games need an
> impartial rule enforcer if there is more than one person involved.
Well, you have the serious games, where you really care who wins and if
this or that move is valid. But I guess more users will just want to
have a match. They will not like the need to hunt for a server component
(and usually the client itself does a poor job finding services without
user's assistance). They just want to click and play.
With a game with your friend, you do not have a referee if you play real
chess with him. So you do not that if play over internet. Personally I
played, while trying to implement my version of chess client, without
any rule checking (without even that in the client), and the game was
> >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
> 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?
Well, as I said, people may want to just play. Therefore I think there
should be a version that does not need the server part and the versions
should be similar enough so it can be done by one client implementation.
> 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.
Another nice feature could be to use existing MUC, so the people there
can just say "Hey, lets play this and this" and just continue living in
the same MUC with chat and everything.
> 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.
But you still needs the arbiter, which may be unreachable. What if you
want to play chess with your boss in the lunch pause and you have only
corporate server which is not connected to outer world? And no, you are
really not going to cheat on your boss ;-)
However, I fully agree there are games which need such way of handling.
I like this way (well, as I said, I would more like to see using
multicast component for multicasting, but still..). But I think the easy
games should be possible to play in an easy way.
I suggest having the move part and you send it in the iq stanza, then it
is broadcasted in the message stanza and so. If you play without the
"middle part", you just send the message with move. Or iq.
Or the arbiter could accept messages as well, so the client would just
send the moves to different location. (And you can return message errors
as well, which would be "cheat", and receiving the broadcast would mean
> 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.
Wait few minutes before opening this email. The temperature difference
could lead to vapour condensation.
Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards