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

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


More information about the Standards mailing list