On Fri, 2007-02-09 at 10:21 +0000, Richard Dobson wrote: > > Instead, I would opt for using a vanilla MUC service and write a bot > > that owns the room. That should allow plenty control. > > > Exactly, which is what I am doing as part of it for the in game chat, > the only problem with using MUC is that you cannot use it for the > distribution of game state in most cases as a lot of games require that > each player has only a subset of the complete state, i.e. in a scrabble > game players cannot see what letters each of the other players has or in > a poker game you cannot see what cards the other players are holding etc > etc, so the game state in those cases needs to be distributed directly > individually to each player, also move/actions in the game need to be > sent directly to the "game host" (the bot or component) and cannot be > just be broadcasted in the room by each player as the game host needs to > verify those moves (and given the opportunity to reject them if they are > illegal or wrong) before the game state is updated.
Yes, of course. I'd say that you just private messages [1] for that. I don't think it matters too much that the messages don't originate from the room itself, and for clients that don't have a specialized game UI, I think it is very intuitive to interact with a game master. [1] http://www.xmpp.org/extensions/xep-0045.html#privatemessage > Also as pointed out by Michal the protocol needs to be able to support > operation without a server so it would be better if it wasn't tied to > MUC and would work without it, without the protocol being much if any > different. I haven't fully read the thread, but I'm not sure why that would be true. -- Groetjes, ralphm
