Lemmings was the original inspiration for BusyBodies. Puzzles in Lemmings make a very nice analogy for software. Lemmings flow through the level one by one, much like data in a foreach loop. Several elements of the game act like instructions. By giving a Lemming a task, you are programming an agent, albeit in a simple way. But more interesting, the different environmental elements, which can be modified by the player, act as statements.
For example, there is a crack in the ground, each lemming will fall into it. That's roughly equivalent to putting Lemming.Die(); in your foreach loop. But by adding a bridge, you change that statement into a Lemming.!MoveForward();. Thus, the goal of the game, in some sense, is to construct the body of that loop such that every Lemming will survive.
Links: trailer for PSP version, original trailer
Exit, Pikmin, The Incredible Machine, and the original Prince of Persia apparently share some similarities with Lemmings, and may be cousins to BusyBodies, but I have not played any of them. The Incredible Machine appears to have a very similar gameplay mechanic to Lemmings, although with more complicated environments and without the added difficulty of needing to rely on Lemmings to modify the environment.
Links: Exit
Scratch is an easy to learn programming environment for kids. It is game-like in some ways. However, it's basically just a visual programming language. It really is a programming language like any other.
The KidSim project, in trying to solve the end-user programming problem, "decided that the question is not: what language can we invent that will be easier for people to use? The question is: should we be using a language at all?" This is very much in line with my strategies. But they go on to suggest that the solution is to use GUI principles instead, which is a rather different approach than BusyBodies.
They speak in praise of Bill Budge's game, "The Pinball Construction Set", which allows players to drag functional bits of a pinball game around. The KidSim authors call this "programming by direct manipulation" which is precisely what BusyBodies is. They point out that the pinball game is useful only in a very narrow domain and that increasing the generality of such a system without decreasing the ease of use is a challenge.
The approach KidSim takes is rather different than the pinball system. In KidSim, users create a simulation by demonstrating simple rules that graphical objects are to follow. This approach is called "programming by example" or "programming by demonstration" (PBD), and they suggest that it results in "languageless programming", however, they do not address the possibility that there are examples of languageless programming other than PBD.
Interestingly, despite labelling their approach "languageless programming", they describe the graphical rewrite rules created by users as "production systems", terminology which descends from the field of Linguistics, where "production" refers to a grammatical rewrite rule within a formal language. Thus the programs created in KidSim are linguistic in a very traditional sense, differing from programming languages only in the fact that at the user interface level, KidSim programs are visual rather than textual
StageCast Creator is the modern, commercial result of this work.
The creators of KidSim identified two problems with their approach: "(a) The 'rule-generality' problem--pictures, being inherently literal, are difficult to generalize to apply to multiple situations; and (b) The 'rule-semantics' problem--it is difficult to specify how the computer is to perform the transformation from the left to the right side of a rule.'
I agree that both of these represent problems, but I question their assessment of the cause of the rule-generality problem, and I question their formulation of the rule-semantics problem.
I think one of the limitations of their approach comes from their approach to use the graphical production rule as their basic programming structure. This makes the system relatively easy to learn, but it leads to two serious problems. First, since users have only one atomic programming structure, they have to invent all other forms of logic on their own. This makes it quite difficult for users to create more complex programs. Second, because of the rule-semantics problem the KidSim authors describe, the behavior that governs the graphical production rules is actually rather complex. This is a core problem with programming by demonstration: the software must infer the intention of the user, a difficult process which is prone to error.
Links: KidSim Paper, StageCast web page
MicroWorlds offers kids a graphical environment in which Kids can program a wide variety of simulations. For example, they might simulate a the physics of a rocket lifting off, or the statistics of rolling a set of dice. Programming is done with the Logo language.
Links: Web site, Screenshot, Screenshot
The Programmable Bricks project is another descendant of the Logo project, focused on bringing programming for kids out of the computer into the real world. It allows users to write programs using a traditional textual language or a graphical language like the one in Scratch. These programs can then be uploaded to a "programmable brick" which is a small computer that connects to various sensors, servos, lights, speakers and other objects. One particulary prolific example of the Programmable Bricks concept is Lego Mindstorms, but other examples, like Crickets exist as well.
Links: Crickets web site, Commercial version of Crickets, MindStorms web site, Lego Mindstorms NXT Screenshots
Electronic Blocks seem at first blush to be a dumbed down version of Programmable Bricks. However, they provide one very compelling difference which has been a significant inspiration for BusyBodies. Unlike the Programmable Bricks, which require a program to be written on a computer and uploaded, Electronic Blocks are self-contained, fully programmed digital objects. The user constructs programs by plugging the Electronic Blocks together in different configurations. By plugging a light sensor into a block representing the logical operation "NOT" and then plugging that into a car block, the user creates a car which moves only in the absence of light.
Although there is code which is contained within the blocks themselves, the "program" being manipulated by the user exists as a configuration of blocks. By declining to separate this "program" from the context in which it is runing, Electronic Blocks is unique amongst programmable toys. This strategy, of keeping the user's program in the user's domain of interest is a potential strategy for making programming more engaging and easier to understand. It remains to be seen whether Electronic Blocks succeeds in meeting this goal.
LogiBlocs is a commercialized toy which seems very similar, with a few additional sensors and other add-ons.
2001, Peta Wyeth, Helen C. Purchase
Links: Electronic Blocks, Paper, LogiBlocs
The Lego Intelli-Train is a tangible toy train which reacts differently to different configurations. It adjusts speed depending on which conductor is driving. "Code brick" can be snapped into the track to cause the train to toot, reverse, stop, stop to pick up passengers, or stop to fuel.
Links: mentioned in this paper
Where the MindStorms project provides virtual programming tools that control tangible objects, the AlgoBlocks system provides precisely the opposite: tangible programming tools that control virtual objects.
Tangible Programming Bricks are a set of stackable lego-esque bricks, each of which has a specific function. In this respect, it is extremely similar to Electronic Blocks, though Electronic Blocks are somewhat simpler.
Early versions of Programmable Bricks were oriented towards making imperative programs--sequences of commands, like those that are created in the Logo langauge. McNerney later decided that a different language, called the "Digital Construction Set", which is "inspired by the functional programming concepts of combinators and streams, and introduces the concept of sequencers," proved more effective. He advocates using functional programming concepts for tangible programming in general, seemingly because the message-passing nature of functional programming maps well to physical object that are chained together, where there is no central executive.
Links: Web page
Sketch-a-move is a design project, culminating in a video prototype, which demonstrates a toy car which responds to pen input on its roof. When you drawing a path on the roof of the car, the car traces that path in real space. It is very similar to Curlybot, and like Curlybot I think it could be part of a tangible programming system. It's just a neat, rich behavior for a tangible object.
Links: Web site
Curlybot was another one of the very early influences on BusyBodies. It is a dead simple robot that records its own motion when its button is depressed, and then plays that motion back when the button is released. With this very simple mechanism, you can create a variety of interesting behaviors. When coupled with a pen, Curlybot can draw some neat computer art.
What really got me thinking was when I started thinking about using multiple robots like this together. I thought of giving construction toys this sort of behavior, and letting kids use those toys in concert to orchestrate complicated group behaviors. But the trouble with scaling up the complexity with tangibles is that it's really hard to develop this kind of technology. It's often orders of magnitude more troublesome than writing the same stuff in software. With BusyBodies I opted to do everything virtually, but I still have my eye on the physical space.
Links: Web site
Timothy McNerny, MIT.Wrote what I consider to be the definitive paper on physical languages. Web site
