Smith, David C., and Cypher, Allen. "KidSim: Child Constructible Simulations". In Proceedings of the Imagina '95 Conference, Monte-Carlo, February 1995, pp. 87-99.
Although most simulations today allow users to modify some of their parameters, they do not permit users to modify their fundamental behaviors and assumptions. These are built in and can be changed only by professional programmers. This inflexibility makes them too rigid to support many teachers' curriculum goals, and so many school teachers do not use them in the classroom. Simulations which do allow fundamental modification invariably require extensive programming skills. Few children or teachers can or want to do it.
What's needed is a way for children without programming knowledge to have complete control over the behavior of simulations. What's also needed is a way for teachers to tailor simulations to advance their curriculum goals. KidSim provides a way to do both. In KidSim, children define simulation behavior by programming the objects in the simulations, but they do so in a new way, what we call "languageless programming." In essence our approach is to apply the good user interface principles developed during the 1980's for personal computers to the process of programming. The key innovation is to combine two powerful techniques: graphical rewrite rules and programming by demonstration. Programming by demonstration builds programs in the background while children manipulate simulation objects as they would normally. Graphical rewrite rules provide a representation for programs that is understandable to children. The combination appears to provide a major improvement in kids' ability to program simulations.
* The copy box is a source for new simulation objects. Each time an object is dragged out of the copy box, KidSim makes a copy of it leaving the original unchanged. Thus the copy box has an infinite supply of objects.
* Each simulation object has a viewer which displays the rules for its behavior, its symbolic data in the form of name-value pairs, and buttons that allow it to be manually controlled.
* The rule editor is the environment in which users define and modify rules to control an object's behavior.
When
creating a rule, the left and right sides of a rule are initially the same; all
rules start out as identity transformations. Users define the semantics of a
rule by directly editing its right side. KidSim records the editing
actions in a form that can be reexecuted later. This is "programming by
demonstration" (see below).
When running a simulation, a rule is said to match if its left side conforms to some region of the game board. When a rule matches, KidSim executes its recorded actions, its "program." The effect is that the region of the board which matched the left side is replaced with the scene in the right side.
Graphical rewrite rules are a form of "if-then" rules, which are at the heart of "production systems." There is a long history of production systems in Artificial Intelligence ([4], [6], [7]), mainly as the control structure for expert systems. However, expert system rules are not graphical and have proven to be difficult for nonprogrammers. Typically expert systems require an intermediary--a programmer--to sit between the computer and the user, translating what the user says. The goal of KidSim is to get rid of this intermediary.
There have been a number of programming by demonstration (PBD) systems prior to KidSim. The major ones are listed in [3]. A problem for PBD systems is how to represent recorded programs in a way that users can understand. Often PBD systems show programs as scripts in some language syntax. But it doesn't work to let people define programs in a way they can handle--by demonstration--and then force them to learn a programming language to examine them.
The main KidSim innovation is combining programming by demonstration with graphical rewrite rules. When combined, each solves a problem in the other:
First we create a new object in the copy box by clicking on the "tube of clay"
symbol next to it. This squeezes out a "lump of clay"
,
i.e. a new object, into the copy box. The idea is that out of clay, you can
make anything. The drawing editor automatically appears so that we can make the
new object look like something other than clay. We'll make it look like a clown
fish:
Once we have a drawing we like, we close the drawing editor window, and the object in the copy box appears as a clown fish. We now drag out a couple of fish and scatter them around the game board.
We can run the simulation by clicking on the Run button under the clock:
.
But when we do, nothing happens because we haven't defined any behavior for the
fish. So now let's get to the heart of KidSim: how to program the behavior of
simulation objects. We click on one of the fish in the game board. KidSim
displays a "viewer" for that fish. This shows its rules (there aren't any),
traits (symbolic data), and buttons.
We click on the New Rule button to begin defining a new rule. This causes
several things to happen. (a) KidSim enters "record mode." (b) The rule editor
appears, as shown in the lower right corner of figure 5.
(c) The game board
darkens and shows the discrete spaces into which it is divided. This provides
feedback that the system is in record mode and helps children communicate their
intentions to the computer. (d) The area around the fish being modified is
shown brighter. We call this area the "spotlight"; it focuses the user's
attention on the object being dealt with. We can adjust the size of the
spotlight by dragging the small handles provided. The spotlight defines the
area of the game board with which this rule will deal. The area in the
spotlight appears in both the left and right sides of the rule in the rule
editor.
Now, any actions we do on objects in the spotlight or in the rule editor or on properties in a viewer will be recorded as part of the program for this rule. Let's make a simple "move" rule. First we'll make the spotlight include the space to the right. Any change to the spotlight size is reflected in the rule:
Then
we'll edit the right side of the rule. Since all we want to do is move the fish
to the right, we simply grab the fish with the mouse and drag it into the
square to the right:
Then
we click on the Done button. That's all there is to it. Nowhere did we type
IF-THEN-ELSE, or BEGIN-END, or semicolons, or any other language syntax, and
yet we've modified the fish's behavior. We edited the right side of the rule
until it looked the way we wanted it. This is the essence of programming in
KidSim: programming by direct manipulation editing. The system records
the editing actions in the program for this rule. This graphical rewrite rule
may be read as follows: "if a clown fish has an empty space to its right, then
move into that space."
Now when we start the clock, the clown fish we just modified and all clown fish on the game board start moving to the right. The reason all clown fish move is that we have found that children expect that things that look the same will behave the same. Thus we have changed our rule paradigm from associating rules with individual objects to associating rules with classes of objects. The "class" object is the one in the copy box. Copies made of it are instances of that class.
The KidSim convention is that on every clock tick, every simulation object on the game board gets a chance to run. KidSim starts at the top of each object's list of rules, tries each rule in order, and executes the first one that matches. As soon as one rule executes, that object's turn is over. On its next turn, KidSim starts over at the top of the object's rule list. Thus iteration is built into KidSim's rules. We have already seen that conditionals are also built into them: IF the left side of a rule matches, THEN execute the recorded program used to produce the right side.
Now let's create some other things that occur in the ocean: some other types of fish, some sharks, and some kelp. We do this just as before, by creating new objects (lumps of clay) and then drawing their appearance. Then we drag out a few copies of each:
When we run the simulation now, we see that only the clown fish move. We have not yet given the new objects any behavior. We define "move" rules for them as we did for the clown fish. If we want another fish to have exactly the same "move" rule as the clown fish, we can drag the "move" rule out of a clown fish's viewer and drop it on the other fish. KidSim will copy the rule and insert it in the destination object's list of rules. This makes it easier to spread behavior around. Here, for variety, we'll make each type of fish swim differently; some will swim up and down, some diagonally, and some the opposite direction. This will increase the likelihood that fish will encounter each other. (These steps are not shown.)
Being Americans, we'll start with the violence. Let's have sharks eat other fish. We'll define an "eat" rule for sharks. First we put a blue shark next to a clown fish, where it can reach it. We click on the shark to display its viewer and then click on its New Rule button to create a new rule and put the system into record mode. We expand the spotlight to include the clown fish:
This
enables the shark to detect a clown fish when it is right in front of its nose.
If we wanted the shark to be able to detect it when it was farther away, we
could expand the spotlight and place the clown fish farther away. To get it to
eat the clown fish, we "vacuum it up" with the Vacuum Cleaner. The Vacuum
Cleaner is the way we delete things in KidSim. We drag it over and drop it on
the clown fish:
Now
the clown fish is gone. (Actually it's still in the system, in the Vacuum
Cleaner's bag. We can drag it back out later if we choose.) At this point, what
we really want is to create a blood-curdling animation of a shark ripping into
the clown fish's flesh with appropriate bone crushing sounds, and it will
eventually be possible for a child to define such an animation; but it's not in
KidSim yet, so we'll skip that part. The last thing we'll do is move the shark
into the space occupied by the clown fish. The illusion is that the shark eats
the fish:
Actually,
we want sharks to be able to eat any kind of fish, not just clown fish. If we
click on the clown fish in the left side of the rule, a pop-up menu appears
showing its type classification.
We
used to allow an arbitrarily deep type hierarchies--e.g. clown fish, fish,
ocean dweller, animal, living thing, object,--but we found that children
couldn't construct these hierarchies. The process was too complex. They could
understand class hierarchies, but they couldn't create them. Try
as we might, we couldn't find a simple way for children to do it. So we
eliminated them. Now every object has a fixed three-level hierarchy: this
particular clown fish (instance), any clown fish (class), or anything (object).
There is a way to define additional classifications in KidSim, but that is
beyond the scope of this paper. So for now, we'll just change the
classification to "anything." This rule will now match any object, i.e. the
shark can now eat any object that appears next to it. (While this is not
exactly what we want, it's actually not that unrealistic, given what has been
found in the stomachs of sharks over the years.)
We're done with this rule, so we click on the Done button. Now when we run the simulation, blue sharks start eating anything they come across. If we want hammerhead sharks to do the same thing, we can drag the blue shark's "eat" rule onto a hammerhead shark. At any rate, objects now start disappearing from the simulation. If we run it long enough, most objects will eventually get eaten. We need a way to generate more objects in order to maintain a steady state. Clearly it's time for sex!
Let's define a rule that causes clown fish to mate. Whenever two clown fish are close to each other:
the
one on top will "mate" with the one below, producing a baby fish. We make birth
happen by dragging one of the fish, say the bottom one, out of the way, and
then dragging a baby fish out of the copy box:
Just
as vacuuming is recorded as a delete action, dragging from the copy box is
recorded as a create action. Every time this rule executes, a new baby fish
will be created. (Somewhat easier than what people go through.)
Now we have clown fish fighting back, creating new baby fish to counteract the sharks' eating. The only trouble is that a baby fish is not a clown fish. We need to make baby fish grow up and mature into clown fish.
The first thing we'll do is give baby fish an "age" property. We turn to the "traits" (properties) page of the baby fish's viewer. We create a new property in it by clicking on the New Property button. We'll call the new property "age" and give it a value of "1":
To KidSim, numeric properties have no units; but we may think of numbers as being in any units we please, whatever seems appropriate for the current simulation. Let's think of a fish's age in terms of weeks. Properties in KidSim are equivalent to instance variables in traditional object-oriented programming languages. We've modeled their appearance after the boxes in Boxer [5], a language which has proven to make it easier for children to learn about variables.
First we need a rule that increments the baby fish's age on every clock tick. As before, we create a new rule for it by clicking on the New Rule button. This time we aren't interested in the matching part of the rule; we want the rule to always match. So we leave the spotlight alone, just big enough to cover the baby fish. What we want is to record a change to the baby fish's age property, namely we want to increment it by one. Since the
system
is in record mode, anything we do to an object's properties will be recorded.
So all we have to do is change the "1" in the age property to "2". Ordinarily
KidSim would record "put 2 into baby fish's age." But we have found that
incrementing and decrementing by one are the most common arithmetic operations
on numeric properties, so as a heuristic, KidSim instead records "add 1 to baby
fish's age." We can change this if we don't like the choice, but here it's what
we want. More complicated arithmetic calculations involving multiple properties
from multiple objects in multiple steps can be performed with the Calculator.
Since all we wanted to do was change the age property, we're done with this rule, and so we click on the Done button. Now on every clock tick, every baby fish's age property is incremented by one. That is, all baby fish now grow older.
The alert reader will notice a problem. Since an object's turn is over as soon as any rule matches, and since a baby fish's aging rule will always match, all baby fish will be able to do is grow older. They won't be able to move or eat or avoid sharks or anything else. However, there is a way in KidSim to mark rules of this sort so that they do not stop the rule interpreter. That is, a marked rule may match and execute, and the rule interpreter will still continue testing other rules. (The marking process will not be described here.) We'll mark the aging rule. Now baby fish will not only age but perform other actions as well.
The final thing we have to do is have a baby fish turn into a real clown fish when it is old enough. So we'll create a rule to do that. (That's the universal answer to solving problems in KidSim: create a rule.) We click on the baby fish's New Rule button, which puts the system in record mode. Again, we aren't interested in the pattern matching part of the rule, so we leave the spotlight alone. But this time we want to test one of the baby fish's properties. Specifically, we want this rule to apply only when the baby fish becomes 20 (weeks) old. We click on the triangle under the left side of the rule, causing a property test area to appear:
We
drag the baby fish's age property into the left side of the test and type 20
into the right side. We then choose "=" from the pop-up menu in the middle:
This
rule may be read as follows: "if the baby fish is on the board, AND IF the baby
fish's age property equals 20, then...." Now we have to tell it what to do.
What we want is for it to turn a baby fish into a clown fish. First we drag a
clown fish out of the copy box. Then we copy any data we want to preserve, such
as its name, into the clown fish. We do this dragging properties or property
values from the baby fish's viewer into the clown fish's viewer. Finally we
vacuum up the baby fish. The effect is that the baby fish becomes a clown fish.
Lastly, we click on the Done button to end the rule.
Now, as we run the simulation, clown fish periodically encounter each other and spawn baby fish. If we start with enough clown fish, they should be able to keep up with the rate that sharks eat them, producing a steady state population. If we start with too few, they may all get eaten.
We can go on from here and investigate a variety of possibilities. For example, what happens if we make sharks able to detect fish farther away and thus eat more efficiently? What happens if we make clown fish have two babies, or ten, instead of one? What happens if we make the babies mature faster or slower? What happens if we give clown fish a defense mechanism, e.g. hiding in sea anemones as in real life? What happens if we add an energy level to sharks and fish so that they have to eat regularly or die? We might have to create plankton for the smaller fish to eat and set up a food chain. We can let our imaginations drive the simulation in directions that, while possible with conventional programming languages, were not practical before.
The point is that this is a moderately interesting and flexible simulation that was created by actions that you the reader are perfectly capable of doing. At least we hope you feel that way. It did not require any long learning time or studying a manual. And we hope you feel that children and their teachers could, for the first time, create such simulations.
2. Cypher, A. and Smith, D.C., KidSim: Programming Simulations by Demonstration, to appear in CHI `95 Conference Proceedings, ACM Press, New York, 1995.
3. Cypher, A., ed. Watch What I Do: Programming by Demonstration, MIT Press, Cambridge, MA, 1993.
4. Davis, R. and King, J. An Overview of Production Systems, Computer Science Department Report No. STAN-CS-75-524, Stanford University, 1975.
5. diSessa, A.A. and Abelson, H. Boxer: A Reconstructible Computational Medium, in Soloway, E. and Spohrer, J. Studying the Novice Programmer, Lawrence Erlbaum Associates, Hillsdale, NJ, 1989, 467-481.
6. Newell, A. and Simon, H.A. Human Problem Solving, Prentice-Hall, Englewood Cliffs, NJ, 1972.
7. Rychener, M.D. Production Systems as a Programming Language for Artificial Intelligence, Ph.D. dissertation, Department of Computer Science, Carnegie-Mellon University, 1976.
8. Smith, D.C., Cypher, A. and Spohrer, J., KidSim: Programming Agents Without a Programming Language, Communications of the ACM, 37, 7 (July 1994), 55-67.
9. Smith, D.C., Irby, C., Kimball, R., Verplank, W. and Harslem, E. Designing the Star User Interface. Byte, 7,4 (April 1982), 242-282.
back to ... Publications 
Allen Cypher