| 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. |