[Standards-JIG] New version of chess game protocol

Richard Dobson richard at dobson-i.net
Mon Oct 9 14:32:32 UTC 2006


>> 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.
> 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.
> 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.
> 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.
> *) 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:

1) latency (there will be a delay while the game traffic is being routed 
via the referee)
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)
> *) 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.
> 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.
> 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.
> *) 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.
> *) 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.
> 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.
> 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.
> 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.
> 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.
> 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.

Richard





More information about the Standards mailing list