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

niess at uni-potsdam.de niess at uni-potsdam.de
Sat Jul 26 12:14:01 UTC 2008


Michal 'vorner' Vaner wrote:
> Torsten Grote wrote:
> > in the previous weeks we worked hard on our proposal for Multi-user
> > Gaming with XMPP that we would now like to present to this list [1].
> > It
> > is far from ready, but we hope to have covered the most important
> > parts.
> > Some aspects of the protocol were even controversial in our working
> > group, so we are anxious to receive feedback.
> >
> > One of these controversial issues is how to integrate our proposal
> > with
> > MUC. Since the protocol makes significant use of MUC, we are unsure
> > whether to somehow extend MUC, to create a protocol very similar to
> > MUC
> > and uses MUC only for chat (current approach) or to create a new
> > protocol that takes some parts (e.g. roles) from MUC.
> I have read it in fast, so if I say something not being true, I
> apologise.
> It seems to me some parts of the MUC XEP could be reused (this one is
> rather long to read and many parts are the same or similar, would be
> nice to somehow say it is MUC with the additions of… ‒ instead of
> writing it again).

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

> > In our proposal, the game service validates the turns it gets from
> > the
> > clients and kicks misbehaving clients. Permission management is
> > handled
> > a bit simpler than in MUC with only one association to the match
> > (affiliation).
> 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.
For simpler games we want to propose the instant gaming protocol [1] 
and recommend to use this instead of the multi user gaming.

> Anyway, I wish you luck with the proposal.

Thanks for your interest and your wishes.


[1] http://pidgin-games.sourceforge.net/xep/instant-gaming.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 250 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080726/adfba466/attachment.sig>

More information about the Standards mailing list