[Standards-JIG] New version of chess game protocol

Michal vorner Vaner michal.vaner at kdemail.net
Mon Oct 9 11:29:27 UTC 2006

On Mon, Oct 09, 2006 at 09:25:22AM +0100, Richard Dobson wrote:
> >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.
> >  
> You shouldnt be trying to use the JID itself to work out if it is a game 
> or a bot, you should be using disco for that, so I doesnt matter what 
> the JID itself looks like.
> >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?
> >  
> a) you would send the message to them
> b) as teams are something that are only going to be appropriate to 
> certain types of game and not all their are two ways to implement it, 
> the game creates extra MUC rooms for each team, or you simply send the 
> message to each team member individually, you dont need any extra JIDs 
> on the game server component.

Which seems to be a bad situation, either way.

> c) you would use the games MUC room
> >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)
> >
> >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. If
> >someone comes with a new variant, you need to replace the whole
> >component. 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.
> Sorry but that does not convince me at all, it need not be complex to 
> have different games and variants in a server component if its 
> programmed and architected correctly, each game can easily just be an 
> addon to the core game component that in and of itself need not be 
> complicated, also each component can easily have a set of config files 
> that contain information about each variant of the game it supports and 
> both the addon's and the config files can easily be added and removed at 
> runtime without the entire server needing be be restarted, so you dont 
> need to replace the whole component as you state, it need not be complex 
> to debug as you would debug each game individually, if you find a but in 
> a game you just replace that particular addon with the bugfixed copy, 
> when an admin doesnt want a paricular game or variant they simply dont 
> deploy that addon or config file, there is no need to add all the 
> complexity associated with your referee bots if these are your reasons 
> for them.
OK, you may have what I want hidden from anyone except admin. However,
it means each game addon must be written for one particular game
component, if you have more of them, you have to duplicate work.

Another thing is, game developer must run his own server, in my way he
may specify a connected (not-listed) referee bot and debug it, see what
it does a lot simpler.

And, you probably want to have the possibility to choose (and list) AI
bots, you at last need to choose if you play with easy one or difficult
one. You may need to choose some kind of game overlord (like master of
the cave in dungeons and dragons). You may want to choose the referee as
well, in these situations:
*) you do not trust the built-in one.
*) the game component does not know this particular game - you can say I
have a referee, this is game overlord, so the game is complete and you
do not have to care.
*) You want a real person to be referee.

If you as a player or you as a client developer do not want to support
choosing referee, you just can ignore them, you get one assigned (the
default one) by the game component.

The fact that the referee has its own JID does not mean it can not be
plugin/part of the game component, it may just pretend to be external.

And the thing you get the possibility to write a universal referee (that
which works with any game component implementation).

The complete idea is like this:
(Any parts may be one part in real implementation)

The game component itself - it does not know anything about any games,
it however can do clever things like
*) Keeping list of known bots (whatever their purpose is, referee, AI,
*) Keep list of play-starving users (those who just want to play with
anyone, may be interconnected with MUC room)
*) Keep list of ongoing games (publish them only if they are public, of
*) Do routing for each game (with possibility to send to all, one,
preset group/team)
*) Remember game state and/or (and send it to newly connected
*) Save/load games
*) Maybe fork or merge games (I do not know if this may be of any use)
*) Couple with MUC rooms (the way the game flows trough the game
component and game chat is trough MUC is nice idea)

It would have disco structure something like this:
 |  +-AI Bots
 |  |  +-Chess easy bot
 |  |  +-Chess hard bot
 |  |  +-Other game bot
 |  +-Referee bots
 |  |  +-Chess referee(Default for chess)
 |  |  +-Dummy referee - allows anything
 |  +-Overlord bots
 +-Available players
 |  +-Chess easy bot
 |  +-Chess hard bot
 |  +-Other game bot
 |  +-Some real player willing to play
 |  +-Other real player
 |  +-Chess referee
 |  +-Dummy referee
 |  +-Some real person wishing to referee - unlikely
 |  +-Real person wishing to be an overlord
 +-Known game types
 |  +-Chess
 |     +-Chess easy bot
 |     +-Chess hard bot
 |     +-Chess referee
 |     +-One chess match
 |     |  +-Chess referee
 |     |  +-One player
 |     |  +-Other player
 |     |  +-Some spectator
 |     +-Game without published person list
    |  +-One chess match
    |  |  +-Chess referee
    |  |  +-One player
    |  |  +-Other player
    |  |  +-Some spectator
    |  +-Game without published person list
    +-Other game

Some of the information is available on more than one place - chess AI
bot is under bots as well as under chess as under players.

Then the bots, what AI bots does is simple, it pretends to be a player
and if invited to any game (any game it can play), it accepts and

The referee bots - all the moves/sends/events whatever goes first there
and it can allow them/discard them/modify them and do whatever it likes
(including kicking players) before the event gets to be routed. Dummy
referee bot is one that just allows any moves.

Overlord bot (which makes no sense in most cases) is something between
referee and player. It sees all the moves/etc, but it acts after as
normal player. It is kind of admin of the game (moderator in muc).

How a game session could look like:
*) 1-1: players meet somehow and want to play, without any spectators or
referees, just one invites other and they play without any middle thing.

*) Any more complicated situation: One player - the founder - informs
the game component he wants to create a game, optionally may specify
overlord and referee (may be himself), may specify who is allowed to
connect (anyone, only invited, spectators..) and set password. He may
specify initial state, ask for saved state (saved by him) and invite

If nothing of this is specified, just a default game is created. Rule
variants may be negotiated with the referee (no matter how assigned one)
or choose other referee.

It allows moving from 1-1 to GC managed game.

It seems to me it is possible to easy up for new games development by
little complication of the central component, which may be ignored on
the client side. On the other side, it allows quite a lot of flexibility
and allows users to create their own games and play them without any
need of server admin to set anything (however, he would need to list the
bots in the disco, if they should be made public).

I hope it makes some sense.

When eating an elephant take one bite at a time.
		-- Gen. C. Abrams

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/20061009/d14e171b/attachment.sig>

More information about the Standards mailing list