[Standards-JIG] proto-JEP: Game Sessions

Mircea Bardac dev.list at mircea.bardac.net
Sun Sep 17 07:45:29 UTC 2006


Hi all,

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 
component.

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
 http://www.jabber.org/jeps/inbox/sxde.html

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
d) spectators

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 
client).

Hope this helps.


Regards,
Mircea

-- 
http://mircea.bardac.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060917/ae707b8f/attachment.sig>


More information about the Standards mailing list