[Standards-JIG] New version of chess game protocol

[Mridul]

Michal vorner Vaner wrote:
> On Fri, Oct 06, 2006 at 06:42:12AM +0530, Mridul wrote:
>   
>> 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 ?
>>     
>
> I mean any particular game. I meant if you want to have a component that
> understands any game, it is hard to keep it updated enough to support
> all games.
>
>   

I am not really sure why this should be so ?
You can take two approaches to this - either have a top level 
gamesessions component which is like a collection of individual game jep 
implementations , or just have each game as a component by itself.
The specs would need to define the disco req/resp and register it with 
the xmpp registerar ... that should be enough.
About whether it is 'easy' or 'difficult' is just an implementation 
detail , and should not bother us at this time unless it is obviously 
going to create trouble : and I dont think so.
A component supports say 3 varients of chess , pool , battleship : it 
will expose these , you will modify it only if you want to add more game 
support - why else would you do it ?
The actual implementation could be logically seperate from the component 
, or bundled into it : does not matter , all impl details.

>> 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.
>>     
>
> Agreed.
>
>   
>> 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.
>>     
>
> Seems possible. That will need that central component written, however.
>   

Yes, it will.
The more I think about it , the less I see an oppurtunatety for any game 
to happen without basic validation - atleast at the minimum , we will 
need sanity check of the game rules.
Whether users configure the game to start with this or not : that is up 
to how you create the game - but that would be an option , not the 
normal behaviour.
You just need to play online for a week to realise the amount of 
cheating that kids indulge in nowadays :-)

>   
>> 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
>>
>>     
>
> On Fri, Oct 06, 2006 at 10:14:48AM +0100, Richard Dobson wrote:
>   
>> I think for the server component mode of protocol this it makes the most 
>> sense for it to be structured in the following way:
>>
>> You have a central  game server component which people can browse 
>> through using disco (similar to the way yahoo games works), where you 
>> would have multiple levels like the following:
>>
>> games.jabber.org/board
>> games.jabber.org/board/chess
>> games.jabber.org/board/checkers
>> games.jabber.org/board/backgammon
>> games.jabber.org/card
>> games.jabber.org/card/poker
>> games.jabber.org/puzzle
>> games.jabber.org/word
>>
>>     
>
> And maybe to have list of known referee bots and play bots as well.
>   

We really dont need to mix both.
A play bot would be just another client.
You would just have it connect to the component and allow itself to be 
registered as "open for a game , I am a bot".
Most of the online servers for a lot of games have this sort of 
behaviour already - and the actual bot is not part of the server : but a 
remote client which connects to the server just like any other user.

>   
>> When you get to the level in the hierarchy of a particular game for 
>> example /board/chess you would get a list (in disco) of the games 
>> currently in progress e.g.
>>
>> chess4433 at games.jabber.org
>> chess33422 at games.jabber.org
>> chess34 at games.jabber.org
>> chess45332 at games.jabber.org
>>     
>
> Well, maybe, but maybe just different kind of addressing, since you need
> to address somehow sub-group of the game as well (like only my team).
>   

Yes , you are right.
But this is part of the configuration ... I mean ,for any game , you 
have to define who my team is (degenrate : team of 1) , who my opponent 
is , and who are the viewers.
Whether you can move from one to another depends on the game : not 
possible for chess for example , but in say counterstrike a spectator 
can join the game or a player can go back to being spectator at any time 
(provided the server config for that map allows it).
The rest of the communication just becomes immediately who I am 
addressing the messages to.
team 1 ,team 2 , ... team n , viewers only , all.

>   
>> If a client understands the gaming protocol once it gets down to the 
>> /board/chess level it will examine the disco features and present a 
>> "Create Game" button in the client interface so people can start new games.
>>
>> The game server component (games.jabber.org) will manage the games and 
>> validate any turns people make and sending out the result of that turn 
>> to all the players which the players will use to update their copy of 
>> the board etc so they dont have to worry about checking against the 
>> rules etc. 
>>     
>
> I would suggest piping this trough some kind of referee so the component
> itself does not need to understand all the games (the referee may of
> course be part of the component, but it may be a bot on the server,
> somewhere completely elsewhere or human as well) and the component would
> know a list of public referees.
>   

I am not very sure of this ... this would be an implementation detail of 
the component.
Whether it allows discovery of 'game parser bots' , or whether it 
already has a pre-built library of supported games is up to the 
component author to design and implement.
 From a user's point of view - you would.
a) connect to component.
b) start a game with an opponent (could even be a game involving a 
single player)
c) manage the game.
d) interact with the game/opponent (which is where rule and state 
validation comes in)
e) save , abort , exit , etc state management.

The choosing of the game , chooses the referee for you.
If I want to play standard chess - I dont care of the component uses a 
'botS at domain' to validate my game or not.
That is between the component and the refree bot : why should the end 
user be involved ?
We will just need to allow for the component to expose a set of 
supported games , and the user to select one from this list.
Rest would be game specific and will need to be documented in that games 
jep.

> Anyone could choose a referee or leave it on the server to choose one
> for the game, or choose none (or dummy one, which would allow anything).
>
> However, a game with referee would be only if not simple 1<->1, as a
> optional plugin of the component and resending process.
>
>   
>> Similar to how the workgroups protocol works if a chat room 
>> is needed in a game the game server component will create the room and 
>> give its address to all the participants (i.e. chess34 at muc.jabber.org) 
>>     
>
> Well, if you have the game component, you can do the resending from
> there, since (as I said before), muc is not well suited for games, it
> can do only messages, it alters presence and is for text chats.
>   

I dont really agree with muc is only for text - you can consider it as a 
a way to multicast messages based on some routing rules.
Chat is one of the usecases for it - you can as well come up with others 
too.

>   
>> so they can join if they want to, this seems far more inline with 
>> xmpp/jabber to me as its using the various components (i.e. MUC) for the 
>> purpose it was designed for rather than trying to layer stuff like the 
>> sending of game moves etc ontop of it which makes things far more 
>> complicated than above as you need to have one of the people in the room 
>> acting as the master/validator of any moves which just seems rather 
>> messy to me, it seems far better to me to just move all the complexity 
>> to the server properly using a proper component designed for the job.
>>
>>     
> Yes, but I want to have the game components to know nothing of each
> individual game and pick the referee, game master, whatever, from
> different JIDs (which may be on the component directly, of course).
>   

Nope , you will need to pick you game , and maybe your opponent (in case 
you know it - like send a 'join my game invite') or hang around in the 
'lobby' waiting for a suitable opponent(s) (this would a simple case of 
advertising to the component that I am ready to play game 'x' with 
constraints 'y' : if there are suitable opponents : match me with them).
In either case , user picks the game from the game component (which is 
easily obtained through disco ) - not the game master , not the referee 
, etc : those are details handled by the game component and totally 
hidden from the client (why should be care anyway !)

> I will describe this idea once I get home, I'm in hurry now.
>
>