[Standards-JIG] A jep for the Games

Trejkaz trejkaz at trypticon.org
Mon Jan 23 00:08:23 UTC 2006

Heiner Wolf wrote:
> Maxime schrieb:
>> Hi,
>> 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 
flushes. :-)

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 mailing list