[Standards-JIG] New version of chess game protocol

Richard Dobson richard at dobson-i.net
Fri Oct 6 21:10:31 UTC 2006

> 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 

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


More information about the Standards mailing list