Hello On Sat, Jan 12, 2008 at 12:21:43AM +0100, Torsten Grote wrote: > we concentrate on One-to-One gaming, since MUG will need server support.
Is it really needed? A gaming support on server? Couldn't this be done trough ordinary MUC? > http://www.cs.uni-potsdam.de/~tgrote/xep/game-support.html Just few notes here, may or may not be useful. Discovering: Wouldn't it make sense use service disco to get supported/ongoing games too? (add items supported-games and ongoing-games to item list, and their sub-lists as games, for example) It seems to me defining new protocol for discovering is not needed, if there is a generic one. Invitation: What is the difference between body and reason? I would put the reason to body of the message directly, as is with MUC invitations, and so on. Besides, wouldn't it be better in <iq>, as it requires response (either positive or negative)? I like the idea of using ordinary thread in messages as the game identifier, allows more concurrent games. Saving: she/he MUST not save the game and send the following she/he MUST NOT save the game and MUST send? Besides, shouldn't game saving/loading be optional in a way some clients can do it and some don't? (Therefore a discoverable feature for that given game). And, it should be noted each game needs a description of it's own, how it is saved, right? Loading: Is it a good idea send the whole state in the invitation? It might be long (depending on the game) and if the other side declines, it is wasted bandwidth. Terminating: It should be specified, what exactly happens, when the other side just changes to unavailable (lost connection, probably). > http://www.cs.uni-potsdam.de/~tgrote/xep/tictactoe.html Could it allow playing on any-sized plan (possibly infinite too) and have the length of winning strike & starting player negotiated? Besides, it probably should be noted, how the game is saved. Have a nice day -- Please enter password: Michal 'vorner' Vaner
pgptQDC5AX8W9.pgp
Description: PGP signature
