[Standards-JIG] proto-JEP: Game Sessions

[Mircea Bardac]

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.


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

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


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/20060919/7511d076/attachment.pgp