3dpong request for hosting

[Benjamin M. Schwartz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Samuel Klein wrote:
> Benjamin M. Schwartz writes:
>> Samuel Klein wrote:
>>> Yes, it would help to have distributed network services such as ones
>>> that let you say "join the next available connect/pong game"
>> This is easy to implement within the current sharing framework.  It just
>> requires each game to pair off users as they join the activity.
> 
> I'm not sure what use case you have in mind.  I'm suggesting a service
> that does not require you to explicitly join one instance of an
> activity.  You don't care how many people are playing pong (0 or 10)
> or the XO-color of the person who started any specific instance of the
> activity.  You just want to be connected to the next available person
> who also says they want to be connected that way -- whether that means
> you hang out broadcasting your availability for a while, or are on a
> distributed waiting list, or wait while a number of idle players
> running a shared activity (who haven't said "aggressively pair me for
> a game" but are perhaps waiting for a specific partner) are invited to
> play with you.
> 
> Existing tournament systems provide all of the above.  The GAMBIT
> group working on a card game system may have specific ideas they've
> tried to implement.

My point is, instead of thinking "Activity=Game Instance", just think
"Activity=Tournament Instance".  If there's no one playing Pong on the mesh, you
can start your own open Pong tournament and hope someone joins.  If there are
already 10 people associated with a single Pong Activity, that means that that
Activity contains up to 5 games at the moment.  Everything you've described is
easily implemented as an Activity.  There is absolutely no need to modify Sugar
to make it work.

> 
> On Jan 11, 2008 7:42 PM, Wade Brainerd <wadetb at gmail.com> wrote:
>> I'm thinking of the case where there are 5 people connected to a
>> 3dpong activity.  Two are playing, the rest are watching, waiting to
>> play the winner.  Some overall score needs to be maintained, saved to
>> the journal etc.
> 
> Overall score and persistent rank are metadata that could be stored
> externally to a specific activity -- it could ask the journal, the
> activity, the network for different scores and metadata (# of games
> played/won, parameters of each game and raw score) and could, for
> instance, calculate a number of different "averages" or lifetime
> ratings for a given activity.  And I can imagine wanting to have ready
> access to this information for a few dozen activities without opening
> up all of the activities individually - speaking to the reuse you're
> asking for.

This kind of data is precisely what the Journal is for.

It is true that currently, the Journal design does not provide an easy mechanism
to join an Activity and bring something to the party.  For example, If A and B
have both been collaborating during school on a Write document, and then they go
home and continue to work, there does not appear to be an easy way for them to
re-share the document and merge the changes made off-line.  This might be a
worthwhile addition to a future Journal design.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHiPVoUJT6e6HFtqQRArmsAJ9vJkJzkzXvrDPGv/IxDrfO+5eK0wCgmwxK
sTJ4gEXUhv5+0BRfzezQeMs=
=k7gw
-----END PGP SIGNATURE-----