Thanks Richard for this valuable information. What I am trying to do is to extend your "game matching service" in a "game matching and creating service" : a client may request to create new game hosts. So I would like the "game matching and creating service" to instantiate game hosts with their JIDs and specific parameters, and I don't know how to do that : I thought an internal component was loaded at server start according to its configuration file, so I guess my dynamic game hosts can not be internal components... ?
If this is right, the alternative may be that the "game matching and creating service" launches an external script (e. g. a php script on another web server) that creates a new daemon bot and register it as the game host. What's weird in that case is that this communication (launching the php script) is outside the Jabber protocol. Norman, you suggest another seductive solution, but it looks to me that it implies a modification of the server source code, and the way it implements MUCs. I hope my questions are useful to other people than me, since I am asking a lot :p ! Guillaume ----- Message d'origine ---- De : Norman Rasmussen <[EMAIL PROTECTED]> À : Jabber software development list <jdev@jabber.org> Envoyé le : Mercredi, 7 Février 2007, 13h33mn 59s Objet : Re: Re : Re : Re : [jdev] how to program a jabber game server On 2/7/07, Richard Dobson <[EMAIL PROTECTED]> wrote: > [...] the moves are not sent via MUC > rooms to make things nice and simple as a lot of games require that > players only know a certain amount of the game state and should not know > everything (only the game host should) examples of these sort of games > are battleships, scrabble, poker (infact probably all card games), I can > only think of a few instances of games where the entire game state is > know by all players (chess and checkers), and it makes things far > simpler for the game host to directly send out the game state, rather > than having to have two sets of game state being sent separately, i.e. > global state being sent via a MUC room and private state being sent > directly [...] I think one of the things that is being forgotten here, is that you could design the game master component to _be_ the MUC room. There's nothing in any spec to say that all participants see the same room state. You should be able to very easily send different content to each member of the room. The game component (acting like a MUC room) can do all the validation checks based on it's own internal state, and doesn't have to expose the full game state to anyone. Remebering that MUC is really just a set of protocols indiciating the preferred way of simulating joining a room/game, and sending messages. In a non-game context it makes sense that all users see the same data, in a game context, not so much. -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/ ___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
