[Standards-JIG] New version of chess game protocol

Mridul mridul at sun.com
Wed Oct 11 00:45:50 UTC 2006




Michal 'vorner' Vaner wrote:
> On Tue, Oct 10, 2006 at 02:58:22PM +0100, Richard Dobson wrote:
>   
>>> 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?
>>>  
>>>       
>> No why would it be? Its up to the developer if they want to write their 
>> own version of a particular games protocol, this is just providing a 
>> common framework that could be reused for executing game logic by any 
>> component, it doesn't have to be python that was just an example, if we 
>> really wanted to we could write our own language for this, but 
>> personally I think that's overkill, if you look around you will find 
>> lots of projects that are starting to implement easy ways of writing 
>> addon's for them in a language that is different from what the main 
>> application is written in, python is one ive seen used and it seems like 
>> a perfectly capable language for this type of thing.
>>     
>
> Which is however harder than having it in completely separate process.
> You can let any programmer to just choose a language to write his bot
> in, as long as he is able to make the internet connection.
>
> In the case of plugin, you either need a new component for that game or
> language which is friendly enough with the one in which is the component
> written. Yes, python and C may be friendly. Lisp may be not, as it is
> language with completely different philosophy.
>   

Language of design , debuggibility of the component , etc are not 
concerns which should affect you while designing a spec.
That being said , it should be possible to implement the spec ofcourse.
By the way , 'friendly' nature of a language is just a function of 
comfortable you are with it.
Calling lisp not friendly would get you flamed pretty much in most 
universities , emacs newsgroups , etc :-)

>   
>>> And, if a bug shoots the thing down, will it take the whole component?
>>>  
>>>       
>> Only if you are a bad programmer, using something like this (i.e. python 
>> layer) infact makes it even easier to prevent that because each game can 
>> be running inside the server component entirely in isolation from the 
>> others.
>>     
>
> So why not leave the isolation on the OS? You save work.
>
>   
>> I apologise now if this seems offensive but what is your 
>> programming/development background? 
>>     
>
> Student at the moment, with some experience with few rents for a
> program and some programming competition (including international one).
>
>   
>> As the question above as well as 
>> questions and comments in previous emails in this thread from my 
>> perspective reading this seems to show a bit of a lack of experience and 
>> understanding of how to correctly develop and architect software, it 
>> would help to understand exactly what level you are at.
>>     
>
> Well, I meant it differently. I know you can catch falling parts of your
> application if you take care. I just do not like taking care if other
> design allows me not to.
>   

I am not really sure why you assume that there will be a single 
component for the entire server.
You could also have multiple components each for a separate game or set 
of variants.
The client will disco the server and figure of the jid's to be used.

> There are many philosophies. Some (Java is based on this) wants to build
> great monstrous pieces of code as one program. There is old one and
> whole Unix is based on that - split tasks between programs. It says
> program is easiest to be debugged and tend to be better if it is about
> 500 lines of code. You make big things by putting such small programs
> together. It was what I was trying. I just hate the way when program has
> few millions of lines (even if they are split into modules, classes,
> whatever).
>   
>   
>>> 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.
>>>  
>>>       
>> Yes thank you, remote debugging is something you often end up doing as a 
>> software engineer, not really sure what you are trying to get at here tho.
>>     
>
> Which is of course harder than the local one, so I would like to avoid
> it if I could. Debug it remotely if there is no other way.
>   

I am not sure why this focus on debugging : should not concern you at 
this time.
Btw, when you are writing an xmpp server and client - you definitely are 
not going to debug them locally !

>>> 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.
>>>  
>>>       
>> How can you actually know it doesn't understand it if its working in a 
>> generic way as you suggest? Just because it works in a generic way it 
>> doesn't mean it doesn't understand the commands/messages that are being 
>> sent through it, again if you don't trust a server you have no business 
>> using it in the first place.
>>     
>
> You may not trust it, but it still only delivers. You may detect
> inconsistencies/changes easily. And, in the first place, it would have
> to mean to do something wrong. It may be doing it wrong by mistake. I
> may trust the server it does not do anything wrong on purpose, but I
> might suspect it being buggy enough to misjudge.
>   

If there are bugs , there are bugs - and there is nothing the clients 
can do about it after a limit.
Other than file an issue with the server/component developer.
You send a message to userA at domain/res1 and it goes to userA at domain/res2 
, what are you going to do ? However smart you make your client , there 
will be usecases where it is totally helpless in even detecting issues.
But I digress.

>>> I say it is impossible to have one component that understands any game
>>> anyone ever thinks of.
>>>  
>>>       
>> I never said it wasn't, what I am saying is that is not necessary for a 
>> particular server to understand all games that will ever exist, as being 
>> part of the xmpp network means that if one server doesn't understand a 
>> game you want to play you simply contact a different server that does, 
>> simple, easy and no problem.
>>     
>>>> 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.
>>>  
>>>       
>> So... To be actually true to your ideals the server shouldn't understand 
>> any games whatsoever, thus there shouldn't be any "core games", also you 
>> still haven't provided any solutions for the normal operation of your 
>> protocol where the referees are external.
>>     
>
> No, I said there might be some core games, but I want to make it
> possible to plug them in as external clients and do instruct it to use
> one user wants. I want to have the possibility to have external ones.
>   

If the component does not understand a game , it has no business 
supporting it.
There will be some other component which will understand and support it.
Simple example , you can have a game which require 4 players (bridge or 
the like) , while you can have games like standard chess , etc which 
require 2.
The way you might approach both might be different. The way you set up a 
game , continue with it , terminate it , send results ,etc - all are 
going to be game specific.
The point is , gamesessions should allow various ways of propagating all 
this - and should remain generic enough.
The game specific jep's would define the actual semantics : while still 
remaining open enough to plug in other variants.
It does not mean that I attempt to play pool on a component which was 
written explicitly to support only chess.

>   
>>>> 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)
>>>>    
>>>>         
>> unreliability seems a bit of a major concern to me to simply ignore.
>>     
>
> First, if you have consistent connection, you do not loose stanzas (at
> last, you should not, xmpp should be reliable, right?).
>   

Your referee bot disconnects and then reconnects : you lose a bunch of 
stanza's.
TCP/IP gaurentee's in order delivery - not reliability , etc : you are 
misreading the intention of the protocol.

> Second, if the bot runs on the server, why it is less reliable than the
> server plugin?
>   

Your component/server goes down , user is notified of it - not in the 
case of a remote bot.

> Third, if any of the player looses connection, the game ends up as well.
>
>   
>>>> 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?
>>>  
>>>       
>> Im sorry but do you really believe that a game component is just as 
>> suceptable to being hijacked as an external bot is? The component will 
>> is far far more secure as it will be completely under the control of the 
>> server admin and can easily be secured, firewalled etc, whereas the 
>> referee bots are completely outside their control and could easily be 
>> running on someone's completely unprotected home pc.
>>     
>
> Those referees will not be listed in the public list. If I run my bot
> for my game, it is my business to risk it or secure it. If I pick up
> referee bot that is public - listed by admin - then it is running on
> that server probably and is as well secured.
>   

Going by the way you were specifying it , it looked more like - userA 
wants to play game1 with rules which will be validated by bot_1.
So no , bot_1 is not secure - can be hijacked , etc - it is specified by 
the user , not server.
By the way , I really dont see any usecase of specifying a refree bot : 
do you have any real world reasons for making this design choice ?

>   
>>> 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.
>>>  
>>>       
>> Can you please explain tho what is the point of creating referee bots if 
>> you are just going to have the majority of them internal to the game 
>> server component, from my perspective that just seems crazy with the 
>> amount of extra complexity it introduces,
>>     
>
> Where do you see the complexity? The game component gets stanza, it
> first pipes that rough the bot and when it comes back, it broadcastes
> it. That is all.
>   

One more level of indirection without any value addition: loading the 
server , decreasing the throughput of the system , and increasing the 
latency.

> And I do not say majority. I have (I hope not too idealistic) idea there
> will be not 5 or 10 games but some 100 later or so. You end up with a
> single game component that knows 100 games or with 100 game components
> each knowing a game, which seems worse to me in any case.
>   

There is no requirement that all 100 games with 100 variants should be 
on the same component.
Use disco to find out appropriate component.

>   
>> also if you don't have referee
>> bots you arn't stopping people from being able to make their own games, 
>> the developer of the game simply either needs to host their own server 
>> for their game, or convince other game server hosts to deploy it onto 
>> their servers too, that seems the far better option to me, and gives the 
>> server admins complete control over what sort of things they want to 
>> allow on their game server, without that control they could be opening 
>> themselves to a great deal of legal and financial liability, i.e. if 
>> someone implemented a version of monopoly without paying the appropriate 
>> royalties to hasbro the server admin could potentially get sued by them 
>> just because it is being offered on his server by a third party referee 
>> bot connected to it.
>>     
>
> Just by routing the info trough them?
>
> If the admin does not list the bot, then the users would have to supply
> it manually of course. Bots would not automatically plug in, they would
> have to be allowed/listed.
>
>   

Admin does not list a game means , he does not want that game played on 
his server : atleast he does not want to host it.
If required , you can go play it on other server (like over s2s or 
directly connecting elsewhere).

>>>> 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?
>>>  
>>>       
>> Just saying though that if we are going to do this we would probably be 
>> better off seeing what everyone else has done first (i.e. just forfeits 
>> the game), personally I think its far better if one or other of the 
>> clients saves the state of the game rather than the server, and then the 
>> server provides the ability to receive this state from the client and 
>> start a new game where they left off, otherwise if you are saving it on 
>> the server you have to deal with all sorts of storage quota, storage 
>> time etc issues that need to be described in the protocol, it also means 
>> clients can resume their game on a different server too.
>>     
>
> OK, lets say optional here ;-). That was just an idea. However, others
> may not trust the one player to store it and not change. And there may
> be secrets one should not see, so he could not save it. But it is minor
> problem here I think.
>
>   
>> <snipped disco hierarchy>
>>     
>>> This is not to be looked up by users directly (usually). It makes it
>>> possible for client to list all available bots, for example.
>>>  
>>>       
>> Yes it is, disco when used in this scenario is used for users to browse 
>> directly through the hierarchy to find what they are looking for, thus 
>> it needs to be kept as simple as possible, for an example of how to use 
>> disco like this have a look at MUC.
>>     
>
> Well, yes. If you wanted a chess bot, you could just look for known
> games/chess/ and see what is bot.
>
>   

Do not associate meaning to jids please.
The component might internally have some mapping , which is entirely 
different and is an impl detail : clients are not to associate any 
meaning with the jids.
Use disco info to query for characteristics and use items to query for 
the list.

>>> 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.
>>>  
>>>       
>> If it hides the difference from the client developer then how does the 
>> end user stand any chance knowing which bot is a hard one or a easy one? 
>>     
>
> By its name? If it's name is "Stupit chess bot", then the user has an
> easy choose.
>   

This is a bad idea.
Most online game servers have some concept or other of ranking or rating 
players : would make sense to use that.
Calling something 'stupid' or 'hard' is misleading : what is stupid for 
a GM will be tough for a novice.

>   
>> I think that most of the time when implementing the game logic that most 
>> people are going to just use pre-written libraries which will most 
>> likely already support computer players, so its far better to let the 
>> game itself deal with setting up the AI bots in normal instances, 
>> although yes some people may want to write bots external to the game to 
>> play against that to the server just appear to be other users, I just 
>> dont think we should restrict ourselves to only having AI bots that are 
>> external as most games will already have AI player support that can 
>> easily be hooked into.
>>     
>
> Then they can be represented by JID as well, no? Why does JID means
> external for you?
>
>   
>>> But there may be command for the game component to find the bot for you
>>> in the list.
>>>  
>>>       
>> But if you do that then you are making the bots appear differently to 
>> the server than a normal player, you cant have it both ways, it either 
>> appears to be a normal player or it doesn't.
>>     
>
> You may have a bot setup as "default bot" - server just has a JID what
> should invite if said to get a bot.
>
>   
>>>> 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.
>>>  
>>>       
>> Debugging issues should never dictate how a protocol works, it might be 
>> slightly more difficult than simply doing a packet sniff, but it isn't 
>> very much more difficult, this is not a reason in and of itself worthy 
>> of not hiding them from the client and thus making them an 
>> implementation issue rather than a protocol issue.
>>     
>
> Any good protocol is implemented protocol. If you make a protocol that
> is hard to implement and debug, you end up with a useless document. So
> the fact that a protocol is hard to debug is even protocol issue.
>
>   
>>>>> 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.
>>>  
>>>       
>> That's fine, but I still think that's something best left up to being 
>> defined by the games that need it, either that or just in a separate 
>> spec from the core protocol
>>     
>
> It would not define any new protocol, just listed where you can get one
> such bot for the game (or the component could, if left automatically).
>   

The concept of a moderator who controls games , etc is something which 
is external to the scope of the protocol.
That would be an implementation detail typically , and usually clients 
do not directly interact with it ...

>   
>>> 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..).
>>>  
>>>       
>> No frameworks do not always mean complexity, infact it normally means 
>> less complexity as lots of stuff is already done for you without you 
>> needing to do it yourself, and no it doesn't always mean only for a 
>> selected set of languages, look at .NET as an example, you can use all 
>> sorts of languages to program against the .NET Framework and its growing 
>> all the time.
>>     
>
> Having a library for a complex thing does NOT make it simple. It is
> still complex and if you want to work with it, you still need to
> understand the problematic and further more, you need to know the
> framework.
>
> And, .NET is monster. Look how libraries are done in linux. You have a
> library that can be used from any languages (most of them), not only the
> ones the library is for and it is modular. You do not have to have
> 40 megs library if you need to open a network connection only. And with
> .NET, you have 2 versions already and people need to have installed both.
>
> And you say this is not complex? What is, then?
>   

Complexity from the point of view of the implementor.
But I dont think this is relevant to chess jep - so I will not digress :-)

>   
>>> Hm, I think we will not agree here - what the others think?
>>>  
>>>       
>> I think you are probably correct, and as far as what others think Mirdul 
>> seems to be agreeing with my way of doing this....
>>
>> My main way of thinking about this is that if the game server component 
>> is not going to take care of the game management etc itself then there 
>> is no point creating one in the first place, you might as well just use 
>> MUC rooms for relaying the game data directly from the referee bot you 
>> want or just have the clients directly communicating with the referee 
>> bot rather than having the game server as a middle man.
>>     
>
> You need to look up the bots somewhere, you need to route other things
> than <message> and no-one said the MUC component can not modify the
> message or route anything that does not have body. And you need to route
> only to some subsets of the game members, and if you have to do it one
> by one, then you are back at mine web type game.
>
> Yes, I meant the game component as some kind of specialized/modified MUC
> for games where the bots live and you can find them.
>
>   

There is nothing so great about bots - even currently , you have a host 
of bots which do things for users.
So a muc style approach is not going to preclude bots. A game could be 
considered as a tuple of muc's for this reason : which will take care of 
the requirements you have as of now.

The reason why you would want a jep for games in general and some game 
(chess) in particular is to handle game state , validation , game 
specific negotiation , etc.


Regards,
Mridul



More information about the Standards mailing list