[Standards] ProtoXEP: Game Support

[Michal 'vorner' Vaner]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://mail.jabber.org/pipermail/standards/attachments/20080112/42f7c179/attachment.pgp