[Standards-JIG] New version of chess game protocol

Mridul mridul at sun.com
Fri Oct 6 01:12:12 UTC 2006


Hi,

  Just a couple of things :

1)  Just to clarify about xmpp - please refer to section 10 of 3920
There is inorder processing mandated - not delivery

2) I dont really understand the comment about 'ever crazy game' - you 
mean variants of chess ? or you mean different games in general ?
If different games - then it is pretty simple , if there is a component 
exhibiting that game , and we have spec for that game - it works !
If you mean different variants - then I think you already had this 
solved using your ruleset right ?
We just need to use commonly accepted values for that attribute : normal 
(wild0) , fischerrandom , crazyhouse , bughouse , shatranj , etc or 
maybe their corresponding wild'xx' version.
Either case , we could have the component exhibiting a list of supported 
variants , and clients can use only those.
The spec will not need to define any of this : it would just allow 
clients to negotiate what varient (if supported by the component).

The gamesessions protocol could define the semantics of what the 
component would do , behave , interact , manage sessions , etc.
The chess jep would describe the specifics for chess (like use fen for 
encoding positions , pgn for transfering games , what timing controls , 
rules , etc).
If I have snooker or billards tommorrow , there will be a jep for that 
which defines that game ...
The idea is , gamesessions could be that we define a infrastructure for 
a generic gameserver to be exposed through xmpp.
The specific protocol semantics would be mandated for the particular 
game related jep.

3) If you end up defining a new set of data format , protocol , 
extension , rules , etc which are different as compared to using what is 
already in existance (in this case , chess programming world) , we will 
not be able to drive adoption.

4) That being said , I really the like the idea of modelling something 
along the lines of a 1-1 chat which could get 'upgraded' to a heavy 
session similar to 1-1chat <-> muc.

5) We might want to support multiple people interacting on the same 
board - helps in examining a game , tutor sessions and variants which 
really do require more than 2 people.

In the above , I keep referring to a 'component' - it could be replaced 
by something better/analogous , just wanted to name it something.
My 2 cents.

Regards,
Mridul

Michal vorner Vaner wrote:
> 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.
>
>   




More information about the Standards mailing list