[Standards-JIG] New version of chess game protocol
Michal vorner Vaner
michal.vaner at kdemail.net
Fri Oct 6 15:54:23 UTC 2006
On Fri, Oct 06, 2006 at 06:42:12AM +0530, Mridul wrote:
> 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
> 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.
Seems possible. That will need that central component written, however.
> 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.
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:
And maybe to have list of known referee bots and play bots as well.
> 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).
> 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.
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.
> 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).
I will describe this idea once I get home, I'm in hurry now.
Please stay calm. There is no use both of us being hysterical.
Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards