Thanks Ned --

Yes, we have thought about this quite a bit, and have done a few 
simple examples using Etoys. I've done various kinds of games (like 
Lunar Lander, shoot the alien, etc.), I and Bob Arning have done 
planetary orbits, there are a number of gear meshing and other 
physical interaction projects, I've done a Pavlovian learning "brain" 
for sea snails, etc.
      You are quite right that an enormous number of such projects can 
be done simply by writing lots of event-driven parallel scripts that 
are working within refresh frames.

Collision detection of various kinds is critical for systems with 
more than just a few interacting objects. It is natural for kids to 
start off with "color sees" and "color under", but this are pretty 
expensive for more than a few objects (though I have done some nice 
"epidemic" simulations with 50-100 particles just using "color 
sees"). Bob Arning has put in a more efficient collision detector 
which detects the type of object you are colliding with (as opposed 
to touching one of its colors). Proximity testing would also be very 
useful (right now we do it with translucent players that are parts of 
the main player).

Referencing what Ken Kahn has been discussing recently, I think a 
much nicer way to do a lot of this stuff is to have an event manager 
that each script can give the events it is interested in. The event 
manager can be very efficient (it can be like a forward inferencing 
RETE net) and it fires up scripts when it detects the events. Many 
wonderful things can be programmed efficiently this way. Today, only 
a few events are dealt with by an event handler (mouseEnter, mouseUp, 
etc.) and these are found in a fixed list in the "event" menu (the 
one whose default is "normal"). A better way would be to allow these 
to be specified as predicates that an event manager can deal with.

Re: parameters: Yep. At some point Etoys is supposed to merge with 
the mythical OmniUser authoring envionment -- it deals with the same 
kinds of objects, but with more bells and whistles. It's probably 
good to have parameters for Etoys (before the transition to OmniUser) 
-- but I must admit I have had a very good time figuring out how to 
do really simple scripts for complicated projects by only using 
instance variables and without using params.

re: inheritance. I'm not dead set against it, but we have been 
bending over backwards to try a "sideways" multiple roles model for 
Etoys. This is a much more parametric approach (as opposed to a " 
separate species approach") to differences between objects. So I 
think there are other (and maybe better) ways to deal with this than 
classic inheritance.

This is a good time to get interested in this, because there are 
forces afoot within SqC to get to the next level of these concerns. 
We'd love to work with you on some of this.

Cheers,

Alan



At 1:49 PM -0700 10/22/01, Ned Konz wrote:
>I was just playing Sierra's game/construction set called "Return of the
>Incredible Machine: Contraptions". For those who don't know what it is, it is
>a construction set for "Rube Goldberg"-type contraptions.
>
>For instance, you might make a system in which a baseball falls, turning on a
>power switch, which runs an electric fan, which turns a pinwheel, which is
>connected via a belt to a jack-in-the-box, whose opening propels a bottle of
>nitroglycerin into a wall, ...
>
>It's presented as puzzles, with some pieces possibly already anchored, and a
>parts bin with some more pieces. You're told to produce some kind of effect
>(like "make the bowling balls go into the laundry baskets"), and you do it by
>placing and connecting the parts as needed.
>
>When you hit the "Start" switch, object interactions start being computed.
>You can "Stop" the simulation, or "Reset" it, which returns objects to the
>position (and state) they started out in.
>
>I was wondering what it would take to make this kind of simulation work with
>the existing EToys system. What is probably needed is to repeatedly
>evaluate the effect of each object on each other object that it interacts
>with (for instance, many objects are affected by gravity, so the base class
>might well have a mass and motion vector). I don't think a general constraint
>system is needed for this; I suspect that the usual Morphic stepping would be
>adequate.
>
>Some objects only interact with other kinds of objects: things that move air
>(fans, candles, bicycle pumps) interact with only a few other objects
>(propellers, pinwheels, blimps and balloons, etc.)
>
>Some objects are only affected by nearby objects: when something like a ball
>falls past a light switch that's in the UP position, the light switch gets
>turned on.
>
>Ropes, belts, and pulleys complicate the job of doing this in Morphic, though
>my Connectors could probably be used.
>
>Many objects have different appearance for different states (like a mouse
>wheel that's turning or not).
>
>What I envision is a system that would provide some pre-built objects, and a
>way to make new ones using the EToys system.
>
>The part I'm puzzled over is how to represent the interaction in an
>EToy-friendly way. Each _kind_ of object can potentially interact with each
>other _kind_ of object. These interactions would probably be best to be
>inherited. I don't know how much support for inheritance there is in the EToy
>system, though (it appears that you can duplicate a Morph with its scripts,
>but I don't know how to inherit).
>
>One idea that I had was to make a 2D spreadsheet-like Morph whose row and
>column headings would be the names of the individual Morphs in the master
>parts bin, and the cells would be buttons that would open a script editor for
>each possible interaction (Pinwheel>>interactWithFan: aFan and/or
>Fan>>interactWithPinwheel: aPinwheel). Of course, most of these would be
>no-ops.
>
>But it doesn't look like the scripts can take parameters. This could be taken
>care of by assigning a slot (otherObject or something) when evaluating
>interactions.
>
>I figure that this would be a great way to teach about (for instance) force
>and acceleration, as well as providing a fun system to play with.
>
>Has anyone done something like this or thought about doing it in any detail?
>
>--
>Ned Konz
>currently: Stanwood, WA
>email:     ned at bike-nomad.com
>homepage:  http://bike-nomad.com


--