[Standards-JIG] New version of chess game protocol
Robert B Quattlebaum, Jr.
darco at deepdarc.com
Mon Oct 23 21:06:50 UTC 2006
On Oct 18, 2006, at 1:31 PM, Richard Dobson wrote:
> Robert B Quattlebaum, Jr. wrote:
>> 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.
> A game validator/management component is not needed for all games,
> but it is required for others, offhand games like monopoly,
> scrabble, poker, battleships among im sure lots of others,
> basically games where the clients do not know the full state of the
> game (i.e. stuff like the cards in a hand, letter tiles each player
> has), also where a single entity needs to provide services for the
> game like dealing cards, dealing letter tiles (for scrabble), these
> are things were the server needs to maintain what cards are unused
> from a pack / letter tiles. These are things where you need a game
> server component, and they are things that dont cleanly map onto
> MUC due to things like all players shouldnt always being given
> certain parts of the game state.
> If you look at my idea of having the game server that directly
> deals with the game moves/turns, which also inturn (like the
> workgroups XEP) uses MUC rooms for things like in-game chat, and
> any broadcasts to all users (i.e. game state that all users should
> see), that is a far cleaner solution rather than trying to hack
> this all completely on top of MUC even where certain aspects do not
> really fit in with it.
Ok, that sounds perfectly reasonable, but I would say that makes two
classes of games: those which need a 'referee' (something to keep
track of the game state independent of the players) and those which
don't. 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.
>> 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.
> I also refer you to 2.2 (Keep clients simple), using MUC as is
> requires clients to implement the validity checking rather than
> just using a server component that can do it.
I'm pretty sure that this is in reference to protocol complexity. For
example, the SIP protocol requires very complex client
implementations simply to be able to communicate, whereas jabber puts
most of the complexity server-side. And this is a good thing.
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
Jabber: darco at deepdarc.com
eMail: darco at deepdarc.com
More information about the Standards