[Standards-JIG] New version of chess game protocol

Michal vorner Vaner michal.vaner at kdemail.net
Tue Oct 10 06:53:35 UTC 2006

On Mon, Oct 09, 2006 at 11:54:11PM +0530, Mridul wrote:
> 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.

But you have hard time when you want to split it off entirely into
different program in completely other language. In that case, you could
of course use pipe or network socket, but then you are with the referee
bot. And by choosing rules, you would choose the referee bot, you just
choose it by some string, I by different one which is actually a JID. If
I want to specify a way the referee bot may be on a different computer
and communicate trough xmpp, I would say it is only a bonus. And I do
not see reason why you could not have the referees bundled and by
choosing the JID, you just say I want this kind of rules.

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

There are games where cheating is just too obvious so anyone realises.
What would the game component do, if you cheat? Say you lost? What would
real person do if other is cheating? Say "Hay, what do you thing you are
doing?" - I just say I see reasons why some people would like to play
without the middle part, while some may need it.

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

Yes, they might be. But there might be some built-in ones as well, no?
Well, they would look like the same.

Why not allow "I'm referee, if you need one. And I'm a bot too." As I
said, under normal circumstances, you would not need to care about them
at all, they would be assigned to you automatically. You just could do
it, and I do not see reason why someone should deny you the right to
choose your referee.

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

Yes, I just said it the other way - choosing the referee selects you the
game. Or the bot being selected automatically, if you say "Hay, I want
to start chess game". "OK, all ready, you may start, and if you are
interested, this one is referee."

> 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 ?

No, I say he may be involved, not should.

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

But as I said, you have many drawbacks here with MUC. And if someone
writes the game component, adding the broadcasting is not much a problem
anyway (and he could use the multicast component for it, and the game
component would depend on it so admins would just have to install both).

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

First, I do not much see reason why you would have to disco it for
supported games. If the game component knew nothing about the games, any
game would be supported. The worst thing which could happen would be
there is no referee for that game so you would get a dummy one which
allows anything (with nice fat warning you do not have referee), but you
could play (if the game would allow it) without the referee - as a
fallback. Or you could say "O, crap, there was referee on other server,
I will borrow it." or "Well, there was a referee soft on the net with
the game as well, I will just start my own, damn with the server."

And as I said, he shouldn't, he could. You can just write client that
does not allow you to care as well, just ignore referee bot and get some
from the server - that would be the normal case. But the world is not
made of normal cases only.

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

You can't have everything... where would you put it?
    -- Steven Wright

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20061010/ac5cc754/attachment.sig>

More information about the Standards mailing list