[Standards-JIG] proto-JEP: Game Sessions
dev.list at mircea.bardac.net
Tue Sep 19 18:16:21 UTC 2006
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.
> | 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.
> | 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
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
> | 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.
I was just pointing an alternative that uses an *authority* (the game
initiator) for saving/restoring a game.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards