Michal 'vorner' Vaner said the following on 01/12/2008 11:13 AM: > Just few notes here, may or may not be useful.
Thank you very much for your comments! > Is it really needed? A gaming support on server? Couldn't this be done > trough ordinary MUC? We plan to use MUC extensively for MUG, of course. But please let's concentrate on One-to-One gaming for now. > 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. I used a separate mechanism for discovering individual games because there may be hundreds of games a client supports and this would blow up a disco response considerably. But compression or XEP-0115 might solve this problem. So, if there are no further concerns, I'll add the games disco to normal disco requests. > 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. MUC invitations use no <body/>, but a <reason/> element. I agree that one of them is enough. Maybe we should use reason in order to be similar to MUC. What do you (and the others) think? > Besides, wouldn't it be better in <iq>, as it requires response (either > positive or negative)? Well, MUC uses a <message/>, too and as far as I understood <iq/> stanzas, they always carry some kind of payload (get/set data) and are thought to be a request to another client, not its user, which would be better represented by a message. > Saving: > she/he MUST not save the game and send the following > > she/he MUST NOT save the game and MUST send? changed. Thank you! > 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). I thought about this, too and came to the conclusion that saving is not such a big think to implement and that it would only make the protocol more complicated. > And, it should be noted each game needs a description of > it's own, how it is saved, right? Could you please elaborate a little bit more on this? > 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. Sending the state in the invitation has the big advantage that the invitee can see how the game looks like and decide on better grounds whether he wants to join. This is especially helpful with "constructed" games. > Terminating: > It should be specified, what exactly happens, when the other side just > changes to unavailable (lost connection, probably). What happens when the other side changes to unavailable is defined, but not in terms of connection losses. They are a problem and I'm not sure how to handle these. If the game was not canceled, the client should be able to reconnect and play. If the client crashes, this is not possible, but the other player could save the game it is of the complete knowledge kind. >> 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? Well it could, but it doesn't ;) But it there are several variants of Tic Tac Toe which could be added as tictactoe#variant in the future. > Besides, it probably should be noted, how the game is saved. Saving is not yet supported by this XEP. I don't think that saving a game of Tic Tac Toe is really necessary and it could be explicitly stated that it is not supported. > Have a nice day Regards and Thanks again, Torsten
