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.
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 ProgramSubmitted by dhopkins on Mon, 2007-03-19 22:58.
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!
This is a forum for discussing OpenLaszlo.
The Soul of The Sims, by Will Wright
Tuesday, January 28, 1997 / 9:25 AM
I had just started working at the Maxis Core Technology Group on "Project X" aka "Dollhouse", and Will Wright brought this code in one morning, to demonstrate his design for the motives, feedback loop and failure conditions of the simulated people. While going through old papers, I ran across this print-out that I had saved, so I scanned it and cleaned the images up, and got permission from Will to publish it.
This code is a interesting example of game design, programming and prototyping techniques. The Sims code has certainly changed a lot since Will wrote this original prototype code. For example, there is no longer any "stress" motive. And the game doesn't store motives in global variables, of course.
My hope is that this code will give you a glimpse of how Will Wright designs games, and what was going on in his head at the time!
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.
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:
Source code of TCL/Tk Micropolis for the OLPC XO-1 and Linux.
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.
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
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 email@example.com .
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!
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!
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
Even more weird videos: http://www.donhopkins.com/home/movies/