mirror of
https://github.com/tonytins/citylimits.git
synced 2025-03-15 04:11:23 +00:00
366 lines
16 KiB
Text
366 lines
16 KiB
Text
Micropolis for OLCP Sugar User Interface
|
|
By Don Hopkins (dhopkins@DonHopkins.com)
|
|
|
|
Why is Micropolis such a great match for OLPC's Sugar interface?
|
|
|
|
Constructivist education.
|
|
Children learn by doing and experiencing.
|
|
Playful learning (as opposed to edutainment).
|
|
People learn effectively through making things.
|
|
Micropolis is often mentioned as a great example of an educational,
|
|
constructivist game, in the academic literature and popular press.
|
|
|
|
Multi player
|
|
Sharing, collaborating, conferencing, voting.
|
|
|
|
Writing journals about Micropolis
|
|
The Micropolis Journal: newspaper metaphore.
|
|
|
|
Drive the development and prove the worthyness of the technology.
|
|
|
|
Develop Micropolis hand-in-hand with Sugar, so they synergize with each other.
|
|
|
|
I developed the HyperLook version of Micropolis in parallel with the
|
|
HyperLook user interface environment, and they both were better
|
|
because of it. Micropolis required HyperLook to support useful
|
|
multimedia extensions like a shared audio mixer server, an efficient
|
|
shared memory based bitmap animation system, and integration with
|
|
TNT Open Look user interface components (sliders, pin-up menus,
|
|
buttons, etc). And Micropolis was able to take full advantage of
|
|
HyperLook's features like outline graphics, scaling images,
|
|
graphical editing, printing PostScript, etc. Micropolis was extremely
|
|
useful as an engaging promotional demonstation that proved the
|
|
capabilities and quality of HyperLook.
|
|
|
|
Use Micropolis to showcase the unique ideas and features of Sugar, in an
|
|
exciting way that many people can easily understand.
|
|
|
|
CSound audio mixer.
|
|
Mesh networking.
|
|
D-bus messaging system.
|
|
Python scripting langauge.
|
|
GTK widgets.
|
|
Pie menus.
|
|
Communication and conferencing.
|
|
Chat, shared whiteboard, voting interface.
|
|
Learn to work together with other people, and argue your ideas.
|
|
Politics. Interpersonal communication and cooperation.
|
|
Immersive microworlds.
|
|
Inspire and teach kids to program.
|
|
Virtual datalogger, tricorder, lets you export and analyze logs and data from simulation.
|
|
Micropolis courseware.
|
|
Teach ecological and environmental issues.
|
|
Social studies.
|
|
Creative writing, developing language skills.
|
|
Science education.
|
|
|
|
========================================================================
|
|
|
|
Notes on adapting Micropolis to the OLPC Sugar user interface:
|
|
|
|
Core Ideas:
|
|
|
|
Activities, not Applications
|
|
|
|
First cut:
|
|
|
|
Integrate the current TCL/Tk version of Micropolis to run as a simple activity within Sugar.
|
|
|
|
Restructure the multi-window TCL/Tk code to run in a single full screen window.
|
|
Implement a simple activity-oriented tiled window management interface.
|
|
Disable advanced features like multiple editor and map windows,
|
|
that require more sophisticated window management.
|
|
Instead of using a traditional multi-window management approach,
|
|
|
|
Make a simple wrapper around it that makes it appear in the Sugar user interface as an activity, like eToys does.
|
|
|
|
Long term:
|
|
|
|
Implement activity specific modes that reconfigure the user inteface (like Eclipse "perspectives").
|
|
- build/edit oriented interface
|
|
- query/analysis oriented interface
|
|
- financial oriented interface
|
|
- communication/coordination oriented interface
|
|
- dynamic zone finder analysis
|
|
- grid of several overall map views, each configured to show a different overlay.
|
|
- grid of several close-up map views, each centered on a different parts of the city (or tracking a player's cursor)
|
|
|
|
Collaboration: Enhance multi player mode to support sharing activities.
|
|
Both publishing your game for others to clone and play themselves (massively single player, like Spore),
|
|
and letting others join in your game (like the current cooperative multi-player mode)).
|
|
Multi player inte
|
|
|
|
Expression: Enhance chat, journaling, storytelling, and personalization aspects of the game.
|
|
|
|
Journaling: Record all events (both user edits and simulation events), chat messages and drawings.
|
|
Checkpoint the game state, and implement the ability to deterministically replay time stamped
|
|
editing events into the simulation, so you can fast forward and rewind from any checkpoint to
|
|
any step of the simulation.
|
|
Enable players to write newspaper articles about the cities, with live links to a snapshot
|
|
of the simulation and a place on the map, related to the story. Other players could browse
|
|
their published newspapers about the history of a city, and jump into that history at any time
|
|
from any story.
|
|
|
|
Iteration: Checkpoint game save files, allowing players to rewind history, and try "what-if" experiments.
|
|
|
|
Presence is Always Present
|
|
|
|
First cut:
|
|
|
|
Enhance the current X11 based multi player interface to support presence, the grid network, and messaging.
|
|
The current multi player interface runs a single Micropolis process on one laptop,
|
|
which connects to the local X server, and/or several other X servers on laptops over the net.
|
|
Rewrite the "Add User" dialog to be grid-network aware.
|
|
Instead of asking for an X server DISPLAY screen, provide a list of friends on the network.
|
|
Send an invitation to play to friends on the network.
|
|
Rewrite the built-in chat interface to integrate with the chat system used by Sugar.
|
|
Improve the shared "white board" overlay, so kids can draw on the map in different colors,
|
|
enable and disable different overlays, save overlays with the map, add text to overlays, etc.
|
|
Implement location based chat, by overlaying people icons and chat bubbles on the map.
|
|
Each player has a people icon "cursor" that they can move around the map (which follows
|
|
their selected editing cursor), and their chat messages show up in bubbles overlayed on the map.
|
|
When you select an editing tool, you can type what you're doing with the tool,
|
|
other people will be able to watch you, and make comments on what you're doing.
|
|
|
|
Long term:
|
|
|
|
Rewrite Micropolis in terms of Python/GTK/Cairo, and take full advantage of the Sugar libraries and services.
|
|
Support sharing, mentoring, colaboration, voting, political dialogs, journaling, etc.
|
|
Develop Micropolis into a exemplary, cutting edge demonstration of all that's great about Sugar.
|
|
|
|
Tools of Expression
|
|
|
|
Micropolis is great at supporting personal expression, interpretation and storytelling,
|
|
and leveraging what the player already knows to make connections to new knowledge,
|
|
and stimulating conversation, debate and analytical thinking.
|
|
|
|
Develop a web based "Wikipedia" oriented interface to Micropolis, supporting colaboration, discussion,
|
|
annotation, history journaling, and branching alternative histories.
|
|
|
|
Journaling
|
|
|
|
The "Micropolis Journal" could be realized as a web-based
|
|
newspaper-like interface.
|
|
|
|
Expose the multi player user interface through the web, instead of
|
|
using X11.
|
|
|
|
Automatically generate a newspaper for any particular time in a
|
|
city's history, from the simulator events and state, combined with
|
|
user written articles and chat messages.
|
|
|
|
The newspaper has sections that present automatically generated
|
|
snapshots of the information displayed in the various dialogs
|
|
(graph, evaluation, chat, notices, etc), and stories about
|
|
significant events (both user-generated and simulation-generated).
|
|
|
|
Enrich the city save file with metadata including the chat and
|
|
event journal, overlays, snapshots at different points in time (in
|
|
a branching "what-if" tree structure), etc.
|
|
|
|
In the Python version of Micropolis it will be easy to implement a
|
|
web server based interface that lets users read the city's
|
|
newspaper through the web browser, automatically inserting
|
|
pictures of the map corresponding to particular events in time. An
|
|
article about pollution going down could show a before and after
|
|
overall map with the polution overlay, and stuff like that.
|
|
|
|
Plug in modules to the simulator that analyze the state of the
|
|
city and generate events for the newspaper to write articles
|
|
about, including interesting stastical information and other
|
|
parameters to insert into the story template.
|
|
|
|
Implement "online surveys" that let newspaper readers vote on proposals
|
|
(expose the voting interface to web based users).
|
|
|
|
Use OpenLaszlo to develop a rich graphical AJAXian web service
|
|
based Micropolis interface, eliminating the need for the X11
|
|
interface, and enabling all kinds of interesting interface
|
|
customizations and mash-ups with other web services.
|
|
|
|
Know your Audience
|
|
|
|
Inexperienced
|
|
|
|
Keep the user interface simple, low surface area, direct, obvious, redundant, forgiving.
|
|
Gentle learning curve. Self revealing interface. Direct manipulation.
|
|
Integrated help and educational content.
|
|
Playback journals with voice-overs, so kids can learn by watching and listening to
|
|
recordings of teachers playing and describing what they're doing.
|
|
Multi player support for mentoring.
|
|
|
|
Young
|
|
|
|
Micropolis appeals to a wide range of age levels.
|
|
|
|
Design the user interface to support zooming, use large colorful
|
|
graphics, etc.
|
|
|
|
Do not require high coordination, fine pointer positioning, moving
|
|
the mouse while holding down the button, etc.
|
|
|
|
Scale across age levels by using interfaces that clearly reveal
|
|
themselves to novice users, but can be reconfigured by more
|
|
experienced users to be more streamlined.
|
|
|
|
For example, from the current interface: the map editor window has
|
|
a palette of editing tools, which makes it easy for novice users
|
|
to see and learn all the available editing commands, but consumes
|
|
precious screen space.
|
|
|
|
It also provides pie menus as a short cut to the palette, which
|
|
are layed out in the same arrangement as the palett (so the
|
|
palette serves as a map to the pie menus). Intermediate users can
|
|
use the palette as a map, to help learn the pie menus, and when
|
|
they are more experienced, they can close the palette to make the
|
|
map bigger, and use the pie menus exclusively.
|
|
|
|
The pie menus themselves are self-revealing, and have their own
|
|
gradual learning curve that supports graduation from inexperienced
|
|
users (click the menu up, look at the screen, move in the
|
|
direction, select the item), intermediate users (press down and
|
|
move in the direction, look at screen to make sure the right item
|
|
is selected, then select the item), and advanced users (mouse
|
|
ahead in the correct direction without looking at the screen).
|
|
|
|
International
|
|
|
|
The text in Micropolis needs to be broken out into external files so
|
|
it can be translated to different languages.
|
|
|
|
The Micropolis documentation, supporting essays about city planning,
|
|
and study guides need to be translated.
|
|
|
|
Best to do this after converting to Python/GTK/Cairo, since the
|
|
old version of TCL/Tk that Micropolis currently uses does not support
|
|
unicode or i18n.
|
|
|
|
Dig up the tile sets for different kinds of cities (old west,
|
|
european, futuristic, moon base, etc), develop new tile sets, and
|
|
enable children to easily develop their own tile sets and
|
|
interface skins.
|
|
|
|
Key Design Principles
|
|
|
|
Performance
|
|
|
|
Micropolis was designed to run well in a C64.
|
|
|
|
I've profiled and optimized it to run efficiently on Unix, and
|
|
take optimal advantage of the X11 window system.
|
|
|
|
Usability
|
|
|
|
Micropolis is fairly usable and approachable, but every effort should
|
|
be made to improve it, take maximum advantage of the Sugar user
|
|
interface, and for Micropolis to serve as a good example of Sugar
|
|
interface design, for others to emulate.
|
|
|
|
Simplicity
|
|
|
|
Some of the advanced features of the multi player X11 version of
|
|
Micropolis (like multiple map views and editors) will have to be
|
|
temporarily sidelined, and eventually reimplemented in simpler,
|
|
activity-oriented ways.
|
|
|
|
Reliability
|
|
|
|
Micropolis is currently pretty robust and can run for an indefinite
|
|
time without leaking memory or crashing.
|
|
|
|
The scripting language interface should try to protect against hard crashes,
|
|
but once you open it up to scripting, there are an infinite number of ways
|
|
programmers could make mistakes.
|
|
|
|
Security
|
|
|
|
The code should be audited for security.
|
|
|
|
User access to the scripting language and network remote control
|
|
code should be disabled.
|
|
|
|
Currently it allows any users to type TCL expressions, which is
|
|
great for cheating, but bad for security.
|
|
|
|
Currently there is some code in there to enable network remote
|
|
control (setting the tax rate and other parameters via a midi
|
|
slider box on a Mac running Bounce/Body Electric that sends UDP
|
|
packets to Micropolis when the user changes the slider). That should
|
|
be disabled (and eventually be replaced by a secure web service
|
|
based network interface.).
|
|
|
|
Adaptability
|
|
|
|
Adapt to different screen display modes and resolutions. Micropolis
|
|
has a high contrast monochrome tile set that it could use in
|
|
monochrome mode.
|
|
|
|
The color tiles look great in monochrome mode with gray scales,
|
|
but the high contrast monochrome tiles might be easier to see.
|
|
|
|
Need to support zooming into the map with any magnification, like
|
|
google maps (or the old PostScript-based HyperLook version of
|
|
Micropolis).
|
|
|
|
Support playing Micropolis with the game controller in book mode.
|
|
|
|
Instead of using X11 for multi player interaction (which will
|
|
cause the application to crash horribly if the network connection
|
|
is lost), reimplement the multi player mode on top of the dbus
|
|
messaging system, so it is more robust, and every player runs
|
|
their own instance of the simulator, so they all simulate together
|
|
in lock-step, like The Sims Online.
|
|
|
|
Recoverability
|
|
|
|
Use checkpointing and journaling to implement automatic back-up,
|
|
and expose a "rewind/fast forward" interface to the user, so they
|
|
can back up, change history, and replay changes at any point in time.
|
|
|
|
This is also the key to implementing a more advanced multi player
|
|
interface (better than the current X11 based system, more like The
|
|
Sims Online, where everyone runs their own copy of the simulation
|
|
in lock-step), so anyone can join the game by cloning its current
|
|
state, subscribing to its edit event stream, and submitting all
|
|
their edits to the master simulation (or going through the voting
|
|
negotiation system, like the current voting interface for building
|
|
expensive items and changing the tax rate).
|
|
|
|
Solve the colaborative undo/redo problem by allowing children to
|
|
branch out to their own private alternative histories. Instead of
|
|
overwriting the one main history, it inserts a branch point into
|
|
the shared history that links to their own private Idaho, which
|
|
itself may branch out into many histories. See Larry Niven's "All
|
|
the Myriad Ways".
|
|
|
|
Interoperability
|
|
|
|
Exposing Micropolis as a set of web services would enable all kinds
|
|
of interesting mash-ups and rich web based user interfaces.
|
|
|
|
Mobility
|
|
|
|
Support playing Micropolis in book mode with the game pad.
|
|
|
|
Transparency
|
|
|
|
The "view source" button could bring up the Micropolis source code.
|
|
Develop some source code documentation and extend the "How the
|
|
Simulator Works" documentation to link into the appropriate source
|
|
code. Annotate the C and Python source code to better explain how
|
|
it works.
|
|
|
|
Encourage children to learn Python programming (rather than
|
|
focusing on the C source code). Develop a robust Python scripting
|
|
interface that lets you hook into and control all aspects of the
|
|
simulator. Enable users to develop various kinds of Micropolis
|
|
plug-ins (buildings, editing tools, agents, disasters, etc) that
|
|
are easily scripted in Python, by subclassing.
|
|
|
|
Accessibility
|
|
|
|
Enable full keyboard control.
|
|
Enable full game pad control.
|
|
Enable full network control.
|
|
Speech synthesis and recorded voice feedback.
|
|
Zooming interface.
|