History and Future of OLPC SimCity / Micropolis

There are several different versions of SimCity, and at least two different names (so far):

  • The original version of SimCity was developed by Maxis on the C64, and ported to various platforms, including the Macintosh. Maxis licensed the Macintosh SimCity source code to DUX software, to port to Unix.
  • DUX Software contracted me (Don Hopkins) to port SimCity to Unix, and I developed "SimCity HyperLook Edition", while working at the Turing Institute on HyperLook with Arthur van Hoff. The user interface was written in PostScript, which ran on the NeWS window system on Sun workstations, and it supported multiple zoomable views, pie menus, annotating and printing maps, and many user interface improvements.
  • After Sun canceled NeWS, DUX Software contracted me to rewrite the HyperLook user interface in TCL/Tk for X11, and I developed a multi-player networked user interface using the X11 protocol. The TCL/Tk version of SimCity has been ported to various Unix and non-Unix platforms, including SunOS, Solaris, Irix, HP/UX, OSF/1, Quarterdeck Desqview/X, NDC X Terminals, Warp, and Linux. The contract to sell SimCity for Unix expired after ten years, so the TCL/Tk version was no longer commercially available.
  • OLPC SimCity is based on the TCL/Tk version of SimCity. SimCity is a trademark of Electronic Arts. Don Hopkins adapted SimCity to the OLPC, thanks to the support of John Gilmore. OLPC SimCity will be shipped with the OLPC, and it has been run through EA's quality assurance process and reviewed for integrity. EA reserves the right to review and approve any version of the game distributed under the name SimCity.
  • "Micropolis" is the name of the current GPL open source code version of OLPC SimCity. That was the original working title of Will Wright's city simulation game. Since Micropolis is licensed under the GPL, anyone can do anything they want with it that conforms with the GPL, except they can't call it "SimCity" (and a few other limitations to protect EA's trademarks).
  • Other differently named projects can be forked from the Micropolis source code, as long as they're not called SimCity.
  • Improvements to the open source code base that merits EA's approval may be incorporated into the official "OLPC SimCity" source code, to be distributed with the OLPC under the trademarked name "OLPC SimCity", but only after it's been reviewed and approved by EA.
  • In the short term, the TCL/Tk version of Micropolis can be upgraded to support the latest version of TCL/Tk, fix bugs, improve the user interface and Sugar integration, etc. Once that is stable as well integrated into Sugar, it could be submitted to EA to become the official version of "OLPC SimCity" distributed on the XO laptop.
  • In the long term, Micropolis can be recast from C to C++ classes, so it's possible to define clean interfaces between software modules, and make multiple instances of the simulator that don't interfere with each other, as well as easily interfacing it to Python using the SWIG interface generator. That should be done in a language-neutral way, so you could plug the simulator engine into many different languages and programming systems. Then more work needs to be done to open it up, and make it re-vectorable (plug-ins, events, callbacks, hooks, aspect oriented programming, etc), so you can replace and extend the various modules with the host language(s), eventually re-implementing most if not all of SimCity in another language.

GPL Open Source Code of "OLPC SimCity" to be called "Micropolis"

The GPL source code version of SimCity will not be called "SimCity", but we will use the SimCity source code to make a city building game called "Micropolis", which was the original working title of SimCity. That's because EA reserves the right to review and QA the official version of the game that's published under the name "SimCity" on the OLPC. So we can make improvements to the TCL/Tk version of Micropolis (based on the GPL source code), and submit them to EA for review and QA, which if they approve, will be used as the officially branded version of SimCity for the OLPC. It will be the same code, but the only difference is the name, which EA understandably wants to protect, be ensuring the quality and integrity of OLPC SimCity.

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 games@lists.laptop.org .


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: http://www.donhopkins.com/home/movies/

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.


Syndicate content