[Standards-JIG] New version of chess game protocol

Mridul mridul at sun.com
Mon Oct 9 18:40:11 UTC 2006


Hi ,

  Please see inline.

Regards,
Mridul

Michal vorner Vaner wrote:
> On Fri, Oct 06, 2006 at 10:10:31PM +0100, Richard Dobson wrote:
>   
>>> And maybe to have list of known referee bots and play bots as well.
>>>       
>> Play bots quite possibly, as I will detail below I dont think referee 
>> bots are really needed, and even if they are there there is no real 
>> reason to expose them to the clients of the game server.
>>
>>     
>>>> 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).
>>>       
>> Why would you want that??, the above JIDs are for currently active game 
>> sessions.
>>     
>
> They do not look too much nice to me. And, when I want bots to live on
> the component, then one JID means bot and other means game.
>   

Which bot are you talking about ? Referee bot (which are not really 
needed - please see below) , or computer bots which can play a game ? 
(which could just be computer clients connected to the component just 
like normal users are).

> And, if I want to send messages in a game to:
> a) Only selected player
> b) Some set of players, lets say one team
> c) All of them
>
> Do I need to have more game JIDs, each for the team and other for all,
> or is it possible to do otherwise?
>   

You could leverage muc for this ... create private conference to 
represent each group and selectively publish a message based on the 
destination as specified by the client.
So for a single game jid you could have multiple muc's (if required !).
Or , you could use muc essentially as a backbone for gamesessions and 
leverage it to deal with even game routing and multicast packets - not 
just chat messages.


>   
>>> 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.
>>>       
>> As I will detail further below I dont think the referee bots are really 
>> necessary, but if you do want them then there is no real reason for the 
>> game server to expose them to the clients, they should be something 
>> internal to the implementation of the game server and automatically 
>> assigned when games are created without the clients even knowing they 
>> exist, otherwise it creates a completely unnecessary level of complexity.
>>
>>     
>>>> 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.
>>>       
>> That was the whole point, the muc room is just there for chat between 
>> the participants of the game nothing more, no game control messages go 
>> through it, they naturally go to the game component.
>>
>>     
>>> 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.
>>>       
>> Its an interesting idea but I think it makes things unnecessarily 
>> complex, its far better to have the game server understand the games 
>> itself, although if you really want a separate third party validating 
>> moves/game logic etc IMO that doesnt need to be part of this particular 
>> protocol and is more of an implementation issue as the clients of the 
>> game server shouldnt need to know that a third party is validating it 
>> all rather than the server itself, it should be completely transparent 
>> with the clients never knowing its even there.
>>
>>     
> Well, the idea about the referee bots was that:
> 1) If the client does not specify one, the component assigns you one.
> 2) If you want different referee, you can choose (if you want special
> rules, or you want a real person to be a referee)
>   

Each special rule would be a different game type : and the component 
will exhibit it as such in its disco items.
This removes the need for the client have some way to find out and 
specify which referee bot to use.
Like , borrowing Richard Dobson's example :
games.sun.com/board
games.sun.com/board/chess
games.sun.com/board/chess/variants/suicide
games.sun.com/board/chess/variants/frc
, etc.


> They are exposed for users so they can choose different one than the
> default or bring their own if they need it.
>
> And I do not think a game component which knows all the rules of all the
> games is a good idea. If you have 100 games with each 10 variants, you
> have quite big piece of code I would not like to debug personally. 

There are two aspects here -
the obvious one is that it just depends on how you author the component :-)
And also that you could just split the above such that you have a 
component "chess.board.games.sun.com" , etc
Secondly , existence of a million variants does not imply that the 
component supports all of them : it will exhibit the supported variants 
and thats all that it supports.
If no chess component on the server supports Kriegspiel variant of chess 
: then too bad , the client cant play it !

Kriegspiel is similar to blindfold chess btw (you can't see the 
opponent's pieces) : a very good reason why the state should be 
maintained at the server side and not at the clients :-)
One client cant validate the moves of the other since it does not know 
where the pieces are !

> If
> someone comes with a new variant, you need to replace the whole
> component. 

If the server/component wants to support it - then yes , else no.
But then this is just basic modularity requirement , and should not be 
too tough to design !
For the spaghetti coders out there , do one component - do it well , and 
keep it as such , the others can do more ambitious versions.

> Same comes if you find a bug in one game? Or when admin does
> not want some particular game on his server (let's say there is a game
> A, whose validation takes huge CPU time and so many people play it the
> server becomes unusable)? This way, users can start their own referees,
> if really forced to, but do not need to care (nor the clients do) under
> usual situation.
>   

It the admin does not want a game to start , I am not really sure 
whether you want this to be possible : admins still control the 
infrastructure and are accountable for it.
So being able to shutdown a component is a 'good thing'.



Regards,
Mridul



More information about the Standards mailing list