[Standards-JIG] A jep for the Games
trejkaz at trypticon.org
Mon Jan 23 00:08:23 UTC 2006
Heiner Wolf wrote:
> Maxime schrieb:
>> Excuse me, I'm a noob and my english is bad lol.
>> My question is : Is there any jeps about integration of games in jabber ?
>> For example, if a developer wants to create a chess game which use
>> jabber to communicate, I think he'll like to use a standart protocol ;).
> Game clients would communicate by calling functions at the other end.
> This sounds like general remote procedure calls, which lets me think,
> that you might try JEP-0072: SOAP Over XMPP.
Or even JEP-0050, to be even simpler. The downside being that the other
service has to talk JEP-0050, whereas with JEP-0072 the other service
could just be a proxy to a service which only knows how to talk SOAP
over HTTP. That way the Jabber client could access the same games as
something that isn't necessarily a Jabber client. Though I still think
XML-RPC is slightly easier to stomach. ;-)
> There is nothing more game related yet, like e.g. highscore management.
I said to someone who replied to me off-list, that multiplayer games do
in fact have a certain amount of stuff in common, no matter what game it is.
All games do have a certain amount in common. You have two main use
cases: creating a new game and joining an existing game.
Suppose we have this component called the game service which all players
connect to (this would be the equivalent of something like the MS Zone
web site, only in XMPP land.)
Player creating the game:
1. Tell the game service to create a new game of type X.
1a. Game service responds with error "game type not supported".
1b. Game service responds with success, telling the client any
details it needs to join the game itself. e.g., if this
particular game type requires groupchat, it would tell the
client which groupchat room to join.
2. Do whatever has to be done, such as joining the groupchat.
3. Optionally, send a game invite to the player joining. This could
possibly be done through the game service itself so that the
service can recognise the players who join later as having been
Player joining the game:
1. Ask the game service to find all open games of type X. (Unless,
of course, this player got directly invited by step 3 above, in
which case this step won't be needed.)
2. Tell the game service to join a certain game.
2a. Game service responds with error "game type not supported".
2b. Game service responds with error "no such game in progress".
2c. Game service responds with success, giving the same details
to this player that it gave to the one who created the game.
3. Do whatever has to be done, such as joining the groupchat.
At some point, the player creating the game has to tell the game service
that they're starting the game, at which point the game is no longer
considered to be open (so new players looking to join a game won't see it.)
There would be one other type of game, the strict two-player variety
which doesn't require the game service as an intermediary.
Communication would be rather similar in both cases once the game is in
progress, but a different inviting procedure would have to be used for
the direct game.
Direct games wouldn't be as clean anyway, because it would make it much
easier for players to behave poorly. e.g., imagine a poker game where
one player's client generates all the random numbers. It doesn't take
long to figure out that this player is going to get all the straight
As for specific interoperability for different game types, it's almost
like a sub-group should be created to manage creation of these "JGPs".
I can easily see the set of all games becoming greater than the set of
all other JEPs, and it's possible that something like game protocols
shouldn't be handled as seriously as other standards in the first place.
More information about the Standards