[Standards] New Proto-XEP: Multi-User Gaming

Jack Moffitt jack at chesspark.com
Mon Jul 28 05:08:37 UTC 2008

> Our problem is that we found no elegant way to extent MUC with all the
> features it provides. Because MUC is big and provides features we don't
> need and it's difficult to integrate our idea in MUC.

It is quite easy to extend MUC.  One way is through plugins in your
muc implementation.  For example, Chesspark creates a new role in our
game MUCs called "player".  Players don't normally receive messages to
the room from non-players.  This is so that people watching the game
cannot interrupt them or help them accidentally.  However, player chat
is seen by everyone.

Another way to extend muc is just to invent some new adhoc comments
and implement them in the muc.

> For example if we join a game room it's complicated to handle the MUC
> affiliation, MUC role, game role and the game state in the existing
> stanzas and to enter the room in two steps make the process slow and we
> have redundant messages.

I think you're prematurely optimizing here.  At Chesspark the arbiter
sends a game start message to both players that tells them which room
to join.  Arbiter and both players all join the room.  Arbiter sets
the appropriate roles for the players and sends state.  Players send
iq requests to arbiter directly to affect game state, and arbiter
broadcasts state changes to the room for everyone.  When new people
join, arbiter directly messages them the current state.

It's not a single stanza, but it is not overly verbose and it works
great.  It's very easy to put hooks into the MUC component to fast
track messages from trusted components, and this can make processing
messages extremely efficient.

> Also routing game turns can be incompatible with the MUC rooms, so that
> we can't provide messages to only a part of the players (for example a
> team).

We already do this with our palaver extension for new roles.  You
could easily have a team role with a name or id, and then do delivery
based on that.  Or you could utilize multiple muc rooms.

> On the other hand implementing a small new gaming protocol is simpler
> as to find a way to modify the existing MUC implementations that it can
> be used for gaming. We think our proposal is very flexible so it's
> possible to implement small game clients without MUC (and for example
> use another client for communicate) or support additionally ways of
> communication such as jingle.

This is an age old debate in the jabber community. Whether games need
a muc or an arbiter.  In the general case an arbiter is necessary, and
certainly MUCs are natural tools for gaming.  We've been doing
multiplayer XMPP games for 3 years now, and I can tell you that MUCs
work very well.

>> Does it mean the server part must know the rules?
> Yes, since we need server support for gaming (for routing, saving games
> such as the client don't have the complete knowlege), the server has to
> know the game rules. This can support simpler and smaller clients and we
> have a sigle point of trust for validation.

We do this as well, and the component is named Arbiter (as mentioned
above).  It does allow the clients to be simpler, although for some
games this savings is not great if you want to provide a great UI.
For example, none of the Chesspark clients have to know the specific
rules of any chess variant, but they do need general information on
how pieces can move if you want to support features like allowed
square highlighting.  I suppose you could do this through the
protocol, but it could potentially be a lot of data to send.

I suggest anyone that is working in this area should also create a
Chesspark account (it's free and works with your existing jabber
accounts) and look at the protocol a little bit.  We've not yet
documented it, but we do plan to do so, and our clients are GPL.   I
gave a small presentation of it at XMPP Summit 5, and if anyone is
interested, I'm happy to write up a summary on my blog.


More information about the Standards mailing list