Jerry --

Some of the things I didn't like about StageCast were:
   *  its abrupt change in metaphor from pattern matching to what is 
in effect a different language to handle more complex situations 
(somewhat in the same spirit of the initial magic of Prolog 
degenerating into having to understand the depths of how the 
inference engine works just as things get interesting). It's nicer 
when the learning curve is more gradual and without big cliffs to 
fall over.
   * the almost universal tendency of the children to reorder rules 
randomly because sometimes this helps (guessing and superstition are 
not really how you would like to see children debugging -- this is 
too much like most adult programmers!!!).
   * not enough routes for solving problems + the requirement to be 
"too clever too early" -- we would rather try to build a culture of 
understanding vs a culture of tricks. (This was also one of our 
criticisms about Playground as well.)

The food fight game sounds like fun. It's easy to do in Squeak. The 
limitation right now in Etoys is just that there is no real facility 
to deal with keyevents in the Etoy system itself -- but this is 
pretty easy to put in (and we should fix this).
      However, Mike Rueger did put support in for multiple physical 
joysticks, and -- even more weird in a sense -- is that you can have 
as many SW joysticks as you want in Etoys. This means that your game 
can easily be programmed right now to be played via Nebraska (with n 
kids and n computers both on the Internet and sharing a screen -- n = 
4 would be fun -- you could use all four sides of the screen).

Cheers,

Alan

-------

At 3:40 PM -0700 10/26/01, Jerry Balzano wrote:
>[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


--