[Standards-JIG] New version of chess game protocol
mridul at sun.com
Mon Oct 9 18:04:50 UTC 2006
Please see inline.
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:
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
In this way , if we do need a component only for the purpose of say
chess - or integrate into 'gamesessions collection' component : it will
The collection is always expected to be dereferenced to list all the
games within , while a specific game jep component will have a different
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
> 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
More information about the Standards