[Standards-JIG] proto-JEP: Game Sessions
Michal vorner Vaner
michal.vaner at kdemail.net
Tue Sep 19 21:23:07 UTC 2006
On Tue, Sep 19, 2006 at 09:16:21PM +0300, Mircea Bardac wrote:
> Hi all,
> On Tuesday 19 September 2006 10:29, Carlo v. Loesch wrote:
> > Mircea Bardac typeth:
> > | 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.
> > But going through a central instance is actually a longer path.
> > A 'multipeer unicast' approach ("Many to many game, type web") is faster
> > and involves less messages. Remember, Jabber doesn't multicast, thus
> > direct messaging always requires less messages than submitting something
> > to a central server, be it a MUC or a custom daemon.
> I find using message forwarding for multiple message sending to be bad.
> Jabber does multicast - see JEP-0033 Extended Stanza Addressing (Draft). A
> simple approach (IMO) to multicast (without server support) is using a MUC
> component for transport.
So, why not use JEP-0033 for that? Why misuse MUC? I think sending to
more recipients can be done by Extended Stanza Addressing without
mentioning in the JEP.
> > | 1. I ask a MUC component to give me a new randomly generated room (not
> > | sure if
> > If the central daemon for the game isn't doing anything specifically
> > useful to the game, the 'multipeer unicast' option is probably the
> > better choice. Only exception would be, if some MUC features by chance
> > happen to match your game requirements, like supporting 'spectators'.
> Do not confuse the MUC component with a game server daemon. The MUC component
> is used only for transport - it has no knowledge of game internals.
> Even though the MUC component also has some features for adding restrinctions
> to multi-user communication (using roles/affiliations), it is still a
> *transport* layer - ONLY a transport layer.
Which is not it's purpose AND it makes many problems in some cases. For
example the missing iqs.
But I may consider a MUC-based game as one of the possibilities in next
> > | 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.
> > And whoops you are off in special-hack-land. Why shouldn't you want the
> > central server to give you the full picture? Especially for games where
> > the central daemon holds relevant parts of the game logic (like on which
> > island the treasure is hidden) you just can't outsource it to any
> > client.
> Again, the MUC component is not a game entity (server/client etc.). It is only
> a transporter. You still need a game coordinator/session saver etc. - which
> would be best to be only ONE (an authority) - the creator of the game (be
> only one in order to prevent attacks to the game status).
> Therefore, if the transport layer doesn't have the possibility to replay
> everything, an *authority* should be used instead for querying the game
So, if it is needed, we should have the authority somewhere. And why not
have it on server instead of the MUC?
> > | 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.
> > Why do you want to enforce client-oriented application writing style on
> > people who may be perfectly able to do proper server-based apps?
> Hmm.. I wasn't doing this - or.. at least.. that wasn't my intent.
> But now that I think of it, the current JEP (found in inbox) puts all the work
> on the client, even the transport and user management in the game.
No, it only allows it. If there is game where it would be problematic,
then it is needed to be done by some game server/daemon. But I think
that it is waste for a game of 4 people to do it. It is the place for
web game, where I find the server/relyer/MUC to by too big. Why do you
force to use central component every time?
And if the central component is needed, I find MUC to be inaproprate. As
I said, I want to write another JEP of how the central game relay thing
would look like. It could relay iqs, keep secrets, do the sessions and
everything what is needed.
I don't have anything against the idea of having central part of games
that need it. However, I think MUC is not suitable for it at all, and
really not for all games.
> I was just pointing an alternative that uses an *authority* (the game
> initiator) for saving/restoring a game.
This email was generated by a biological random generator.
If you want more random text, just respond to this email.
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