Re: Multiviews?

On 11/2/06, Howard Stearns <[hidden email]> wrote:
The basic idea of the interactor is interesting to me.  I read the
"Filters and Tasks in Croquet" paper a few times, as well as the
earlier referenced papers on Magic Lenses.  I like the idea of the
interactor getting "pasted onto your camera lens" and allowing
stacking of interactors.  Particularly for developers, I could see
using a series of interactors like the wire-frame view, the
boundSphere view, the little arrows representing normals view, etc.  I
can easily visualize how these could be used individually and stacked.
 Maybe 3D painter or mesh deformer interactors could be built.

But I don't really understand how this idea is brought out in Croquet.
 I have the general impression that David A. Smith is doing further
work in this area that will eventually dramatically change things.  On
the other hand, you tell me that you have already done this in
Dormouse and I know that Mark McCahill and team have done some of this
in Hedgehog with thumbtack annotation.  This is an area that I would
like to someday explore further, but what should I use as a starting
point?  Or is the real starting point just not ready for public use
yet?

Somewhat related to your two-island security model, I have been
thinking about how to implement a simple example collaborative Texas
Hold'Em poker game.  The cards have to exist in a replicated island in
order to be dealt from a common deck and for scoring, but different
participants have different rights with respect to viewing the cards
and these rights may change at different points in the game. And the
chips can be viewed by all participants, but only manipulated by their
owner or the dealer.  This is so far just an idea floating around in
the back of my mind, but it seems like a good and fairly simple
example to explore the whole area of security in Croquet.

And as a meaningless parting shot, why is it "putting in my two cents"
but only "a penny for your thoughts?"  I definitely value your input
more than mine!

David Faught wrote:
It's anybody's game. This is all open experimental work. I like David  
Reed's description of the project as "invention in public."

The Dormouse interactors (and I imagine, the first Wicket and  
Thumbtack interactors) used a filter implementation. As the rendering  
descends through nested interactor/fiters, it adds each interactor/
filter to a collection. When the object renders, it does so  
conditionally on whether  the governing filter that it knows about  
appears in the collection.

In Dormouse we treated this as means of getting the EFFECT we wanted  
so that we could see what it would be like to work with. You can do  
the same if you like. (And I imagine that the existing public  
thumbtack code is suitable for that.) However, it doesn't really  
handle your poker example if players are allowed access to their  
Squeak environment.

Depending on your purpose, a valid way to deliver your poker example  
is to seal up the Squeak environment somehow. I'm not exploring that  
just out of my interests, but it can still be a reasonable thing to  
look at.

I like this example!  Depending on your purpose, it might not make  
sense to do this purely within the model. But it's a nice exercise to  
see how that might work.  By the way, this has been reviewed by,...  
well, you're the first, actually.

IF my dual-postcard interactor pans out (a very big "if"), then the  
idea would be that the players enter a parlor to play. Each player  
has an avatar that wears sunglasses and green eye-shades. The players  
optionally communicate by text chat,  live voice, and video. The  
cards appear as ordinary objects that can be moved around, but the  
face of each card is blank.  However, as each card is dealt, the  
person to whom it is dealt sees the real face of the card. (If you  
prefer, maybe they have to wave their mouse over it or something.)  
When called, the players turn over their cards and the faces appear  
to everyone.

An experienced visitor to the parlor might know that the visors they  
wear are what allows them to privately see the cards dealt to them.  
A player can copy his visor and give it to someone else (presumably  
not one of the other players!) so that their friend on another  
computer can see these cards, too. A spectator could even get visors  
from each player who gives a copy.

How it's done:

The parlor is an island like any that you think of in Croquet now.  
Each player's visor is unique. It has a normal postcard to the  
parlor, but each has a second overlay or UI postcard to a unique per-
player island. The players are automically made to wear the visor as  
they pass through the portal to enter the parlor.

The "house" also maintains another island that the player do not have  
access to. For each hand, the house generates a set of shadow card  
objects -- on the house island -- which point to the real cards. The  
house can make another set of shadow cards from the first set, and  
then copy these cards into the parlor.  The parlor shadow cards are  
the ones that are shuffled and manipulated in the parlor space, and  
dealt. Thus the parlor shadow cards have postcards to the house  
shadow cards, and all of this is specific to this hand. Squeaker's  
can't see which card the parlor shadow cards point to, because at  
best they can only see the postcard data, and the interpretation of  
that postcard is unique to that hand.

As each card is dealt, the house copies the face of the real card to  
the shadow view of the card that appears in that player's private  
island.  That player sees the face of the card, while everyone else  
sees the back. When the players turn over their cards at the end, the  
house copies (only) those card faces to the parlor.