[Standards-JIG] New version of chess game protocol
Richard Dobson
richard at dobson-i.net
Fri Oct 6 16:10:31 CDT 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
sessions.
> 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.
Richard
More information about the Standards-JIG
mailing list