git.zerfleddert.de Git - micropolis/blob - src/notes/OLPC-notes.txt

   1 Micropolis for OLCP Sugar User Interface
   2 By Don Hopkins (dhopkins@DonHopkins.com)
   3
   4 Why is Micropolis such a great match for OLPC's Sugar interface?
   5
   6 Constructivist education.
   7   Children learn by doing and experiencing.
   8   Playful learning (as opposed to edutainment).
   9   People learn effectively through making things.
  10   Micropolis is often mentioned as a great example of an educational,
  11   constructivist game, in the academic literature and popular press.
  12
  13 Multi player
  14   Sharing, collaborating, conferencing, voting.
  15
  16 Writing journals about Micropolis
  17   The Micropolis Journal: newspaper metaphore.
  18
  19 Drive the development and prove the worthyness of the technology.
  20
  21   Develop Micropolis hand-in-hand with Sugar, so they synergize with each other.
  22
  23   I developed the HyperLook version of Micropolis in parallel with the
  24   HyperLook user interface environment, and they both were better
  25   because of it. Micropolis required HyperLook to support useful
  26   multimedia extensions like a shared audio mixer server, an efficient
  27   shared memory based bitmap animation system, and integration with
  28   TNT Open Look user interface components (sliders, pin-up menus,
  29   buttons, etc). And Micropolis was able to take full advantage of
  30   HyperLook's features like outline graphics, scaling images,
  31   graphical editing, printing PostScript, etc. Micropolis was extremely
  32   useful as an engaging promotional demonstation that proved the
  33   capabilities and quality of HyperLook.
  34
  35 Use Micropolis to showcase the unique ideas and features of Sugar, in an
  36 exciting way that many people can easily understand.
  37
  38 CSound audio mixer.
  39 Mesh networking.
  40 D-bus messaging system.
  41 Python scripting langauge.
  42 GTK widgets.
  43 Pie menus.
  44 Communication and conferencing.
  45 Chat, shared whiteboard, voting interface.
  46 Learn to work together with other people, and argue your ideas.
  47 Politics. Interpersonal communication and cooperation.
  48 Immersive microworlds.
  49 Inspire and teach kids to program.
  50 Virtual datalogger, tricorder, lets you export and analyze logs and data from simulation.
  51 Micropolis courseware.
  52 Teach ecological and environmental issues.
  53 Social studies.
  54 Creative writing, developing language skills.
  55 Science education.
  56
  57 ========================================================================
  58
  59 Notes on adapting Micropolis to the OLPC Sugar user interface:
  60
  61 Core Ideas:
  62
  63   Activities, not Applications
  64
  65     First cut:
  66
  67       Integrate the current TCL/Tk version of Micropolis to run as a simple activity within Sugar.
  68
  69         Restructure the multi-window TCL/Tk code to run in a single full screen window.
  70         Implement a simple activity-oriented tiled window management interface.
  71         Disable advanced features like multiple editor and map windows,
  72         that require more sophisticated window management.
  73         Instead of using a traditional multi-window management approach,
  74
  75         Make a simple wrapper around it that makes it appear in the Sugar user interface as an activity, like eToys does.
  76
  77       Long term:
  78
  79         Implement activity specific modes that reconfigure the user inteface (like Eclipse "perspectives").
  80           - build/edit oriented interface
  81           - query/analysis oriented interface
  82           - financial oriented interface
  83           - communication/coordination oriented interface
  84           - dynamic zone finder analysis
  85           - grid of several overall map views, each configured to show a different overlay.
  86           - grid of several close-up map views, each centered on a different parts of the city (or tracking a player's cursor)
  87
  88         Collaboration: Enhance multi player mode to support sharing activities.
  89           Both publishing your game for others to clone and play themselves (massively single player, like Spore),
  90           and letting others join in your game (like the current cooperative multi-player mode)).
  91           Multi player inte
  92
  93         Expression: Enhance chat, journaling, storytelling, and personalization aspects of the game.
  94
  95         Journaling: Record all events (both user edits and simulation events), chat messages and drawings.
  96           Checkpoint the game state, and implement the ability to deterministically replay time stamped
  97           editing events into the simulation, so you can fast forward and rewind from any checkpoint to
  98           any step of the simulation.
  99           Enable players to write newspaper articles about the cities, with live links to a snapshot
 100           of the simulation and a place on the map, related to the story. Other players could browse
 101           their published newspapers about the history of a city, and jump into that history at any time
 102           from any story.
 103
 104         Iteration: Checkpoint game save files, allowing players to rewind history, and try "what-if" experiments.
 105
 106   Presence is Always Present
 107
 108     First cut:
 109
 110       Enhance the current X11 based multi player interface to support presence, the grid network, and messaging.
 111       The current multi player interface runs a single Micropolis process on one laptop,
 112       which connects to the local X server, and/or several other X servers on laptops over the net.
 113       Rewrite the "Add User" dialog to be grid-network aware.
 114       Instead of asking for an X server DISPLAY screen, provide a list of friends on the network.
 115       Send an invitation to play to friends on the network.
 116       Rewrite the built-in chat interface to integrate with the chat system used by Sugar.
 117       Improve the shared "white board" overlay, so kids can draw on the map in different colors,
 118       enable and disable different overlays, save overlays with the map, add text to overlays, etc.
 119       Implement location based chat, by overlaying people icons and chat bubbles on the map.
 120         Each player has a people icon "cursor" that they can move around the map (which follows
 121         their selected editing cursor), and their chat messages show up in bubbles overlayed on the map.
 122         When you select an editing tool, you can type what you're doing with the tool,
 123         other people will be able to watch you, and make comments on what you're doing.
 124
 125     Long term:
 126
 127       Rewrite Micropolis in terms of Python/GTK/Cairo, and take full advantage of the Sugar libraries and services.
 128       Support sharing, mentoring, colaboration, voting, political dialogs, journaling, etc.
 129       Develop Micropolis into a exemplary, cutting edge demonstration of all that's great about Sugar.
 130
 131   Tools of Expression
 132
 133     Micropolis is great at supporting personal expression, interpretation and storytelling,
 134     and leveraging what the player already knows to make connections to new knowledge,
 135     and stimulating conversation, debate and analytical thinking.
 136
 137     Develop a web based "Wikipedia" oriented interface to Micropolis, supporting colaboration, discussion,
 138     annotation, history journaling, and branching alternative histories.
 139
 140   Journaling
 141
 142     The "Micropolis Journal" could be realized as a web-based
 143     newspaper-like interface.
 144
 145     Expose the multi player user interface through the web, instead of
 146     using X11.
 147
 148     Automatically generate a newspaper for any particular time in a
 149     city's history, from the simulator events and state, combined with
 150     user written articles and chat messages.
 151
 152     The newspaper has sections that present automatically generated
 153     snapshots of the information displayed in the various dialogs
 154     (graph, evaluation, chat, notices, etc), and stories about
 155     significant events (both user-generated and simulation-generated).
 156
 157     Enrich the city save file with metadata including the chat and
 158     event journal, overlays, snapshots at different points in time (in
 159     a branching "what-if" tree structure), etc.
 160
 161     In the Python version of Micropolis it will be easy to implement a
 162     web server based interface that lets users read the city's
 163     newspaper through the web browser, automatically inserting
 164     pictures of the map corresponding to particular events in time. An
 165     article about pollution going down could show a before and after
 166     overall map with the polution overlay, and stuff like that.
 167
 168     Plug in modules to the simulator that analyze the state of the
 169     city and generate events for the newspaper to write articles
 170     about, including interesting stastical information and other
 171     parameters to insert into the story template.
 172
 173     Implement "online surveys" that let newspaper readers vote on proposals
 174     (expose the voting interface to web based users).
 175
 176     Use OpenLaszlo to develop a rich graphical AJAXian web service
 177     based Micropolis interface, eliminating the need for the X11
 178     interface, and enabling all kinds of interesting interface
 179     customizations and mash-ups with other web services.
 180
 181 Know your Audience
 182
 183   Inexperienced
 184
 185     Keep the user interface simple, low surface area, direct, obvious, redundant, forgiving.
 186     Gentle learning curve. Self revealing interface. Direct manipulation.
 187     Integrated help and educational content.
 188     Playback journals with voice-overs, so kids can learn by watching and listening to
 189     recordings of teachers playing and describing what they're doing.
 190     Multi player support for mentoring.
 191
 192   Young
 193
 194     Micropolis appeals to a wide range of age levels.
 195
 196     Design the user interface to support zooming, use large colorful
 197     graphics, etc.
 198
 199     Do not require high coordination, fine pointer positioning, moving
 200     the mouse while holding down the button, etc.
 201
 202     Scale across age levels by using interfaces that clearly reveal
 203     themselves to novice users, but can be reconfigured by more
 204     experienced users to be more streamlined.
 205
 206     For example, from the current interface: the map editor window has
 207     a palette of editing tools, which makes it easy for novice users
 208     to see and learn all the available editing commands, but consumes
 209     precious screen space.
 210
 211     It also provides pie menus as a short cut to the palette, which
 212     are layed out in the same arrangement as the palett (so the
 213     palette serves as a map to the pie menus). Intermediate users can
 214     use the palette as a map, to help learn the pie menus, and when
 215     they are more experienced, they can close the palette to make the
 216     map bigger, and use the pie menus exclusively.
 217
 218     The pie menus themselves are self-revealing, and have their own
 219     gradual learning curve that supports graduation from inexperienced
 220     users (click the menu up, look at the screen, move in the
 221     direction, select the item), intermediate users (press down and
 222     move in the direction, look at screen to make sure the right item
 223     is selected, then select the item), and advanced users (mouse
 224     ahead in the correct direction without looking at the screen).
 225
 226   International
 227
 228     The text in Micropolis needs to be broken out into external files so
 229     it can be translated to different languages.
 230
 231     The Micropolis documentation, supporting essays about city planning,
 232     and study guides need to be translated.
 233
 234     Best to do this after converting to Python/GTK/Cairo, since the
 235     old version of TCL/Tk that Micropolis currently uses does not support
 236     unicode or i18n.
 237
 238     Dig up the tile sets for different kinds of cities (old west,
 239     european, futuristic, moon base, etc), develop new tile sets, and
 240     enable children to easily develop their own tile sets and
 241     interface skins.
 242
 243 Key Design Principles
 244
 245   Performance
 246
 247     Micropolis was designed to run well in a C64.
 248
 249     I've profiled and optimized it to run efficiently on Unix, and
 250     take optimal advantage of the X11 window system.
 251
 252   Usability
 253
 254     Micropolis is fairly usable and approachable, but every effort should
 255     be made to improve it, take maximum advantage of the Sugar user
 256     interface, and for Micropolis to serve as a good example of Sugar
 257     interface design, for others to emulate.
 258
 259   Simplicity
 260
 261     Some of the advanced features of the multi player X11 version of
 262     Micropolis (like multiple map views and editors) will have to be
 263     temporarily sidelined, and eventually reimplemented in simpler,
 264     activity-oriented ways.
 265
 266   Reliability
 267
 268     Micropolis is currently pretty robust and can run for an indefinite
 269     time without leaking memory or crashing.
 270
 271     The scripting language interface should try to protect against hard crashes,
 272     but once you open it up to scripting, there are an infinite number of ways
 273     programmers could make mistakes.
 274
 275   Security
 276
 277     The code should be audited for security.
 278
 279     User access to the scripting language and network remote control
 280     code should be disabled.
 281
 282     Currently it allows any users to type TCL expressions, which is
 283     great for cheating, but bad for security.
 284
 285     Currently there is some code in there to enable network remote
 286     control (setting the tax rate and other parameters via a midi
 287     slider box on a Mac running Bounce/Body Electric that sends UDP
 288     packets to Micropolis when the user changes the slider).  That should
 289     be disabled (and eventually be replaced by a secure web service
 290     based network interface.).
 291
 292   Adaptability
 293
 294     Adapt to different screen display modes and resolutions.  Micropolis
 295     has a high contrast monochrome tile set that it could use in
 296     monochrome mode.
 297
 298     The color tiles look great in monochrome mode with gray scales,
 299     but the high contrast monochrome tiles might be easier to see.
 300
 301     Need to support zooming into the map with any magnification, like
 302     google maps (or the old PostScript-based HyperLook version of
 303     Micropolis).
 304
 305     Support playing Micropolis with the game controller in book mode.
 306
 307     Instead of using X11 for multi player interaction (which will
 308     cause the application to crash horribly if the network connection
 309     is lost), reimplement the multi player mode on top of the dbus
 310     messaging system, so it is more robust, and every player runs
 311     their own instance of the simulator, so they all simulate together
 312     in lock-step, like The Sims Online.
 313
 314   Recoverability
 315
 316     Use checkpointing and journaling to implement automatic back-up,
 317     and expose a "rewind/fast forward" interface to the user, so they
 318     can back up, change history, and replay changes at any point in time.
 319
 320     This is also the key to implementing a more advanced multi player
 321     interface (better than the current X11 based system, more like The
 322     Sims Online, where everyone runs their own copy of the simulation
 323     in lock-step), so anyone can join the game by cloning its current
 324     state, subscribing to its edit event stream, and submitting all
 325     their edits to the master simulation (or going through the voting
 326     negotiation system, like the current voting interface for building
 327     expensive items and changing the tax rate).
 328
 329     Solve the colaborative undo/redo problem by allowing children to
 330     branch out to their own private alternative histories. Instead of
 331     overwriting the one main history, it inserts a branch point into
 332     the shared history that links to their own private Idaho, which
 333     itself may branch out into many histories. See Larry Niven's "All
 334     the Myriad Ways".
 335
 336   Interoperability
 337
 338     Exposing Micropolis as a set of web services would enable all kinds
 339     of interesting mash-ups and rich web based user interfaces.
 340
 341   Mobility
 342
 343     Support playing Micropolis in book mode with the game pad.
 344
 345   Transparency
 346
 347     The "view source" button could bring up the Micropolis source code.
 348     Develop some source code documentation and extend the "How the
 349     Simulator Works" documentation to link into the appropriate source
 350     code. Annotate the C and Python source code to better explain how
 351     it works.
 352
 353     Encourage children to learn Python programming (rather than
 354     focusing on the C source code). Develop a robust Python scripting
 355     interface that lets you hook into and control all aspects of the
 356     simulator. Enable users to develop various kinds of Micropolis
 357     plug-ins (buildings, editing tools, agents, disasters, etc) that
 358     are easily scripted in Python, by subclassing.
 359
 360   Accessibility
 361
 362     Enable full keyboard control.
 363     Enable full game pad control.
 364     Enable full network control.
 365     Speech synthesis and recorded voice feedback.
 366     Zooming interface.