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.
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/
Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser
By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland.
Human-Computer Interaction Laboratory
A.V. Williams Bldg., University of Maryland
College Park MD 20742, U.S.A.
Since browsing hypertext can present a formidable cognitive challenge, user interface design plays a major role in determining acceptability. In the Unix workstation version of Hyperties, a research-oriented prototype, we focussed on design features that facilitate browsing. We first give a general overview of Hyperties and its markup language. Customizable documents can be generated by the conditional text feature that enables dynamic and selective display of text and graphics. In addition we present:
- an innovative solution to link identification: pop-out graphical buttons of arbitrary shape.
- application of pie menus to permit low cognitive load actions that reduce the distraction of common actions, such as page turning or window selection.
- multiple window selection strategies that reduce clutter and housekeeping effort. We preferred piles-of-tiles, in which standard-sized windows were arranged in a consistent pattern on the display and actions could be done rapidly, allowing users to concentrate on the contents.
HyperTIES is an early hypermedia browser developed under the direction of Dr. Ben Shneiderman at the University of Maryland Human Computer Interaction Lab.
The Design and Implementation of Pie Menus
There're Fast, Easy, and Self-Revealing.
Copyright (C) 1991 by Don Hopkins.
Originally published in Dr. Dobb's Journal, Dec. 1991, lead cover story, user interface issue.
Although the computer screen is two-dimensional, today most users of windowing environments control their systems with a one-dimensional list of choices -- the standard pull-down or drop-down menus such as those found on Microsoft Windows, Presentation Manager, or the Macintosh.
This article describes an alternative user-interface technique I call "pie" menus, which is two-dimensional, circular, and in many ways easier to use and faster than conventional linear menus. Pie menus also work well with alternative pointing devices such as those found in stylus or pen-based systems. I developed pie menus at the University of Maryland in 1986 and have been studying and improving them over the last five years.
During that time, pie menus have been implemented by myself and my colleagues on four different platforms: X10 with the uwm window manager, SunView, NeWS with the Lite Toolkit, and OpenWindows with the NeWS Toolkit. Fellow researchers have conducted both comparison tests between pie menus and linear menus, and also tests with different kinds of pointing devices, including mice, pens, and trackballs.
Included with this article are relevant code excerpts from the most recent NeWS implementation, written in Sun's object-oriented PostScript dialect.
The Shape of PSIBER Space:
PostScript Interactive Bug Eradication Routines
Written by Don Hopkins, October 1989.
University of Maryland
Human-Computer Interaction Lab
Computer Science Department
College Park, Maryland 20742
The PSIBER Space Deck is an interactive visual user interface to a graphical programming environment, the NeWS window system. It lets you display, manipulate, and navigate the data structures, programs, and processes living in the virtual memory space of NeWS. It is useful as a debugging tool, and as a hands on way to learn about programming in PostScript and NeWS.
Cyberspace. A consensual hallucination experienced daily by billions of legitimate operators, in every nation, by children being taught mathematical concepts ... A graphic representation of data abstracted from the banks of every computer in the human system. Unthinkable complexity. Lines of light ranged in the nonspace of the mind, clusters and constellations of data. Like city lights, receding ....
How to Choose with Pie Menus
English 393, Technical Writing Assignment #1
Instructions for Performing a Process
March 10, 1988
Q: What is the process?
A: The process is selecting from pie menus.
Q: Whis is the audience?
A: The audience is users of the pie menu software for the NeWS window system.
Q: Where would the document be found?
A: It would be part of the documentation that goes along with the software.
Selecting commands from menus is an easy, straightforward way to operate a computer. You can use a pointing device called a "mouse" to indicate the selection you desire, from a list of choices show on the screen. Pie menus (Figure 1) differ from traditional "linear" menus (Figure 2) in the way that their choices are laid out, and the shape of their selection target areas on the screen.
These instructions will describe how to select a choice from a pie menu, cancel a menu without making a selection, and make selections quickly and efficiently.
A Pie Menu Cookbook
Techniques for the Design of Circular Menus
By Don Hopkins, October, 1987
Pie menus are used for making selections from items displayed on the computer screen, by pointing and clicking at the desired one with a mouse. The regions of the menu are shaped like the slices of a pie, laid out in a circle around the menu center.
The click of a mouse button invokes a menu, which pops up on the screen positioned so that the cursor is centered in the small inactive region in the menu center. The active target regions are all adjacent to the cursor, but in different directions. Pie menus are fast, because it only takes a small amount of cursor movement to point at one of the regions, and they are accurate, because the wedge shaped regions all have large areas.
The circular layout of pie menus makes them very appropriate for certain tasks. Complementary items can be placed in opposite directions, and spatially oriented items can be put in their appropriate directions. Experienced users can select from familiar pie menus without looking at the menu, and can even mouse ahead into menus faster than the computer can update the screen. When the user selects by mousing ahead into a menu, suppressing the menu display can speed up interaction considerably.
The cursor distance from the menu center can be increased to get more angular precision, for accurate directional selection. It can also be used as an argument to the selection, as a continuous analog value, or a discrete sub-selection.
Users can benefit from commonly used pie menus if they are designed to be easy to learn and use. A window management pie menu with its spatially oriented items in appropriate directions is an example of such a menu. A font selection menu using direction to select font style, and distance to select point size, is an example of how the two-dimensional aspect of pie menus can be exploited.
A user should be able to discern the function of a pie menu by looking at it. A simple, intuitive, consistent look for visually representing the meaning and function of a pie menu can help to create an easy to use user interface. Pie menus can also be designed so that they have a good kinesthetic feel to them, they do not require a lot of wasted mouse movement, and the directions are easier to select, and well matched with the input device.
I released the source code for a NeWS window manager based on pie menus, called NeatWindow (source).
Date: Wed, 11 May 88 02:31:51 EDT
Subject: class NeatWindow From: Don Hopkins <email@example.com>
Here is a window class with window managment menus designed to work well with pie menus. You should of course have piemenu.ps loaded up before running this. Just psh it into your environment, and the DefaultWindow will be set up so that the next window you get will be a NeatWindow! Fire up a clock or something, pop up the frame menu, and play around! I am not including any instructions right now, because I would like to hear what you think of it after trying to figure out what the menus do on your own. (heh heh heh -- the code is free but you gotta be a guinea pig!) This is experimental, so I'll be coming out with a more refined version later. If you'd care to answer the following questions after playing around with the NeatWindow menus, I'd really appreciate it!
- Which functions were obvious by their direction, or their labeling?
- How would you change the labels to make their meanings clearer?
- Why do you think the selections are arranged the way they are?
- What mnemonic tricks can you think of to remember the selection directions?
- After using them for a while, which selections do you find yourself mousing into without looking at the menu?