[Standards-JIG] New version of chess game protocol

Michal vorner Vaner michal.vaner at kdemail.net
Thu Oct 5 20:09:55 UTC 2006


On Fri, Oct 06, 2006 at 12:18:16AM +0530, Mridul wrote:
> 
> Hi,
> 
>  Please see inline.
> 
> Mridul
> 
> Michal vorner Vaner wrote:
> >On Tue, Oct 03, 2006 at 04:36:44AM +0530, Mridul wrote:
> >  
> >>Michal vorner Vaner wrote:
> >>    
> >>>Hello,
> >>>there is a new version of the chess game protocol in the inbox.
> >>>
> >>>http://www.jabber.org/jeps/inbox/chess.html
> >>>
> >>>If you want to have a look, I would be delighted to hear opinions.
> >>>
> >>>Thank you
> >>>
> >>> 
> >>>      
> >>Hi,
> >>
> >> Some thoughts on this proto-jep , and also on gamesessions (in the 
> >>context of this proposal).
> >>
> >>gamesessions :
> >>
> >>1) Who creates the gid ?
> >>If it is the responsibility of the client , then how can it be expected 
> >>to be unique ?
> >>From my understanding , gid will identify a game to which others could 
> >>potentially connect - so shouldn't this not be assigned by the server ?
> >>    
> >
> >It is created by the one who first needs to put one there.
> >
> >Well, it is created by the client. But as mentioned in the JEP (I hope I
> >did mention it somewhere), it SHOULD contain full JID of the creator and
> >a timestamp or some kind of hash of this, so it will not happen someone
> >just asks you again with the same ID. The client could then mismatch
> >the 2 games.
> >  
> 
> Section 5 talks about game list as though it is centrally hosted by some 
> server/component : in which case uniqueness can be gaurenteed only at 
> the server side.

Every entity capable of playing any game has a game list, claiming which
games it supports and, if it wishes, what games it plays right now. It
may be a server side client, multibot, whatever, but it may as well be a
client.

No, it is not like if I want to play a game, I put it somewhere on
server. I have my own list that says I can play the game and I look to
others' lists to see if someone else can play it as well.

> That is the ambigous part of the spec : it is not very clear as to what 
> needs to be done by a client , what is to be done at the server side.

There is actually no server side as such. There may be some kind of game
server, game boss, but it does not have to be on XMPP server, it is
server from the point of game - it holds the rules.

> Some of the part's are mentioned as client side in one instance and for 
> a slightly different case , gets pushed to the server : spectating is an 
> example of this.

This all is client.

> It might make sense to clearly demarcate both.
> In the context of spectating , I have more comments below.
> 
> >  
> >>2) "One to one game, with spectators" - In the context of chess games , 
> >>which is essentially falling under this category :
> >>
> >>Are the client's supposed to take care of it ? 
> >>    
> >
> >Under "normal" match, you usually do not want people to watch, so you do
> >not need it. And even if you want some friend of you to watch, you have
> >this mirroring better (it seems to me) than negotiating for a server
> >component, which actually does not exist, you have to discover it, which
> >is error-prone (see actual state of file transfer proxies).
> >  
> 
> Is it the intention that a single game gets treated seperately for one 
> to one , and same game gets treated differently when there are > 2 
> participants or spectators also involved ?

Well, you need to send it to more people, so it actually is different.
It is why there are the game types.

> It is logically possible - consider the analogy of a one to one chat 
> becoming a muc when there are > 2 participants.
> If this is the intention , then it is fine (though this is not mentioned 
> in the spec) - when I was going through it, at different spots , I felt 
> that it should be handled differently.

In the spec, a many players game just "envolves" from the 1-1 game.
Maybe it is not much the XMPP way, as I see the reactions.

> 
> >  
> >>Or do the spectators 
> >>connect to the component/server and view a game ?
> >>It would be heavy if the client has to manage spectating - imagine 
> >>kasparov vs anand game :-)
> >>    
> >
> >Hm, it would need some kind of "man-in-the-middle" component. Maybe I
> >should not it there. It goes to TODO.
> >  
> 
> Yep , two client's managing a 1 to 1 game is fine as long as it will 
> remain 1 to 1.
> Else , we need a muc style component in the middle which manages things.
> Actually even a 1 to 1 game has issues of rule validation , timing , etc 
> - which would typically require some sort of server side support.

You can not build a server side component for any imaginable game to
check rules. If it works with chess, alright, but I want to see you
hunting for a server side component and for every crazy game someone
thinks of and server admins are unwilling tu put there.

> >  
> >>Also , how about acl's for this ? (tutor session/class similar to muc , 
> >>etc)
> >>Actually , I did not see anything about how a client would initiate a 
> >>spectating session for a game in the proposal.
> >>    
> >
> >There is whole section 8 about creating spectator session.
> >  
> 
> I was talking w.r.t gamesessions here.
> Btw , this would be the first spec I have seen (unless I am forgetting 
> something) , which is expecting the client to do routing of messages :-)

Hm, yes, seems like the resending is not much a good idea, the web-type
game and the 1-1 with spectators. But I would like at last to allow the
server-thingie (that something MUC-like) to have a node part of JID, so
server does not need to have a DNS name for every game server -> so you
could have chess at games.server and battleships at games.server.
> >  
> >>Typically , spectating involves side chatter : some of which is also 
> >>visible to the players , and some of which are not : makes all the more 
> >>sense to move it out of the control of the client.
> >>    
> >
> >But where?
> >  
> 
> To the server side ofcourse - where else !
> The general philosophy , from what I see , in xmpp is to have a tradeoff 
> as to make the clients lighter ... sometimes at the cost of making the 
> servers more 'heavy'.

I do not have problem with heavy server, but with the fact that servers
will implement MUC, but will not implement every crazy game. So it needs
to be something general for all the games (so somehow the 'routing
rules' of the game can be uploaded there somehow - to tell it "this is
for everyone, this is for my team only, and keep this for later")
> >>chess :
> >>
> >>1) Time related attributes.
> >>There are a whole series of timing considerations in chess games : sec 
> >>per move , fischer time control , primary/secondary/etc time controls of 
> >>time per x moves , etc : and different UI's support different subsets of 
> >>these.
> >>    
> >
> >Hm, I must admit I'm not really good in time and chess. I play chess
> >sometimes and I wanted jabber-based client, so I started writing one.
> >And when describing the protocol, I added some time measuring. Maybe I
> >will look at that.
> >
> >  
> >>2) There are variations of chess where more than 2 players play - this 
> >>is not handled by the spec I believe (refer to 3).
> >>
> >>3) There are a large number of variants of chess - refer here for a 
> >>small list : http://www.chessclub.com/helpcenter/tips/wild.html
> >>There should be some way to negotiate this.
> >>    
> >
> >Well, these is not chess as is, you just can expect normal clients to
> >support this. So if you create special client for lets say 3-people
> >chess, you need to define new protocol, which may reuse this one as the
> >core and extend it.
> >  
> 
> The way it stands , it is not really possible to extend the jep to 
> support other varients.
> Like for example , bughouse (4 player).
> Also , the spec makes assumptions about the game itself - and expects 
> well behaved clients from a chess point of view.
> I have seen a lot of such efforts going down when there was inadequate 
> server side support on rule validation ... and in an aborted chess 
> server effort that I did with a friend long time back, it became very 
> obvious that you totally need server side support on rule validation.
> Rule validation , time management and gamestate management are the most 
> critical aspects - rest are just features.
> Need not be built into the xmpp server - could be an external server 
> side component.

As said, you just cant have a sever component that understands each of
possible games. There are too many games.

And it should be possible to either allow the clients stand each other
or make one of them "the boss" - or name the boss someone else, if no
one of them is trusted, like in real chess, you may have a referee, but
many games are just for fun and you do not need one, so it is waste of
time looking for one.
> >  
> >>4) Considering that you already have (3) above , I think the ruleset 
> >>attribute could be modified for this - the current rules mentioned are 
> >>not really very useful imo ...
> >>
> >>5) There is a standard way to represent chess positions : FEN 
> >>(http://en.wikipedia.org/wiki/Forsyth-Edwards_Notation) for normal chess 
> >>, X-FEN(http://en.wikipedia.org/wiki/X-FEN) and shredder FEN for fischer 
> >>random chess - not sure about other variants.
> >>Similarly , for communicating games , there is a PGN standard format.
> >>It would make sense not to invent another format - all UI's I know 
> >>support FEN already.
> >>Btw , the 'piece' attribute could be considered broken from a chess 
> >>point of view actually.
> >>    
> >
> >Will have a look there.
> >
> >  
> >>6) Maybe I did not get this point ... but who manages a game ?
> >>The gamesessions seems to indicate that 1 to 1 games would be managed by 
> >>the players themselves ... in which case , time synchronization , 
> >>checking of rules , etc have to be managed by the client ?
> >>If not , then how are the errors , timeouts , etc to be sent ?
> >>    
> >
> >It is done by the clients. If one client "catches" the other while
> >cheating (or playing over time), it accuses the other one of it and
> >terminates.
> >  
> 
> Most cases , this would not work - you would end up with cases where 
> both sides claim a win on time.
> There have been cases of buggy clients claiming illegal move (one after 
> other - especially in varients) when things were valid , vice versa , etc.
> The number of combinations here are hairy , and frankly I am not really 
> sure of the full intent of the spec.
> 
> If the intention is that we allows users to play a game of chess from 
> their client using xmpp as the transport , then it becomes important 
> that we end up defining the spec of a server side component.

Yes, it seems there is need to have a possibility to have a referee (or
have it plugged into one of the sides, or have "dummy" referee, that
does nothing). That will need a remake as it seems.

> You query the chess component , 'seek' a game or initiate a match 
> against a specific user , have the component manage your games (time , 
> game state , etc) , etc - becomes something akin to muc in some respects.
> If the idea is to allow any arbitrary clients to initiate a one to one 
> game (similar to 1-1 chat) and restrict ourselves to that : then it is 
> much more simpler , but severely limited.

I will try to find a way to switch between the MUC and MUCless version
(well, MUC-like, anyway)

> >  
> >>7) Might be useful to add a move number to gameflow. Also , it does not 
> >>consider extra semantics necessary for (3) above ...
> >>    
> >
> >Can't you just count in your client? No-one sends how many messages did
> >you sent already with chat, do you?
> >  
> 
> Hmm , in chat , out of order delivery , though rare when it does happen 
> , is not a severe error.

XMPP guarantees this does not happen, the messages between 2 entities
must get there in the order how they were sent. And if you want to build
on top of something and you expect that thing to be broken, it is much
harder to build anything at all.

> Btw , you need not start a game from the begining of an opening position 
> - but could be an adjourned game , or a game continuing from a well 
> known position - or if you allow examining moves , you will have a 
> series of make/unmake moves (by multiple people).
> These are just real world problems in writing a chess server ...
> 
> >  
> >>8) I am not very sure of the client's managing spectating ... might make 
> >>more sense for the server or external component to manage this (I 
> >>mention this under gamesessions actually).
> >>    
> >
> >Yes, I will try to think about the game component, which might be as
> >well used for the middle spectator. But I want simple (1 to 1) games to
> >be possible to play without any server support.
> >
> >  
> >>9) Other ideas which are currently available in most online chess server :
> >>a) Adjournment of game ?
> >>b) Retrieving a move list to continue a previously adjourned game
> >>c) Browsing game history.
> >>    
> >
> >No need for protocol for this one, if you need a chat history you keep
> >it. If you need game history, you keep it.
> >  
> 
> Agreed about game history - could be an additional feature for specific 
> implementations.
> Adjourned games are typically kept at the server - else both clients 
> could end up tampering with the games and making it go out of sync.

Saving and resuming (if I understand what you mean by adjourned right)
is not designed yet.

> 
> >  
> >>d) Examine a game (could have multiple users modifying the board).
> >>
> >>    
> >Well, I would not like to overcomplicate it, I want to be able to make a
> >simple client that allows 'only' to play chess.
> >  
> 
> Just as an aside : examining games is the logical extension of playing 
> chess for even moderately serious chess players.
> You lose a game , you examine it with friends/master's to understand 
> your game better.
> 
> Ofcourse , like I mention above - either we can define a more complete 
> protocol or limit it to a simple case.

Would be nice if somehow could manage to make a protocol that would be
simple in the simple cases and became more complicated in more
complicated situations only. But it is hard to do.

> I have seen a lot of client protocol and also server side efforts come 
> to a stop in the chess world just cos it is not supporting essential and 
> basic requirements.
> People tend to be very serious about the games (you should check out one 
> of those online multicasts in action :-) ) , and designing something 
> which makes assumptions about the 'goodwill' of the participants maynot 
> become widely adopted (the cheating will drive people away).

Well, with chess, cheating is really easily discovered and you can do
whatever you would do in real chess game if the opponent would cheat,
except maybe throwing the chessboard at him.

> If we do define a spec in this space for xmpp , when game programmers 
> try to use xmpp as a middleware for online servers (yep , some are 
> seriously considering this already) , it should not lead them to 
> insecure implementations 'cos of our simplifying assumptions : just as 
> it would be good if they did use these xep's for their requirements.
> 
> Regards,
> Mridul
> 
> >>If I am not wrong , the protocol's of most of the online chess servers 
> >>are public (a search showed me icc format : 
> >>ftp://ftp.chessclub.com/pub/icc/formats/formats.txt , I am sure fics , 
> >>others will also have their formats out there somewhere)... so it would 
> >>help us to take a look at what they support and what they allow.
> >>We may not want to model all of it , but should be reasonably flexible 
> >>to allow the jep to be used for supporting these as required.
> >>
> >>Wanted to comment only about the time thingy ... but became a much 
> >>bigger mail than I expected :-)
> >>
> >>Regards,
> >>Mridul
> >>
> >>
> >>    
> >
> >  
> 
If you feel you have any specific ideas how to do it, please try to
modify the xep directly.

-- 
grep me no patterns and I'll tell you no lines.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20061005/9aae6ab1/attachment.sig>


More information about the Standards mailing list