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