Blatent self promotion. Pie Menus. OpenLaszlo. Sims. Content. User Interface. Software.

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?)

SimCity, Robot Odyssey, and Visual Programming

From: Don Hopkins
Subject: Education?

Of course it might just be more powerful and efficient to re-implement something like Klik-and-Play from scratch in Python, as a plug-in visual scripting component, which can be used to script a HyperCard-like gui environment, and games built on top of it like SimCity and Robot Odyssey.

From: Antoine van Gelder
Subject: Education?

Anyone know the current status of being able to turn an AST tree emitted by the Python compiler module back into code after it has been modified ?

From: Andrew Clunis
Subject: Education?

I've been looking into this for Develop activity, but it seems that path has never been explored. Best approach seems to be to write a pretty-printer to walk the tree.

From: Guido van Rossum
Subject: Education?

I'm curious about the focus on ASTs that seems apparent in this subthread (though I may easily be misreading between the lines :-). I've always been more inclined to edit the text and re-parse from there, as it puts the author in control of formatting, comments etc., and this is how most "real-world" environments work. (Not that that necessarily makes it better, but neither is the opposite true.) Is someone willing to write up a brief comparison between the two approaches?

OLPC Visual Programming Language Discussion with Guido van Rossum and Alan Kay

This is a discussion from the OLPC Sugar mailing list, about implementing visual programming languages like eToys in Python.

From: Guido van Rossum
Subject: Etoys and integration

Isn't the mere presence of eToys on the XO a complete anathema to the sugar philosophy?

From: MBurns

I think the quote is referencing something else (though I may misunderstand).

The eToys environment is a self-contained world of development. One that exists within the Sugar world of development. Programs, projects, source code and objects written in that eToys world do not exist outside in the Sugar world. You can write a sugar Activity or an eToys bundle, and, as we have seen in the gaming realm, they can often accomplish the same end goal.

Now this may or may not be an issue to people(OLPC devs, students, teacers), they may or may not care, but it is an interesting 'world inside a world' for this transparent learning machine we are developing.

From: Alan Kay

Guido knows that I've been advocating that the Python folks should do Etoys or a very Etoys like environment in Python (and that the rest of the OLPC be given an objectification and media and scripting integration that is Etoys like).

However, there are simply zillions of things left to be done everywhere for OLPC so the first round of SW on the XO will be more of a gathering of "suggestive" features and abilities (of which Etoys is just one). That seems fine to me.

Viewpoints Research (our little non-profit) doesn't have any "ego or identity" staked around whether the children's authoring environment is Python based or Squeak based. I have said many times that, if the general integrative base of XO is to be Python, then the Etoys-like authoring should be based in Python also.

However, I will personally fight to the death to make sure that there is a children's authoring environment that allows even young children to do simulation style programming with very rich media objects.

For now, that is Etoys. It could be a suitable object-oriented Logo with media objects (this is essentially what Etoys is). It could be some better design (let's do one). The base could be Javascript (if implemented on top of an integrated environment of sufficient power), Python (ditto), Ruby (ditto), etc. Whatever it is, it has to be above high thresholds, not a hack or a gesture.

Besides the programming the children use to learn important ideas in math and science, they also need to be able to see how their own computer world is structured by being able to "pop the hood" on practically everything they use. Perhaps it is OK for high school children to see the current code (but I don't think so). I think there needs to be a wrapping on the entire set of facilities that uses the same conventions that 9 year olds do their own programming in. Again, if it is to be Python, then it needs to be crafted a bit for younger children. E.g. Etoys allows easy unlimited parallel tasking, and this is very important for children's programming. Etc.

There are many good things that can be done here. We live in a computing world in which there is a tremendous amount of identification between many programmers and the tools they use -- so strong that it resembles religious fervor. From my view, ALL of the system have such flaws that we are better off being critical of all of them and try to use the best ideas from everywhere.

If "Children First!" is really the goal here, then we must spend most of our energies trying to make the childrens' environments more conducive to creative learning of powerful ideas.



From: Guido van Rossum

Thanks Alan. I'm quite satisfied with this response and I agree with the priorities!

Slashdot OLPC SimCity Discussion

From: Don Hopkins
To: Alan Kay
Subject: Slashdot OLPC SimCity Discussion

I'm with you completely! Here are a couple messages I posted in the Slashdot discussion "One SimCity Per Child":

Here's a great article, too!


Responding to Alan Kay's criticisms of SimCity

In other (and fewer) words, the plan is to respond to Alan Kay's valid criticisms of SimCity by opening it up to scripting languages, documenting and parameterizing how it works, and ultimately implementing an eToys-like visual programming language for scripting and extending SimCity, and implementing your own games based on the reusable components that SimCity will be rebuilt in terms of (like a generic tile engine, sprite engine, map editing tools, numerical and symbolic layers, data visualizations, overlays, annotations, points of interest, etc).

Oops, I was trying for fewer words. Oh well...


Alan Kay's ideas about SimCity for OLPC

I just received this exciting email from Alan Kay. I totally agree with the direction he wants to take SimCity for the OLPC!


From: Alan Kay
To: Don Hopkins
Date: 11/9/2007 6:14 PM
Subject: SimCity for OLPC

Hi Don --

I'm writing to applaud you for your plans to reimplement SimCity for children on the OLPC.

My main complaint about this game has always been the rigidity, and sometimes stupidity, of its assumptions (counter crime with more police stations) and the opaqueness of its mechanism (children can't find out what its actual assumptions are, see what they look like, or change them to try other systems dynamics).

So I have used SimCity as an example of an anti-ed environment despite all the awards it has won. It's kind of an air-guitar environment.

In the past, I tried to get Maxis to take the actual (great) educational possibilities more seriously, but to no avail.

Going to Python can help a few areas of this, but a better abstraction for the heart of Sim-City would be a way to show its rules/heuristics in a readable and writable form. Both of these could be stylized to put them in the child's own thinking and doing world. For example, just the simple route of making a drag and drop scripting interface for Etoys allows children to make very readable and writeable scripts and helps the children concentrate on what they are trying to do. A carefully designed object system (that is filtered fro children) can expose the environment so they can really think about it.

I'm not at all suggesting that Etoys be used here, but I am suggesting that some deep design be done to come up with a "behavior modification interface" that allows real creativity on the part of the children. So it is much more than stringing black boxes together or having to deal with fragile procedurals.

I sense that you have some interests in making SimCity really a microworld for children's learning and exploration from reading your webpage.

Children in 4th - 6th grade can do a lot here if they are given a good UI and tools. So, we could think of part of this project as a "pre-Python" UI.

Scalability and non-scalability of ideas are interesting. Rocky's Boots is still one of the best ever games that provide profound learning experiences. The extension of this to Robot Odyssey didn't work because the logic and wires programming didn't scale well enough -- the bang per effort dropped off precipitously. I was Chief Scientist at Atari at that time (Warren Robbinet worked for me) and I worked with TLC to try to get them to realize that something like Logo, or even better, a rule-based robot programming system, was needed. The failure of Robot Odyssey really pained me because I thought that the concept of this game was one of the best ever (still is). But it just needed a much better notion of how the children were going to program the robots. I think the same goes for SimCity.



SJ Klein's OLPC Keynote at GDC Serious Games Summit

Here is a description of the OLPC talk that SJ Klein is giving at the Serious Games summit on Tuesday the 6th:

Alan Kay on Programming Languages

Alan Kay wrote:

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.

Syndicate content