[Standards-JIG] proto-JEP: Game Sessions
dev.list at mircea.bardac.net
Sun Sep 17 07:45:29 UTC 2006
First of all, sorry for the late comment.
I was looking with great interest at the discussion, since I was also thinking
some time ago about creating such a JEP. Unfortunately, the birth of it
didn't make me happy. Reasons below.
On Tuesday 12 September 2006 20:25, JEP Editor wrote:
> Abstract: This document defines how to initiate a game session over the
> XMPP protocol
Apparently, the JEP does not only define how to initiate a game session, but
also how to send messages between the peers. This looks like a minor conflict
between what it actually does and what it says it does.
> URL: http://www.jabber.org/jeps/inbox/gamesessions.html
The whole idea of forwarding messages from one peer to another looks like a
misuse of Jabber for me. IMO, all game types can easily be mapped over a MUC
Imagine the following scenario:
1. I ask a MUC component to give me a new randomly generated room (not sure if
this was standardized after all, I remember there were some discussions about
it) - anyhow, I enter a new MUC room.
2. As an owner, I configure the room in the following way:
a) All game participants are MUC-participants
b) All spectators are MUC-visitors
c) The default role is visitor
d) The room is invite only
(these should be looked through the MUC JEP)
In this case, only participants will be able to send messages to the MUC
component. The MUC component will handle forwarding to all game participants.
Spectators(visitors) will only be able to read the messages exchanged in the
MUC room and play the game.
In order to sync with the current status of the game, (because the MUC
component doesn't replay ALL the messages - from the begining of the game), a
spectator could private-message one of the participants to request a sync.
The room owner (the initiator of the game) could
The room owner (the initiator of the game) could store the game status for a
later restart or he could delegate one of the participants to store locally
the game status for a later restart.
While I was writing this e-mail, I remembered the discussion on whiteboarding
and a step which was made to ease the development of the protocol.
There's a JEP in inbox/ named: Shared XML Document Editing
I remembered it because it describes how one2one/multi-user sessions are
started. Theoretically, anything can be mapped over these sessions, including
gaming AND whiteboarding (with saving, sync-ing, spectators etc.)
Now that I look over it, I can see that multi-user sessions are also handled
by MUC components.
Maybe join forces in order to produce a "Collaborative Work - Session
Management" JEP, to be used for starting all kinds of sessions with:
a) session setup (type, with/without spectators)
b) session saving
c) session restart
Anything could be mapped over that.
Also, something which hasn't been covered, session negociation for out-of-band
collaboration. In this case, application-support would be necessary, but only
for receiving session parameters from an external application (the IM
Hope this helps.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards