[Standards-JIG] New version of chess game protocol
Michal 'vorner' Vaner
michal.vaner at kdemail.net
Tue Oct 10 18:47:17 UTC 2006
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.
> >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
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.
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,
> >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.
> >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.
> >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.
> >>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?).
Second, if the bot runs on the server, why it is less reliable than the
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.
> >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.
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.
> 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.
> >>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.
> >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
> 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).
> >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
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?
> >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 are two types of optimizations. The ones which make the program
slower and the ones which make the user red by missing features.
Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards