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

Arne König arne.ko at 23inch.de
Tue Jul 29 14:53:36 UTC 2008

Hi Jack,

Jack Moffitt wrote:
> 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.

There are two different thing to look to at here. First is the protocol
level. Extending the MUC protocol is fine. But changing the routing
actually breaks MUC since routing in MUC isn't intended to be changed.

The second problem is the implementation. Adding a role to the chat
requires changes in both server and client MUC implementations. In many
implementation that is hard to accomplish. We try do create a protocol
that can be implemented in most clients and servers. If you take
Openfire for example. Their MUC component doesn't have a plugin
infrastructure. Thus to change the routing of MUC you would have to
rewrite the whole component. On the client-side you have multi-protocol
clients with similar problems.

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

Most things you describe don't conflict with our proposal. The only
thing that we don't do is send states through the MUC room since we try
to seperate all game messages from chat. Our proposal defines the
communication between the game service (arbiter) and the clients. It
also provides a way to discover the associated chat. Everything besides
that is implementation specific. The service may create the MUC room,
configure it accordingly, update player statuses (give voice to every
player, no voice for spectators).

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

But you don't need any of those hacks if you don't misuse the MUC for
game messages. Team chat is a special problem that should be handled by
the game protocol itself. This again should be no big problem as long as
you use team chats only for chat.

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

I agree that you need both an arbiter and a chat. But MUCs are natural
tools for chat, not for gaming.

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

There are definitely cases were it may be useful to allow a client to
"guess" a move. Whether that are chess variants or games with incomplete
knowledge. We will add support for that.

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

Where can we download the source for the client? We only saw a link for
the windows installer. Also we would appreciate you describing your
protocol further.

Thanks for your feedback,

More information about the Standards mailing list