[Standards-JIG] New version of chess game protocol

[Mridul]

Michal vorner Vaner wrote:
> 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.
>   

Actually what was described above can be considered analogous with how 
you chat in xmpp : so I hope that is also not a bad situation for that 
too :-)

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

Depends on how you write it I guess ?
I am not really sure why you consider it so tough to author a bunch of 
different variants for say chess.
Having programmed chess bots for better part of 5 years , I know for a 
fact that the basic rules are similar - just small variations on top of 
the same basics.
I have authored an engine a while back which could play 3 variants from 
the same codebase - just a command line flag change.
So , it is just how you write code.
They are called game variants simply because they are fundamentally 
alike except for some rules changed or quirks introduced.


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

Yes he would - just like a muc component author will need to do the same.
I am not sure why you consider that all game servers need to be trivial 
- it is just dependent on the level of scaling that the component author 
wants to provide.
The simple usecase of 'I want to play a game with my buddy' and the 
complex usecase of 'I am ID software and I want to leverage xmpp to 
build Doom x network infrastructure'.
One way to look at it is that we are allowing xmpp to be used as a 
middleware for how game servers reach and communicate with users/players.

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

I think I mentioned it some place else too - remove special status for 
bots : make them 'users' which are connected to the game component , and 
advertise themselves as bots.

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

Then all I can say is 'too bad' , you are playing at the wrong component.
It is like saying 'I dont trust xmpp server to manage my presence' , 
then you are using the wrong protocol (analogously , you are connected 
to the wrong component).

> *) 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 am not very sure of this - supporting this sort of usecase is pushing 
the responsibility from the server towards the clients ... and I am 
slightly jittery about that.

> *) You want a real person to be referee.
>   

You do have arbiter's in tournaments. But from what I usually see , they 
normally decide tournament results , pairing , etc - not individual 
moves in a game....
Is it possible to envision a case where there might be a need for this I 
guess ?

> 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,
> whatever)
>   

Makes sense. Required actually.

> *) Keep list of play-starving users (those who just want to play with
> anyone, may be interconnected with MUC room)
>   

Yes , most game servers have this sort of 'lobby'.
Either a grand chat room where all idle players are present , or small 
sections of players 'seeking' games.

> *) Keep list of ongoing games (publish them only if they are public, of
> course)
>   

Retrieve this list via disco based on node - like "*kasparov*" , etc.

> *) 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
> players/spectators)
>   

Yes , game state management.

> *) Save/load games
> *) Maybe fork or merge games (I do not know if this may be of any use)
>   

This would be game specific ... and hopefully a jep for that game could 
introduce it ?

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

As an example : currently in most chess servers , it is common etiquette 
to declare if you are a bot , a centaur (human using bot support) , or a 
human.
Violating these (and getting caught ofcourse !) normally get you banned 
from the server.
Also , it is common practice for people (especially amateur and 
professional chess programmers) to 'put their engine online' and spar 
against other bots or humans.
What I am getting at is , it might make sense to just disco (and maybe 
local info for that bare jid incase of violator , etc ) the user to find 
out if it is a bot or not - and just flag is appropriately.
This allows any number of , and potentially different , bots to be 
plugged into the system.

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

And most of these resemble how you would configure a muc room :-)

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

Usually it is the reverse - there will be very few server side 
implementors anyway : but potentially many more client side implementations.
So it makes more sense to ease the latter's job.


My 2 cents.
Regards,
Mridul
> I hope it makes some sense.
>
>