[Standards-JIG] New version of chess game protocol

[Mridul]

Hi,

  Please see inline.

Regards,
Mridul

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

This is along the lines of what I was envisioning too.
A disco info of the top level component would return some identity of 
say 'games' or similar.
And you could send an items followed by disco info on each returned value.
The type could be which game it is or along those lines.
The gamesessions jep could define what a game component should look like 
in general : the allowed 'methods' on it , etc.
A particular game would implement the game specific extension (the game 
specific extension would define what that game should return as its 
identity).
In this way , if we do need a component only for the purpose of say 
chess - or integrate into 'gamesessions collection' component : it will 
not matter.
The collection is always expected to be dereferenced to list all the 
games within , while a specific game jep component will have a different 
type ...

You could have a single component implementing different games which it 
returns in its items (or different components : though I dont see what 
is so tough in doing what is shown above).
Game creation , state management , adjournment , etc would be controlled 
by the specific component's extension : and would be defined in its own 
jep (in case there are specifics).
A simple example would be , send a disco items on 
"games.jabber.org/board/chess" with some filter in the node and you are 
returned with all the accessible games which are in progress which 
matches the criterion in node. You could have it muc style : that is 
game@<component>/[user_as_resource] or just have it as game@<component>. 
Depends on how we design it I guess ...


>
> 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
>
> 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. 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) 
> 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.

For the purpose of chat , banter , taunts , kibitz , whisper , etc - we 
could just leverage muc for that ... in which case , it might make sense 
for gamesessions to define how/when a game will also have a muc 
associated with it , how a user can request for it , etc ...
Popular games have huge number of concurrent observers : like the recent 
Kramnik vs Topalov match when it gets relayed online : you have more 
than 10k people simultaneously viewing and commenting about it in some 
of the online chess servers : makes sense to leverage a defined spec for 
this.


Regards,
Mridul

>
> Richard
>
>