Notice: Undefined property: stdClass::$theme in /usr/local/src/drupal-5.1/includes/ on line 45
OLPC | Don Hopkins


warning: Creating default object from empty value in /usr/local/src/drupal-5.1/modules/taxonomy/taxonomy.module on line 1364.

SimCity for OLPC (One Laptop Per Child): Applying Papert's Ideas About Constructionist Education and Teaching Kids to Program

Here are some ideas about applying Seymour Papert's philosophy of "Constructionist Education" to SimCity, by integrating it with the OLPC's "Sugar" user interface and Python-based scripting system.

Back in the early 90's, I ported the classic version of SimCity to Unix, first implementing a PostScript-based user interface for the NeWS window system with the HyperLook gui environment, then a multi-player TCL/Tk based user interface for the X11 window system, for the Sun, SGI, NCD and other X11-based systems.

I've updated the TCL/Tk/X11 version of SimCity to run on the latest version of Linux, and I'm in the process of adapting it for the OLPC. I got permission from Will Wright to show the unreleased development version of OLPC SimCity at the 2007 Game Developer's Conference (GDC). OLPC News wrote an article about SimCity on the OLPC XO, and Gamasutra reported that SJ Klein Asks For Serious OLPC Content at GCD.

SJ said that the OLPC project is looking not just for games, but for tools that enable kids to program their own games. "Existing games are nice, and cute," but games for things like learning language are the "gem they're targeting." Most importantly, Klein said in a direct plea to the serious game developers in front of him, the project needed frameworks and scripting environments -- tools with which children themselves could create their own content.

The TCL/Tk scripting languages and user interface toolkit was a great choice for X11 at the time (around 1992), and it still runs fine because the code is self-contained and X11 hasn't changed in all that time. But it would be wonderful to re-implement SimCity with a modern, powerful scripting language like Python, and create a kid-friendly user interface and scripting API, focused on Constructionist Education, and teaching kids creative writing and programming language skills.

The HyperLook version of SimCity had some cool features like map zooming and editing at any scale, and a user-customizable hypercard-like interface, that weren't easy to implement in TCL/Tk/X11 at the time. But fortunately, the OLPC's Sugar user interface takes advantage of Cairo and Pango for rendering graphics and text, which are better than PostScript!

The first step in integrating SimCity with Sugar is to clean up and modularize the C simulator code, and plug it into Python (which is a much more powerful scripting language than TCL, and the standard language for OLPC programming).

Sugar is based on Python, and uses the GTK toolkit, Cairo rendering library, Pango international text layout library, and Hippo drawing canvas, and many others useful modules. Once SimCity is integrated with Python, it will be great fun to create a kid-friendly multi-player user interface that's totally integrated with the OLPC's unique hardware design (like the hires mono/color LCD screen, which flips over into book mode with a game controller pad) and Sugar's advanced features, like scalable graphics, journaling, mesh networking, messaging, collaboration, and (most importantly) applying Seymour Papert's philosophy of "Constructionist Education" to SimCity.

The goals of deeply integrating SimCity with Sugar are to focus on education and accessibility for younger kids, as well as motivating and enabling older kids to learn programming, in the spirit of Seymour Papert's work with Logo. It should be easy to extend and re-program SimCity in many interesting ways. For example: kids should be able to create new disasters and agents (like the monster, tornado, helicopter and train), and program them like Logo's turtle graphics or Robot Odyssey's visual robot programming language!

The long term goal is to refactor the code so it can be scripted and extended in Python, and break out reusable general purpose components like the tile engine, sprite engine, etc, so kids can use them to build their own games, or create plug-ins and modify the graphics and behavior of SimCity.

The Cairo graphics based user interface will let you zoom into the map like Google Maps, overlay scalable information visualizations, drawings and text. The journaling interface will extend the SimCity save files with a blog-like history of events in the city timeline, enable players to write their own time-stamped and geo-coded stories about events on the map, and let you fast forward, rewind and branch time like a virtual TiVo. The mesh networking interface will let you share cities and play with friends over the network, vote on plans and issues, tell stories and publish journals/newspapers/blogs/maps about your cities.

Other Sugar developers are building visual programming interfaces that can be eventually be used to script the behavior of SimCity plug-ins!

Bil Simser blogs about Micropolis source code and gui

Bil Simser has been writing some great stuff on his blog about building the Micropolis source code.

And he's even been developing a user interface in Python around the MicropolisCore module.

I have been working on a scripting language independent callback system, and removing the old X11 and SimView dependencies from the code, so you can call the editing tools from the scripting language. Bil will be hooking that stuff up soon.

The idea behind the scripting language independent callback mechanism is so that the Micropolis engine can generically call back out to "virtual" functions that can be written in a scripting language, or handlers built into the application, without being tied to any one particular scripting language or user interface toolkit.

I've done all the plumbing with C++ and SWIG to integrate MicropolisCore with Python, which can be used as an example for integrating it with any other scripting language that SWIG supports (and there are many). So the same MicropolisCore simulation engine can run in a web server as well as a laptop application, and it will be easy to port to other platforms like desktop computers or handheld devices, and languages like Lua or Java.

Micropolis (SimCity) source code available on Google Code

I've checked the Micropolis (SimCity) source code into the Micropolis Google Code Project.

The subversion repository contains two different projects based on the original SimCity source code from Maxis:

  • micropolis-activity:
    Source code of TCL/Tk Micropolis for the OLPC XO-1 and Linux.
  • MicropolisCore:
    Source code of three Python modules: micropolis, cellengine and tileengine.
    • The micropolis module is the new version of Micropolis (SimCity), cleaned up and recast as a C++ class.
    • The cellengine module is a cellular automata machine engine.
    • The tileengine module is a Cairo based tile renderer, used to display micropolis tiles and cellengine cells. It plugs into micropolis and cellengine, but is independent of them and useful for other applications.
    • These modules require Python 2.5 and the Python modules pygtk, pycairo and PIL to be installed. Probably some other modules I can't think of off the top of my head, too.
    • This code will compile on Windows or Linux. It is intended to be used with the OLPC's Sugar user interface environemnt (depending on Cairo and Pango for graphics and text formatting), but layered so the core code is useful in other contexts such as different scripting languages, web servers, desktop applications, embedded devices, etc.

SimCity Rules

From: Alan Kay
Subject: Just curious ...

Has anyone tried to articulate the SimCity rules (e.g. in English sentences)?



From: Don Hopkins
Subject: Just curious ...

I'm interested in writing some English documentation about how it works. But it would make sense to write a high level overview, more like a tour than a reference manual, and describe the behaviors and interactions of the different kinds of tiles and agents and layers and global computations. There is certainly a lot of ad-hockery involved!

Some muckety-muck architecture magazine was interviewing Will Wright about SimCity, and they asked him a question something like "which ontological urban paridigm most influenced your design of the simulator, the Exo-Hamiltonian Pattern Language Movement, or the Intra-Urban Deconstructionist Sub-Culture Hypothesis?" He replied, "I just kind of optimized for game play."

There are also a lot of smarts in the SimCity editing tools, which maintain the integrity of the tile patterns on the map. Like the way roads and railroads combine into intersections when they cross, turn into bridges over water, and tiles are combined into bigger 3x3, 4x4 and 5x5 zones, and stuff like that. Those behaviors are similar to cellular automata rules, but less structured and regular. Kind of like what you could do in KidSim.

KidSim / Cocoa / StageCraft Creator let kids define visual cellular automata rules by example, based on tile patterns and rules. Show it a pattern that you want to match by selecting an instance of that pattern in the world, then abstract it with wildcards if necessary, then demonstrate the result you want it to change the cell to in the next generation.

One of the plug-in interfaces that SimCity should support is plug-in editing tools.

Another interface is plug-in agents like the monster, tornado, helicopter, etc.

And for user interface and ease of use purposes, I'd like to combine the notion of an agent and an editing tool, instead of using a traditional "cursor" metaphore.

The agent could be controlled by the touchpad or the gamepad, and it would have a cursor-like footprint showing the area of the map it would effect.

That would make it much easier for small kids to use simple tools, and make it possible to use SimCity in book mode with the gamepad.

The multi player mode would enable a bunch of kids to pick up different tools and perform complementary functions together.

Once you have a rich library of interesting tools, there could even be a meta-game like Magic the Gathering or Pokeman cards that let kids trade and use tools and special effects (disasters, miracles, magic spells, special buildings, bribes, cheats, etc).

You could navigate the tool around the map in various ways appropriate to the tool's function.

So you could drive a bulldozer around, or drive a road building machine around, or drive a residential zone stamp-pad that had a programmed gap between houses for lower density housing, or was smart about finding a place to plop down down the house, based on a set of constraints and search algorithms.

Then you could take a generic house plopping tool, and go inside of it like a Robot Odyssey robot, and rewire its behavior to make it smarter about finding a location to plop the house (or dumber), or moving around until it found a good place.

It could call on other tools like the bulldozer tool to smash stuff underneath if it wanted to (this behavior is already built into the zoning tool to a limited extent, called "auto bulldoze mode", which automatically bulldozes "soft" tiles like grass and dirt whever you try to build something.

It could even measure properties of the map like the pollution, traffic, population density, etc, and base its navigation and decisions on any function of any parameter imaginable.

An interesting exercise would be to program a bulldozer to stop a fire from spreading, by bulldozing around the edge of the fire to create a fire block.

As we open up SimCity, we can put in user defined layers for the tools to use as storage and control, and let the user edit the numeric values in those layers, or specify rules to define their value. Like a mask layer that computes if a zone is on fire, or adjacent to a zone that's on fire, for the bulldozer to follow.

Of course that would be for advanced kids, but it would be great for making games like KidSim could do, but with the full power of Python underneath and easily accessible!


PS: Here's a summary of one of Will Wright's talk to Terry Winnograd's user interface class.

It covers a lot of interesting stuff, but unfortunately I *still* haven't typed in the stuff about SimCity yet. :(

The funny part is the description of "Dollhouse", which I wrote less than a year before going to Maxis and working on it!

A summary of Will Wright's talk, by Don Hopkins

SimCity Info

From: Samuel Klein
Subject: Just curious ...

Hey, Don, this is great stuff. I'm starting a section for such essays on the laptop wiki (see [[category:essay]]) as a preface to tours or more interactive guides.

Alan, there's a programmer who has been haning out on olpc channels who wants to help make Robot Odyssey... I'm starting a related thread on .


From: Alan Kay
Subject: Just curious ...

Hi SJ --

Robot Odyssey is another game that would benefit from having a clean separation between the graphical/physical modeling simulation and the behavioral parts (both the games levels and the robot programming could be independently separated out) -- this would make a great target for those who would like to try their hand at game play and at robot behavioral programming systems.

This is a long undropped shoe for me. When I was the CS at Atari in 82-84, it was one of our goals to make a number of the very best games into frameworks for end-user (especially children's) creativity. Alas, Atari had quite a down turn towards the end of 83 ... We did get "the Aquarium" idea from Ann Marion to morph into the Vivarium project at Apple ... And some of the results there helped with the later Etoys design.



From: SJ Klein
Sent: Monday, November 12, 2007 5:29:24 PM Subject: Game ideas for the XO: Robot Odyssey

Don and Alan have been having a great discussion about Robot Odyssey, which I'd like to share with the list. By coincidence, a discussion in #sugar today around SimCity's open sourcing turned to how to get Robot Odyssey onto the laptops... so I'd like to open the discussion to a wider audience.

Who is interested in helping develop a R.O. port, and in improving on the old implementation? Alan has some excellent ideas about how to turn the updating of the design into a useful exercise, perhaps for an eager coder or class.

Of course other nifty project ideas are more than welcome.

Don and Alan -- I think the entirety of your discussions about simulation and game design are worth sharing; if you don't mind, I'll transcribe some of them to the wiki for further elaboration.


From: Alan Kay
Subject: Game ideas for the XO: Robot Odyssey

Thanks SJ --

We are benefiting here from Don Hopkins' generosity (and of the original designers and owners of these games).

The basic notion is that there are many games that, if modularized with nice separable interfaces, would be great environments for exploring various kinds of "learning by doing". For example, there is a nice separation between the "rules/dynamics" of a games world and the "strategies/actions" of the characters. There could be a third separation to break out the graphics and sound routines as a media environment.

For example, in SimCity, the first and most useful breakout for children would be to allow various UIs to be made that would let children find out about and try experiments with the "city dynamics rules". It's not clear what the best forms for this would be, so it would be great to have a variety of different designers supply modules that would try to bridge the gaps to the child users.

This could work even for pretty young children (we helped the Open Magnet School set up Doreen Nelson's "City Building" curriculum in the third grade of the school and this was very successful -- a child controlled SimCity would have been wonderful to have).

Maybe this separation could be set up via the D-bus so that separate processes written in any language the authors choose could be used. This would open this game up to different experiments by different researchers to explore different kinds of UIs and strategy languages for various ages of children. I think this would be really cool! We would all learn a lot from this and the children would benefit greatly.

A trickier deal would be the world dynamics (I'm just guessing here, but Don would know). This is one of the really great things about SimCity -- it can really accommodate lots of different changes and stitch things together to make a pretty decent simulation without too many seams showing. (Given the machines this game originally ran on, many of the heuristics are likely to be a little patchy. Don has indicated as much.) I think doing a great world dynamics engine for games like SimCity would be really wonderful -- and could even be a thesis project or two.

Don has talked about doing the separations so that many new games can be made in addition to the variations.

Similarly, Robot Odyssey (one of the best games concepts ever) was marred by choosing a way to program the robots where the complexity of programming grew much faster than the functionality that could be given to the robots. This game was way ahead of its time.

Again, the idea would be do make a game in which environment, levels of challenge, and how the robots are programmed would be broken out into separate processes that a variety of gamers and researchers could do experiments in language and UI.

One of the most wonderful possibilities about this venture is that it will bring together very fluent designers from many worlds of computing (more worlds than usually combine to make a game) in the service of the children. We should really try to pull this off!



Python Plug-In Technologies for Extending OLPC SimCity

The TurboGears web framework, and other Python web frameworks like wsgi, use Python eggs, easyinstall, setuptools, distutils, buildutils, paste, and other systems to package code and manage plug-ins for web servers, template engines, and other components.

I've been wondering how the Python version of SimCity can expose a bunch of different plug-in interfaces, like zones, disasters, editing tools, and locate resources and compiled Python extensions associated with each plug-in, etc.

And how can the development tool and other Python based visual programming languages support programming and packaging plug-ins?

I'd appreciate it if anyone who understands that stuff could please point out some good web pages about Python plug-in frameworks, explain some of the issues and solutions available to Python programmers, or describe the big picture behind the design of setuptools, Python eggs, paste, etc!


OLPC Visual Programming Languages for Education

Simon Forman's stuff about xerblin is fascinating, and I'm excited about where it's heading, and how we can incorporate ideas from eToys into Python! I like the idea of having visual meta-languages that are compiled into Python, which avoids the problems of editing Python text or parse trees directly, and can support simplified "kindergarten" languages as well as more advanced forms.

The drag-and-drop stack and code outliner ideas work well with PostScript, which is a stack based but lispy code=data dynamic language that easily supports smalltalk-like object oriented programming via PostScript's "dictionary stack". Python + Cairo is also a great platform for implementing that kind of stuff, with dynamic layout of hybrid text and outline graphics, which scales and zooms and supports direct manipulation of data structures!

Here's a paper about PSIBER (PostScript Interactive Bug Eradication Routines), a visual interface to the PostScript interpreter in NeWS, and some links to video demos, too. Sorry about the flashing and poor compression -- they're recorded off a hires Sun monitor whose refresh rate was different than the camera, and I mercilessly compressed them a few years ago when the Internet was slower.

The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines

PSIBER Demo: (9434433 bytes) Demo of the NeWS PSIBER Space Deck. Research performed under the direction of Mark Weiser and Ben Shneiderman. Developed and documented thanks to the support of John Gilmore and Julia Menapace. Developed and demonstrated by Don Hopkins.

One problem with PSIBER was that it was too easy to make a mistake dragging and dropping, and accidentally totally hose the internals of the window system, since you were editing shared structures in the NeWS server, like classes and canvases and event handler threads! It needed some kind of read-only safety shield or edit mode switch. Like Emacs, its main purpose in life was to develop and debug itself (and secondarily other NeWS applications like HyperTIES and NeMACS)!

A regular hierarchal outliner like most gui toolkits support might be too limiting for a visual programming language. Objects might have several ways to "open" them, and links coming in as well as going out. Any object might be at the intersection of several trees or sequences at once (like the class hierarchy, and the window hierarchy, the set of instances of the same class, and an ordered list of search results).

PSIBER supported "peripheral views" that let you attach embedded visual editors and open objects in different ways. Good XML editors support a branch for element attributes as well as a separate branch for sub-elements and text. Check out the way 3D Studio Max has outlines with two kinds of branching at each level of the 3d object tree (one branch for animatable object properties, and another branch for attached sub-objects), and the way it crosses a vertical outline with a horizontal timeline. It would be nice to be able to view an object in one or more hierarchies or sequences at once (like 3dsmax's property/sub-object outline + timeline), and easily pivot the editor between different hierarchies and sequences and alternative views (narrowing it to just a timeline, or just a sub-object outline, or a free-form graph view).

I can't remember what he called his system, but Steve Strassmann did some cool stuff on Mac Common Lisp or Dylan with "butterfly diagrams" that branched out in different directions, left for incoming links and right for outgoing links.

The closest thing I could google about Strassmann's butterfly diagrams was his infamous "Is There Toscanini's Ice Cream in Heaven?" flowchart:

Marc H. Brown and Robert Sedgewick at Brown University developed a cool visual interface to Pascal called Balsa (named after a tree, of course), which supported multiple synchronized views of Pascal programs (lexical structure outline, Nassi-Shneiderman flowcharts, dynamic scope views, pascal syntax graphs, algorithm animation, etc). But it was pretty restrictive and ungainly about how you could input and edit a program (you could not do anything that wasn't syntactically correct, and I don't think it supported drag-and-drop), so you couldn't just type Pascal code into a text editor and watch the code views update in real time.

Here's a paper by Brad Myers that mentions Balsa and lots of other cool stuff like Henry Lieberman's "Tinker" Lisp programming by demonstration system:

Brad Myers: Taxonomies of Visual Programming and Program Visualization

Marc H. Brown, Robert Sedgewick: A system for algorithm animation

Henry Lieberman: Tinker: A Programming by Demonstration System for Beginning Programmers, in Watch What I Do: Programming by Demonstration, Allen Cypher, ed., MIT Press, 1993.

One problem with editing programs as text while trying to maintain a visual representation, is that typing in and editing a program as text puts the program through many syntactically incorrect states, before you've closed all your parens and balanced all your blocks, and you have a horrible correspondence problem mapping between changes in the text to changes in the structure. So it's hard to have your cake and eat it too. Even Emacs Electric-C Mode can get pretty annoying when it tries to close your parens and reindent your program for you while you're typing, if you're not trained to expect it. Of course it's much easier to attempt with languages like Lisp and Python that have simple clean syntax, rather than languages like Perl and C++ with complex byzantine syntax.


PS: Some weird videos:

Here's an incomprehensible video I recorded late at night, of the freaky "PseudoScientific Visualizer" stuff: Pseudo Scientific Visualizer Demo: (21431618 bytes) Demo of the PseudoScientific Visualizer and NeWS PSIBER Space Deck. Research performed under the direction of Mark Weiser and Ben Shneiderman. Developed and documented thanks to the support of John Gilmore and Julia Menapace. Developed and demonstrated by Don Hopkins.

HyperTIES Demo: (3562242 bytes) University of Maryland Human Computer Interaction Lab HyperTIES Demo. Research performed under the direction of Ben Shneiderman. HyperTIES hypermedia browser developed by Ben Shneiderman, Bill Weiland, Catherine Plaisant and Don Hopkins. Demonstrated by Don Hopkins.

NeMACS Demo: (3511315 bytes) Demo of UniPress NeMACS running in the NeWS Window System. Emacs development performed under the direction of Mike Gallaher. NeWS user interface developed and demonstrated by Don Hopkins.

HyperLook SimCity Demo: (49816346 bytes) Demonstration of SimCity running under the HyperLook user interface development system, based on NeWS PostScript. Includes a demonstration of editing HyperLook graphics and user interfaces, the HyperLook Cellular Automata Machine, and the HyperLook Happy Tool. Also shows The NeWS Toolkit applications PizzaTool and RasterRap. HyperLook developed by Arthur van Hoff and Don Hopkins at the Turing Institute. SimCity ported to Unix and HyperLook by Don Hopkins. HyperLook Cellular Automata Machine, Happy Tool, The NeWS Toolkit, PizzaTool and Raster Rap developed by Don Hopkins. Demonstration, transcript and close captioning by Don Hopkins. Camera and interview by Abbe Don. Taped at the San Francisco Exploratorium.

Even more weird videos:

Redesigning the SimCity User Interface for the OLPC

Visual Programming

Simplify the SimCity interface and make it easier for kids to use it with the game controller, in a way that will support multi player interaction.

Collapse the separate concepts of game editing tool (bulldozer, road, residential zone, etc) and agent (sprites like the monster, tornado, helicopter, train, etc).

Agents with specialized tool represent different roles that kids can play. A bunch of kids can join together and play different roles at the same time in the same city. Instead of having a bunch of editing tools to switch between, you have a bunch of different agents you can drive around the map, like using a monster to crush things instead of a bulldozer, or riding around in a helicopter to scroll around and observe the map. Make a meta-game like pokemon trading cards or magic the gathering, about acquiring and deploying and using agents on the map. Give agents different budgets and constraints.

Use an agent to represent a user in the world, and control an editing tool. You see other users in the map driving around their editing tool agents.

Each editing tool can be associated with a particular agent, with a keyboard/game controller based user interface for moving around, as well as a mouse based interface for picking it up and dragging it around.

The road tool becomes a road building vehicle, that you can easily move up/down/left/right/diagonally with the game controller directional input. Requires much less coordination to draw straight roads than with a mouse.

The bulldozer tool becomes an actual bulldozer that you can drive around the map, crushing things in your wake.

This makes the game easily usable by little kids in book mode.

Also support small children using SimCity like a drawing tool or etch-a-sketch, simply doodling with the editing tools for the visceral pleasure of it, and setting fires and other disasters to watch it burn and mutate.

Logo Turtles (as a generalization of the monster, tornado, helicopter, etc)

Implement programmable logo turtles as agents that can move around on the map, sense it, and edit it.

Like Robot Odyssey agents, so you can go "inside" an agent, and travel around with it, operate its controls, read its sensors, and automate its behavior by wiring up visual programs with logic and math and nested "ic chip" components.

Plug in graphics to represent the agent: use classic logo turtle and SimCity sprites, but also allow kids to plug in their own. SimCity sprites have 8 rotations. SVG or Cairo drawings can be rotated continuously.

Re-implement the classic SimCity agents like the monster, tornado, helicopter, train, etc in terms of logo turtles, that kids can drive around, learn to use, open up and modify (by turning internal tuning knobs, or even rewiring).

Let kids reprogram the agents to do all kinds of other stuff.

Mobile robots, that you can double click to open up into Robot-Odyssey-esque visual program editors.

Agents have local cellular-automata-like sensors to read information about the current and surrounding tiles.

KidSim / Cocoa / StageCraft Creator let kids define visual cellular automata rules by example, based on tile patterns and rules. Show it a pattern that you want to match by selecting an instance of that pattern in the world, then abstract it with wildcards if necessary, then demonstrate the result you want it to change the cell to in the next generation.

Sense high level information about zones and overlays, so the agents can base their behavior on any aspect of the world model.

Support an extensible model by allowing users to add more layers.

Add layers with arbitrary names and data types at different resolutions:

byte, int, float, n-dimensional vector, color, boolean mask, musical note, dict, parametric field (i.e. perlin noise or other mathematical function) at each cell, etc.

Edit the world.

All SimCity editing tools (including colored pens that draw on overlays) should be available to the agent.

Enable users to plug in their own editing tools, that they can use themselves with the mouse, keyboard or game controller, or program agents to use to edit the map under program control.

Robot Odyssey

Build your own universal programmable editing tool. Roll your own von Neuman Universal Constructor. Smart robots you program to perform special purpose editing tasks.

The "Painter" picture editing program had a way of recording and playing back high level editing commands, relative to the current cursor position.

Remixing. Journaling. Programming by demonstration or example. You could use a tape recorder to record a bunch of SimCity editing commands that you act out (or you can just select them from the journal), then you can play those tapes back with relative coordinates, so they apply relative to where the agent currently is on the map. You can copy and paste and cut and splice any editing commands into tapes that you can use to program the robot to play back in arbitrary sequences.

Program an urban sprawl development-bot to lay out entire residential subdivisions, complete with zones, roads, parks and wires. Then program a luddite roomba-bot that sucks them all up and plants trees in their place.

This becomes really fun when we let players plug in their own programmed zones for the robot to lay out, and layers of data to control the robot's behavior, out of which they can program their own cellular automata rules and games (like KidSim / Cocoa / StageCraft Creator).

Ideas about OLPC SimCity GUI, Turtle Graphics, and Cellular Automata

From: Don Hopkins

SimCity in Python will be totally programmable in Python, so what should we program it to do? And how can we refactor it into general purpose, reusable components?

Here is an outline (in the next blog posting) of some ideas I've had about simplifying the SimCity user interface and making it more fun and educational. It should be easy and fun for little kids to use, work well in book mode with the game controller, support the mouse but not require it, and enable collaboration over the network with other players.

Instead of (or in addition to) using the mouse to paint with a palette of editing tools like Photoshop, the interface could be based on agents like logo turtles that represent the user on the map, which carry around SimCity editing tools that they can draw with. When you throw in a visual programming language, it leads the way to a Robot-Odyssey-esque version of SimCity!

This is one reason I want to have a nice plug-in visual programming language!

Just for fun, and for the enjoyment of cellular automata freaks and von Neumann fans, here is a nerd toy I wrote in OpenLaszlo (a von Neumann 29 State CA editor and simulator), with a cellular automata grid editing tool that you can move around over the grid and edit the map like an agent or logo turtle, using the keyboard or mouse. It's a half-baked experimental user interface, so I'm not claiming that it isn't bizarre or doesn't suck, but it does demonstrate some ideas that might be applied to the SimCity user interface.

John von Neumann's 29 state Cellular Automata Implemented in OpenLaszlo:

Full window demo in Flash player:

Source code:

The arrow keys move the tool, space clears the cell under the tool, the letter diamonds "wasz"/"rdfc" make an unexcited ordinary/special directional arrow cell in the corresponding direction, and "WASD"/"RDFC" make excited versions of those arrow cells, other letters and numbers are for miscellaneous states, and so on. The "." key advances the current cell to the next logical state, so you can toggle the excited state of any arrow cell in a standard way without changing its direction, or cycle confluent cells through their four states. Clicking the mouse on the tool pops of a pie menu with submenus of all possible states organized by category (some of which arrange naturally into pie menus, because they are directionally oriented). Clicking the mouse anywhere else moves the tool to that cell. The goal is to be able to quickly key in a cellular automata configuration, as well as randomly accessing and editing it (even while it's running).

[I'm not going to attempt to explain how the CA itself works (just press "Run" and enjoy the blinking lights), but it's based on one of my favorite classics: John von Neumann's 29 state CA rule, which he specifically designed (on paper!) to program self-reproducing machines. The source code has some good references and obtuse comments! Sadly, the Flash player is way too slow to run enough cells to actually house a complete self-reproducing machine (and its offspring, and their offspring...) in their full glory and splendor. Fortunately I do have an efficient C++ implementation of that rule (and others), as a Python extension! Once we have a good tile display/editing engine in Python, it will be fun to hook that code up to drive it, and efficiently run huge self-reproducing cellular automata!]

For hard core cellular automata freaks: Hit "Next" a few times till you get to "Autoinitializing Exclusive Or", then hit "Load" then "Run", to see a cool self modifying cellular automata bootstrap! A special signal of 5 excited states in a row goes through first, which initializes the circuit, ignites all the pilot lights and synchronizes all its internal clocks at just the right time and phase, and then cuts off the ignition circuit (blows the explosive bolts so to speak, with construction commands) so the circuit is only initialized once, and subsequent signals flow through the normal part of the circuit. In this case, the circuit performs an exclusive-or (which is easier said than done in this rule, requiring synchronized clocks), two of which are needed to cross two signals without interfering.

The point of all this, is that machines in this CA rule can only construct other machines in the powered-off state (or they might get electrocuted ;-), so there has to be a way to turn a machine on and start all its clocks ticking by "autoinitialization" -- self modifying CA code! The self-reproduction process has two phases: first build a copy of yourself in the powered-down ready-to-initialize state, by scanning back and forth with the builder arm like an ink jet printer, programmed from a huge spiral of memory (the machine's dna). Then once you're done, dock your construction arm into the new machine's naval at the base of it's memory loop (like an umbillical cord for data), then switch into playback mode and loop all your memory back through, injecting a copy of it into the duplicate's memory loop. Then send a start signal to initialize the copy and start it reproducing itself.

This stuff was described (and illustrated ;-) in a paper by William R. Buckley and Amar Mukherjee. The examples in this demo show different ways to effect a signal crossings (with different advantages and disadvantages). Some (like the real time crossing) are not "constructible", and some have interference problems (like the coded channel crossing), and some are enormous (like two autoinitializing exclusive or's). Of course people have come up with much more efficient rules since then (and that is a fun game too), but John von Neumann's 29 state rule is classic coke, the real thing.


From: Andrew Clunis

Will SimCity itself be implemented in Python, or will there just be some kind of scripting interface to SimCity?

btw, Develop (or pieces of it) might provide the code editing functionality. In fact, Develop (possibly not until gen2) might also provide a visual code editor (flow chart-ish, or similar)

That is pretty cool! However, it might be desirable to leave in classic SimCity mouse-based editing as an option, in case someone wants to build a large map by hand with the mouse.

From: Don Hopkins

The idea is to preserve the original SimCity code (written in C) so it you can still play the original game, and expose it to Python through functions, variables, hooks and callbacks.

I might have to wrap the C code in a C++ class, so it's encapsulated and possible to have any number of the simulators running independently in memory at the same time, without using any global variables. (As distasteful as C++ is, it's good for a few things like encapsulating old C code!)

I'm planning on using SWIG to expose the SimCity interface to Python, so it will be possible to plug the same code into other scripting languages that SWIG supports as well (given some work with language-specific typemaps and convenience functions, etc).

Over time, I'd like to document how the code works, and factor out parts of SimCity into modular functions that you can call from Python, which you can override in Python to do your own stuff before, after, or instead of the original C code. Then you can replace and instrument parts of the simulator in Python (like the traffic simulation, or the economic simulation), and plug in new features (like your own scripted disasters), but still have the original simulator there if you want to run the classic SimCity. Parts of it can be rewritten in Python so they act the same but they're general purpose and easy to reprogram by subclassing, like the monster, tornado, helicopter, etc. Then you could use a visual programming language to subclass them and customize their behavior.

Absolutely: it's important to always support the original SimCity user interface and behavior!

I want to enable extensions through optional plug-ins, hooks (extension points, like "aspect oriented programming") and subclassing, and preserve the original behavior and interface, while cleaning up and modularizing the code.


Discussion with Alan Kay about Visual Programming

From: Don Hopkins
Subject: Visual Programming

The following two papers that I highly recommend cover a lot of interesting visual programming and simulation systems, which are well worth knowing about.

Kurt Schmucker (inventor of the C++ Barf Bag ;-) at Apple wrote "A Taxonomy of Simulation Software":

Tim Smith at Anglia Polytechnic University in Essex wrote "A review of simulated and micro-world environments":



From: Alan Kay

Don --

Thanks very much for these references. I was not aware of either of them and both are very useful for helping think about some of the educational environment needs for the OLPC XO.

When teaching science, we have the important conflict between empirical and model-based approach of modern science and the belief-based dogma of religion. This is particularly critical because there are too many important results in science for each and every one to be learned through personal experiment, and many require tools that are beyond most individuals and schools. So, most people including scientists contact science via reading and hearing about results rather than verifying the experiments themselves. Much worse, most children are taught science as a kind of hearsay catechism of "this is true and must be believed".

Scientists escape to a large extent from simple belief by having done enough real experimentation, modeling building using mathematics that suggests new experiments, etc., to realize that science is more like map-making for real navigators than bible-making: IOW, the maps need to be as accurate as possible with annotations for errors and kinds of measurements, done by competent map-makers rather than story tellers, and they are always subject to improvement and rediscovery: they never completely represent the territory they are trying to map, etc.

Many of us who having been learning how to help children become scientists (that is to be able to think and act as scientists some of the time) have gathered evidence which shows that helping children actually do real science at the earliest possible ages is the best known way to help them move from simple beliefs in dogma to the more skeptical, empirically derived models of science.

We also know from the last century of careful observation of children that they think in ways that are different from adults, and as Piaget pointed out, it is best to think of children as thinking beings in their own right rather than as "defective adults who have to be fixed by education". And, further, children themselves are not homogenous in their approaches to life and learning: they have different styles, reasons for why they want to do things, what kinds of play they prefer, and so forth. The adults in their culture are both explicitly and implicitly trying to get the children to be part of the culture, and the children are wired by nature to try to learn whatever this is. In our culture, this is quite confusing, since the adult culture is an admixture of many different approaches to the world and how it works and can be manipulated. Real science is in the back seat or not even in the cultural vehicle as far as most children and adults (including most teachers) and most of the surrounding media are concerned.

My main concern over the years is how to help children and adults do the initial "real science" that can form the modern scientific stance towards knowledge that allows them to deal with the majority of science knowledge presented as claims they will encounter over the years.

So, I'm very interested in how the children can be motivated and helped to observe nature in ways that give rise to the formation of guesses that can be modeled and compared against the observations and lead to further observations. This requires finding out: what motivates different kinds of children, what kinds of observations can be done and in what form, how children can do real modeling and mapping, etc. All this has to be done above thresholds for what "real" means for science and its modeling. These thresholds can be approached by analogies to what it means for children to do "real music", "real art", "real writing and reading", "real sports", etc.

Seymour Papert's background was in real mathematics and science, and he was able to combine these with important insights of Piaget to realize that children could learn certain kinds of powerful math quite readily, whereas other forms of mathematics would be quite difficult. A central realization was that (a) the differential geometry of vectors (Gauss was one of the parents of this perspective) fit very readily into how children thought about themselves in the world, and that (b) the computer could show this world graphically and also easily do the laborious integration of the differential equations to give children the deep hit of fundamental powerful ideas of vector calculus in forms they could recognize and use for their own ends. I still regard these insights by Seymour as among the top few of all time regarding what computers are really good for.

My contribution to this was small, and amounted to adding in the ideas (a) that multiple independent objects (an idea derived from the early world of simulation) which children could program in the manner of LOGO would amount to a world of real children's mathematics that could model many kinds of ideas, including those of science (and of course all previous computer structures and old and new media), and (b) that the entire environment including the math/programming languages the children used were properly part of the user interface and had to be carefully designed.

There is abundant evidence that helping children move from human built-in heuristics and the commonsense of their local culture to the "uncommonsense" and heuristic thinking of science, math, etc., is best done at the earliest possible ages. This presents many difficulties ranging from understanding how young children think to the very real problem that "the younger the children, the more adept need to be their mentors (and the opposite is more often the case)".

If "children first!" is the rallying cry, then it makes sense to try to invent computer environments that use the very best ideas (and these are very hard to come up with). This is why the various groups that got interested in this romantic quest via early contact with Seymour have always been colleagues and never rivals. The hard to come by ideas for projects, representations, user interfaces, experiments, etc., have been freely traded back and forth. The notions of "thresholds below which is not worth going" have been jointly refined, etc. One of the parasitic difficulties is that computer environments, once made (with lots of effort and dedication) tend to form tribal bonds that are rather religious in nature. The amount of effort required plus the attendant religion makes it extremely difficult to take new insights and ideas and make brand new better environments for the children. The strong tendency is to use and reuse and incrementally expand the old environments.

So, for young and youngish children (say from 4 to 12) we still have a whole world of design problems. For one thing, this is not an homogenous group. Cognitively and kinesthetically it is at least two groups (and three groupings is an even better fit). So, we really think of three specially designed and constructed environments here, where each should have graceful ramps into the next one.

The current thresholds exclude many designs, but more than one kind of design could serve. If several designs could be found that serve, then we have a chance to see if the thresholds can be raised. This is why we encourage others to try their own comprehensive environments for children. Most of the historical progress in this area has come from a number of groups using each other's ideas to make better attempts (this is a lot like the way any science is supposed to work). One of the difficulties today is that many of the attempts over the last 15 or so years have been done with too low a sense of threshold and thus start to clog and confuse the real issues.

I think one of the trickiest issues in this kind of design is an analogy to the learning of science itself, and that is "how much should the learners/users have to do by themselves vs. how much should the curriculum/system do for them?" Most computer users have been mostly exposed to "productivity tools" in which as many things as possible have been done for them. The kinds of educational environments we are talking about here are at their best when the learner does the important parts by themselves, and any black or translucent boxes serve only on the side and not at the center of the learning. What is the center and what is the side will shift as the learning progresses, and this has to be accommodated.

OTOH, the extreme build it from scratch approach is not the best way for most minds, especially young ones. The best way seems to be to pick the areas that need to be from scratch and do the best job possible to make all difficulties be important ones whose overcoming is the whole point of the educational process (this is in direct analogy to how sports and music are taught -- the desire is to facilitate a real change for the better, and this can be honestly difficult for the learner).

The detailed parts of the design have to do with (a) what kinds of math and science the children can do and learn, and then (b) by good solutions to the user interface and expressive elements in the computer environment. These co-evolve because certain things the children can do and learn only have a real payoff for them if they have a computer. For example, many areas of physical dynamics (e.g Galilean Gravity) can be explored and represented in a kind of differential model they can understand without using a computer at all. But for all but about 5%-8% of the kids just finding a good model is not enough of a payoff. However, if the model can be set into motion (in mathematical terms: the integration of the differential model) then many "pieces of art" of great interest to about 90% of the children can be easily made. These include various kinds of falling games (like Lunar Lander, shoot the monkey, etc.).

As the children get more sophisticated, the black and gray boxes that scaffold what they are doing can be popped open and understand and modified. For example, "forward" (which moves an object in the direction of its "heading") is a black box initially, and very useful in that form. But there is a point when the children will be greatly aided by understanding that forward is just a vector addition and is a method made from a more fundamental idea. The underlying language for the system itself has to reveal itself as the same species as what the children have been learning. The analogy to how English is carefully used for different ages and the expanding range of ideas and expression is quite apt.

One of the simplest rules of thumb for any kind of design that requires learning is George Miller's "7 plus or minus 2", which refers to an estimate of how many things can be given attention at one time by our limited human minds. Perspective, simplification, abstraction and duration can all be traded off in designs that try to help learners make progress without overwhelming them. In programming language design in a UI, especially for beginners, this is especially crucial because it is easy to go far beyond 9 new elements. Many users will interpret this as "I am stupid and can't do this" rather than the more correct "The UI and language designers are stupid and they can't do this".

It's hard to point to any programming language for beginners that has a really great form. One thing that has consistently worked is "close to natural language but clearly not natural language". That is, it really helps if the gist-view of a program is a kind of metaphor for what it does, even if one has to think harder about the detailed meaning. For children, Hypercard was OK in many respects for the gist-view, but was too like English for both deep understanding and for programming (many children had a hard time getting past the idea that Hypercard couldn't understand and do any reasonable English sentence). This was debated endlessly in Logo circles, and Logo wound up going from a much more English-like syntax to one much more like Lisp (this was a big mistake in my view). Finding the balance between these is critical, because it governs how much brain is left to the learner to think about content rather than form. And for most learners, it is the initial experiences that make the difference for whether they want to dive in or try to avoid future encounters.

In one respect, young children are easier to design for in that there are fewer standards for math and science in the early grades (this is being eroded, especially wrt math). If we take functional relationships as an example, it has been shown that children readily understand them but have considerable difficulty with variables, and much more difficulty with parameters. The standard math syntax for functions with parameters requires some extra trained chunks to associated dummy names with actual parameters. Some computer languages allow conventions for prefixing the actual parameters with the dummy names. This is good. For younger children, it's likely that making these into complete assignment statements is an even better idea. An object oriented language can use instance variables for a long time before introducing the idea of passing parameters in a method, etc. Having really good trace and single-step visualizations is critical.

The importance of gisting argues against forms that have more than one meaning. For example, many languages (going all the way back to the 50s) have decided that "=" should have a double (or triple) meaning, and that it is up to the programmers to simply deal with it. This is almost certainly a bad idea for children K-8 (and beyond). In the case of "=", even in a functional language, the difference is huge (between a functional relationship and a definition). A suitable "logical language" that used unification would be less ambiguous but introduces quite a bit of abstraction (likely too early).

But, as the child gets closer to high school and the outside world, the QWERTY phenomenon starts to get more important. Many of the global standards are willy nilly and poor, but need to be pragmatically learned at some point. For example, it is relatively easy to get 10-11 year old children to do the real science and math to make a good simulation model of the 2nd order differential relationship. This is best done (so far) by using two accumulator addition (used to be called a DDA and goes back before Babbage). The trade-offs between this simple and deep way to think incrementally about what is going on and the standard algebraic way of thinking about "what's going on for all time all at once" are interesting and important.

Our view is that one should get the 5th graders to do this in the most powerful way for them (incremental addition). And then later (maybe in 8th grade) revisit this and see how the incremental approach can be turned into an algebraic perspective. Both ways of looking at this are important and powerful in their own ways. It is likely that educators are quite justified in making up useful non-standard representations for powerful ideas for any topic that would be helped by this for children below the age of 12. There are many other important reasons for introducing more powerful forms for dealing with ideas in early childhood, etc.

So it seems to me that there is a lot of room for new and different ideas for children's environments for learning powerful ideas. They have to be above threshold and in the spirit of real science and mathematics. Two cautionary examples are Interactive Physics and SimCity.

The first assumes that Newton was absolutely right and is a direct embodiment of Newtonian Dynamics and Cosmology. The users are restricted to paramerizing the internal dynamic models and cannot see them, question them, or change them. (For example, it is really important to be able to try an inverse cube law for gravity, etc.). This is most assuredly not in the spirit of science! It amounts to a dynamic bible. In order for this to be useful in real education, there has to be a lead up that derives the relationships in an empirical and mathematical form, and only then will the premises of IP be useful.

SimCity is similar but more pernicious. It is a black box of "soft somewhat arbitrary knowledge" that the children can't look at, question or change. For example, SC gets the players to discover that the way to counter rising crime is to put in more police stations. Most anthropologists, sociologists, psychologists, and economists would disagree violently. Alternate assumptions can't be tried, etc.

Both of these packages have won many "educational awards" from the pop culture, but in many ways they are anti-real-education because they miss what modern knowledge and thinking and epistemology are all about. This is why being "above threshold" and really understanding what this means is the deep key to making modern curricula and computer environments that will really help children lift themselves.

Best wishes, Alan

Discussion with Alan Kay about Robot Odyssey

One of Alan Kay's favorite games is Robot Odyssey! I wrote to him:

From: Don Hopkins
Subject: Robot Odyssey

One thing I've always wanted to do is a re-make of Robot Odyssey, with the full power of a real programming language underneath it, and lots of cool toys for the robots to play with! That was such a powerful concept for a game!


From: Alan Kay
Subject: Robot Odyssey

I actually argued with him [Will Wright] and Maxis for not making SimCity very educational. E.g. the kids can't open the hood to see the assumptions made by SimCity (crime can be countered by more police stations) and try other assumptions (raise standard of living to counter crime) etc. I've never thought of it as a particularly good design for educational purposes.

However, I have exactly the opposite opinion of Robot Odyssey, which I thought was a brilliant concept when the TLC people brought it to me at Atari in the early 80s. (Rocky's Boots is pretty much my all time favorite for a great game that really teaches and also has a terrific intro to itself done in itself, etc. Warren Robinette is a very special designer.).

The big problem with Robot Odyssey (as I tried to explain to them) was that the circuits-programming didn't scale to the game. They really needed to move to something like an object-oriented event-driven Logo with symbolic scripting to allow the kids to really get into the wonderful possibilities for strategies and tactics. (BTW, Etoys is kind of an OO event-driven Logo (not an accident), and the next version of it has as a goal to be able to do Robot Odyssey in a reasonable way. This got delayed because of funding problems but we now have funding and are really going to do it this year. Want to help design and build it?)

Syndicate content