[Standards-JIG] New version of chess game protocol

Richard Dobson richard at dobson-i.net
Tue Oct 10 13:58:22 UTC 2006


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

I apologise now if this seems offensive but what is your 
programming/development background? 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.
>
> 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.
>
> 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.
>
> 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.
>> 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.
>> 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.
> 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, 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.
>> 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.

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

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

Richard





More information about the Standards mailing list