[Standards-JIG] proto-JEP: Game Sessions
Michal vorner Vaner
michal.vaner at kdemail.net
Tue Sep 19 07:58:21 UTC 2006
On Sun, Sep 17, 2006 at 10:45:29AM +0300, Mircea Bardac wrote:
> 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.
No, it does not. It only does the initiation. If the game chooses to use
jingle, then it may do so. I only said how to start it (there is only
If you mean the web part, it describes mostly how the sessions are
created. The proto-JEP actually does not prevent you from making some hybrid
thing (like with many servers, which are connected by web, or
something). Maybe I should state it there.
Between, this is aimed for in-XMPP games, not negotiating other games "I
want to play quake".
Or what messages did you mean?
> > 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)
Hm, that is another idea. However, the problem with MUC is, it does NOT
send everything, but only messages bodies. Which is misuse of muc
component for me, if the data were sent trough messages if <iq> would be
I actually wanted to have something like game server component, which
could act as the said server - creating sessions and resending data.
Maybe I will need to define it somehow, but I thought it would be in
I do not like the idea of mapping data over MUC - multi-user _chat_.
And it is quite an overkill, if I had to negotiate with a MUC first,
then send it to the other and so on. For example chess game, it seems
easier this way for me.
> 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.)
Game can be described by changing document, yes, but it may be described
by flow of events as well, which does not need to be remembered. Which
means, shared document is not good for these games.
> 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
Yes, and I leave out-of-bound data for the games that need it to create,
since not all games need it.
> Hope this helps.
Hm, if you find out how to persuade MUC to send iq messages, than
probably yes. More, with MUC you see who you are playing with, there may
be games where you don't know who do you play with/against or how many
of them are. (well, I do not have any specific game in mind now, but MUC
would make it impossible). Or is there a way how to solve this?
There's the light at the end of the the Windows.
-- Havlik Denis
Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards