Lots of concurrency

Jerry Balzano gjbalzano at ucsd.edu
Fri Oct 26 22:40:00 UTC 2001


[A.Kay:]
>>       (This is where an experimental language we made -- called Tableau
>>-- came from. It was later made into a language calledKidSim, then Cocoa,
>>then StageCast. However, this way of doing things was pretty limited and
>>we abandoned it early. I still don't think the StageCast route is really
>>the way to do the before-after programming.)
>...
>
[D.Smith:]
>I found Cocoa on the Apple Research web site one day and I had a lot of
>fun playing with it one weekend. Its limitations were obvious but I was
>surprised how much one could do with it. I wrote a maze crawler (using the
>'hold one finger to the wall at all times' algorithm) among other things.
>The programming model was really different, though it didn't scale and was
>far too concrete.
>
>It's too bad there isn't some way to go back and run old software like one
>can go back and read old journals or books. Cocoa needs to be experienced
>for a day to really get a feel for the strengths and weaknesses of the
>approach.

----

This seems like a good place for me to insert my own experiences with
Cocoa/Stagecast.  I have spent a significant amount of time over the past
three years working with (mostly middle school, some elementary) kids in an
after-school "game design" context where the main software used is
Stagecast Creator, the Tableau-KidSim-Cocoa descendant Alan mentions.  It
uses graphical rewrite rules and programming by demonstration and uses a
metaphor of *characters* on a *stage* who carry out behaviors according to
*rules*.  My experiences have been very positive and kids keep coming back
and learning how to do more sophisticated things, e.g. using variables
intelligently.  Under its current implementation I don't think the program
is as limited as Alan suggests (altho I may be mind-reading here), but
there is a problem (one that Alan mentions himself in an earlier post about
Playground) that you need to be "clever" to solve problems in it that are
at all complex.  These "clever" solutions can be very simple, but that
doesn't mean that most novices would ever come up with them on their own.
This in itself is not a problem, however, if one is "building a culture"
where expertise is distributed and where various programming "tricks" come
to be part of the lore.

I should also mention that with the if-then/production-system form in which
all rules in Creator are written, kids do tend to become relatively fluent
in the kind of "conditional evaluation" thinking that a number of
contributors have suggested is (a) hard and (b) infrequently observed.

There is a very simple game that I teach kids to build in Stagecast that I
was in fact wondering how to do in Squeak.  I call it "Food Fight"; it
involves two players, each of which is represented by a character that can
move up and down along either the left or right edge of the stage (screen).
Each character can "throw" a food item (say a hamburger for player A, a
taco for player B) that travels across the screen and if it hits the
opposing player, that player gets one "life" subtracted from its total.
When a player loses all its lives it disappears.  Each player has a limited
number of food items and a limited number of lives, and the winner is
either the last player left standing or the one with the most lives left
when all the food ammo is gone (lives left and food left are displayed on
screen at all times).

It is very natural for kids to think about all these things happening more
or less in parallel in this game: player A moving, player B moving, player
A shooting, player B shooting, food traveling, food hitting other player,
score updating.  And a large number of kids succeed in creating this game.
(It also absorbs some of the natural tendency of kids -- esp boys -- to
want to make "shooting" games and transforms it into a "food fight" instead
of something more violent.)

Is a game like this easy to create in Squeak?  It seems like it ought to
be, but I seem to remember reading somewhere that "keyboard focus" is
generally held by one morph at any given time.  How then would one handle
the problem of allowing each player to have different "move" and "shoot"
keys where different morphs are "looking for" different keys all the time,
at the same time?

If there were some way that an explanation/mini-lesson on a squeak version
of this game could be provided by one of the kind folks in this discussion,
and also perhaps serve as a more kid-friendly example of concurrency, that
would certainly "feed two birds with one burger" for me!

Thanks for listening, and for a very stimulating set (sequence?) of messages.

			- Jerry Balzano

-------------------------
Dr. Gerald J. Balzano
Teacher Education Program
Dept of Music
Laboratory for Comparative Human Cognition
Cognitive Science Program
UC San Diego
La Jolla, CA 92093
(619) 822-0092
gjbalzano at ucsd.edu






More information about the Squeak-dev mailing list