[Standards-JIG] New version of chess game protocol

Michal vorner Vaner michal.vaner at kdemail.net
Mon Oct 9 20:42:01 UTC 2006

On Mon, Oct 09, 2006 at 03:32:32PM +0100, Richard Dobson wrote:
> >>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.
> >  
> Why is it bad to setup per team MUC rooms for chatting between members 
> of a particular team? Can you please explain anything you state like 
> this otherwise its a useless comment as it gets us nowhere.

Sorry, I thought this was not about MUC for chat but about the old idea
of using MUC for routing game moves etc. For team chat, it is OK.

> >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.
> >  
> No it doesn't at all, you can easily if wanted create a common framework 
> for game add-ons that all game server components could implement, it 
> could easily be done in something like Python or some other scripting 
> language, its just an implementation issue and is entirely possible.

Which does not mean everyone will and you are limited to python code in
that case. What if someone finds it better to write the rules in
fortran? Is it impossible for him?

And, if a bug shoots the thing down, will it take the whole component?

> >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.
> >  
> Why does the game developer need to run their own server? They can just 
> distribute their game add-on to anyone who wants to support their game, 
> with your solution the game developer needs to host their own referee 
> bot, or again just distribute it to their users to host, im not sure 
> what you are trying to get at here, its pretty much the same difference 
> as far as I can see.

Maybe because he needs to test? Did you try debugging something on
remote computer, each time upload it, breaking it up and so on? Aside
the fact that such user needs to have enough privileges.

> >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.
> >  
> If you don't trust the server then you shouldn't be using it in the 
> first place.

You may trust it enough to deliver some piece of data it does not
understand, but you may distrust it with its clever enough mind to judge
some more complex game.

> >*) 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.
> >  
> I think this is the crux of the issue here, you don't think the server 
> should know about the games its hosting, whereas I think they should 
> otherwise it introduces lots of unnecessary complexity as well as 
> various other issues like:

I say it is impossible to have one component that understands any game
anyone ever thinks of.

> 1) latency (there will be a delay while the game traffic is being routed 
> via the referee)

Unless the "core" games - the ones which would be supported internally
are internal.

> 2) unreliability (what if you are using an external referee and it gets 
> disconnected, or what if some of the stanzas get lost in between)
> 3) complexity (needing to route all traffic via a referee bot, and if 
> you want to implement it in the server needing to create a bot for doing 
> it rather than just implementing it in directly)
> 4) security (what is someone hijacks the bot or spoofs it?, they could 
> cheat or possibly steal sensitive info)

As easily as hijack the game component. Or how is the component more
secure than any bot that runs (in most cases) on the same server?

> >*) You want a real person to be referee.
> >  
> I cant think of many games where you would actually want something like 
> that, the majority of games (if not all) will have a set of rules that 
> can be automatically followed by a computer.

Maybe just historical reasons? Maybe the rules are not simple or tight
enough (define a foul in socker, you need referee there). I do not know
of any reason, but it does not mean no-one will ever have such reason.

> >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.
> >  
> But surely it has to be external for your solution to be worth doing, 
> otherwise it makes separating it out completely pointless if you are 
> implementing the bot as part of the game server anyway, you might as 
> well just implement the game logic straight into the game server and get 
> rid of all the complexity.

No, you can make the core ones (the ones you would do anyway) internal.
In that case, you can think of the referee bots as choosing the rules
for the game. But you still leave the space for anyone to build the bot.

> >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,
> >whatever)
> >*) Keep list of play-starving users (those who just want to play with
> >anyone, may be interconnected with MUC room)
> >  
> Those people are better off just joining a lobby type MUC room to try 
> and gather players, this is just like how most other systems work.
> >*) Keep list of ongoing games (publish them only if they are public, of
> >course)
> >  
> Of course
> >*) Do routing for each game (with possibility to send to all, one,
> >preset group/team)
> >  
> Routing what exactly? All the game component should be routing is game 
> state information to all the users in that particular game session and 
> what would pretty much always be going to all, otherwise players would 
> get out of sync with each other.

Routing the moves.

And, you do not want to send all information to your enemies if you play
team. Some of the info may be secret (like where you position the

> >*) Remember game state and/or (and send it to newly connected
> >players/spectators)
> >  
> Yup
> >*) Save/load games
> >  
> Not really sure that is needed for most games, usually you would just 
> forfeit the game if you leave.

Yes, but what if you say we will continue tomorrow this time and save
the state of chessboard so you can load it?

> >*) Maybe fork or merge games (I do not know if this may be of any use)
> >  
> Maybe
> >*) Couple with MUC rooms (the way the game flows trough the game
> >component and game chat is trough MUC is nice idea)
> >  
> Cool, im glad you think so.
> >It would have disco structure something like this:
> >GC
> > +-Bots
> > |  +-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
> > +-Referees
> > |  +-Chess referee
> > |  +-Dummy referee
> > |  +-Some real person wishing to referee - unlikely
> > +-Overlords
> > |  +-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
> > +-Games
> >    +-Chess
> >    |  +-One chess match
> >    |  |  +-Chess referee
> >    |  |  +-One player
> >    |  |  +-Other player
> >    |  |  +-Some spectator
> >    |  +-Game without published person list
> >    +-Other game
> >  
> Seems a bit over complex, we need to be building this for Aunt Tilly 
> type users to be able to use and understand, you should need to have to 
> read a manual to be able to play the games, it should be intuitive, 
> which IMO the above is not.

This is not to be looked up by users directly (usually). It makes it
possible for client to list all available bots, for example.

> >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
> >plays.
> >  
> Personally I don't think AI bots should be being listed at all, it would 
> make things far more simple if you do it like other game systems do, and 
> you simply ask the game for a set number of AI bots, you don't need to 
> go and find them or invite them and you don't need to try and work out 
> if a particular bot you have found understands the game you want to 
> invite it to, it makes far more sense if you just send a command to the 
> game that says something like "add 4 bots", and then its all done, far 
> less complicated and more easy to implement and use.

But what if there are many special kinds of bots - there are many ways
how you can write a chess AI bot, some better some worse and you hardly
can limit for difficulty level here. You need to choose which one. And
making the bot the same as normal player, it hides the difference from
client developer.

But there may be command for the game component to find the bot for you
in the list.

> >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.
> >  
> As already explained, I do not believe this is needed, and even if you 
> do want to implement your server with external components validating the 
> game logic it definitely should not be exposed to the users full stop, 
> there is no need for there to be anything in the user side protocol for 
> this sort of thing.

But making it hidden makes it harder to debug if it is needed. Users do
not read the XML which is sent. It means if you make a simple client for
chess, you do not NEED to expose it. But if you want to have the
possibility to specify other kind of rules, this may be one of the ways.

> >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).
> >  
> This would be something best left to be defined and implemented for any 
> games that require it, rather than it being part of the core protocol as 
> even you admit it will not be required in most cases.

Well, it would be some kind of automatic moderator. It can take care of
the world (like tree falling, stupid animals around..). It would not be
much different from normal player, just it would see anything and the
referee would allow it do anything. Otherwise AI bot.

> >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.
> >  
> Sure.
> >*) 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
> >others.
> >  
> Sure although I am still unconvinced and deeply sceptical about the 
> concept of referee bots, you need to provide some real genuine benefits 
> far more than what you have already provided to convince me that they 
> are worth all the extra complexity they introduce.

Well, I do not see disadvantages for them in the first place. They allow
to use them only when needed. You do not have to care about them if you
do not want. And they allow for things like free plugin system,
possibility to debug and replace by parts. You do not need any
frameworks (I really do not like this word, it always means complexity,
allowing for only some selected set of languages..).

And you still can have them as internal part of the component so you can
use them only as the rule settings.

> >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.
> >  
> Yes I understand what you are getting at, im just not convinced about 
> and don't agree with the referee bot and the server not knowing about 
> any of the games its hosting part. I think that if a user wants to play 
> a game that a server does not support (i.e. one they have made up) then 
> they should just effectively make themselves the game server and have 
> all the moves etc directed directly to them, which is pretty much the 
> same difference as your solution as in your solution as they would need 
> to act as the referee anyway, handing the game directly (i.e. as if it 
> was a 1-1 but is actually for more) is far less complex than trying to 
> be a referee bot and be interacting with the server to control it.
Hm, I think we will not agree here - what the others think?

This is a terroristic email. It will explode in 10 minutes, 
if you do not close it in the meantime.

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/9e607123/attachment.sig>

More information about the Standards mailing list