[Standards-JIG] proto-JEP: Game Sessions

Michal vorner Vaner michal.vaner at kdemail.net
Tue Sep 19 21:40:13 UTC 2006


On Tue, Sep 19, 2006 at 11:07:07PM +0300, Mircea Bardac wrote:
> On Tuesday 19 September 2006 10:58, Michal vorner Vaner wrote:
> > On Sun, Sep 17, 2006 at 10:45:29AM +0300, Mircea Bardac wrote:
> > > 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.
> 
> My comment wanted to point out that you also want to describe delivery (as 
> in "message forwarding"), something which is not part of the *initiation* - 
> thus the contradiction between the Abstract and the content.
> 
> > > > 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.
> >
> > 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
> > needed.
> 
> Hmm.. this is XML. You can wrap anything in XML, as long as it doesn't 
> conflict with something in the currently-in-use namespace.
> 
> Therefore, 
> 
> <message type="groupchat" to="someroom at conference.someserver.org" id="abc" >
>   <iq xmlns="http://jabber.org/protocol/gamesession">
>     <session-started />
>   </iq>
>   <body>Session started.</body>
>   <nick xmlns="http://jabber.org/protocol/nick">IceRAM</nick>
> </message>
> 
> is perfectly legal and gets to be forwarded completely. I've named the 
> in-message-tag "iq" just because you wanted to send IQs (I've tested the 
> above stanza on conference.jabber.ru and it worked, being sent completely). 
> I've added <body>...</body> just to make it show with a regular MUC client - 
> works well without it either.

And it does not look nice at all, actually. That is really a hack. And
why you need it in game of 2 people?

> The main difference between messages and iqs from the protocol design point of 
> view is that messages don't require confirmation and iqs do require 
> confirmation (<iq type="result" id=abc" /> ).
> 
> The confirmation can be easily overcome by the fact that, once the MUC 
> component received the message-stanza, it forwards it to all MUC 
> participants, INCLUDING the sender. Once th sender receives the sent message 
> (same id), you can consider that the confirmation arrived. It is no longer 
> your problem as a client (sender) to THINK of the transport - the transport 
> layer delivered/tried to deliver the message to all participants.
> 
> > 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
> > another JEP.
> >
> > 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.
> 
> I probably didn't make myself clear. MUC would only be used as a transport 
> layer. As a side effect, it would also keep (as roles) the statuses of the 
> game session users. You can also kick/invite in a room (which would be a 
> synonym for a "session").
> 
> Think of the following: in any other implementation, this protocol would have 
> to:
> 1) first establish a connection with the transport layer [open a TCP socket]
> 2) After the connection is established, the transport layer gets connected to 
> the other peers (invite/join) [TCP connect/accept]
> 3) Once the peers connect, you need to start a session (this is another 
> layer). [start own protocol over the connection]
> 
> MUC maps perfectly for the transport layer, before session is started.
> 
> > > 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.)
> >
> > 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.
> 
> First of all, that document is still draft.
> Second of all, it was only thought for documents, not games.
> Third of all, the document does not mention that replaying the history is a 
> must.
> 
> Above all, that document tries to describe a session, just like the 
> gamesession JEP tries. The session would be used in different modes, but 
> still.. it would be a session for multiple users.
> 
Yes, it is true. But on the other side, it would have to be done very
well to support needs of both (or more) and not be too abstract.
> 
> > Hm, if you find out how to persuade MUC to send iq messages, than
> > probably yes.
> See above. It works. It worked for me.

Well, many libs for jabber have some special routines for handling iqs.
For example waiting for the answer, match on iq type and so. You lose
all these things.

> > 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?
> 
> When I said to use MUC as a transport layer, I didn't mean "show the IRC-style 
> dialog for the users". In any implementation, it is at developer's desire to 
> show or not to show the participants in the game, given that, AT SOME POINT, 
> the playerlist is sent in the session.

Well, what if the user develops own game client by the protocol and
shows the list even if it should be kept secret from the player?

> If you need extra options you can either:
> 1. develop a new server component for a transport, possibly forking a MUC 
> component.

Well, I want to do something like that, some hybrid between multicast
component, muc and with some little intelligence and with possibility to
ask for a game bot from the server (if there is some available for this
given game).

But it will be optional for the games to use it. As I said, if you have
3 or 4 players, the load of sending to anyone is not too big and the MUC
will make more work for programmers. You need to init the room,
configure it so no one can join and still you need to discover the other
side, if it is capable of playing games (unless some client joins and
starts sending usual messages), include all the info about game in the
MUC invitation.

And, what if you want to play 2 teams against each other? You have 2
MUCs for things that are private for that team?

> 2. extend MUC with a "totally anonymous" option or something, to be activated 
> on room creation
> 
> 2nd of all, the true JIDs of the users in a MUC room are only seen by 
> moderators. When a user sends a message to the room, the message appears to 
> be sent from his cloaked identity.
> 
Still does leave the fact that you know the count of opponents.
> 
> -- 
> http://mircea.bardac.net

-- 
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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060919/553e824e/attachment.sig>


More information about the Standards mailing list