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, Arne
