![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to OLPC-notes.txt CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Micropolis - Activity] / micropolis / src / notes|
Return to OLPC-notes.txt CVS log | Up to [Micropolis - Activity] / micropolis / src / notes |
1.1 root 1: Micropolis for OLCP Sugar User Interface
2: By Don Hopkins ([email protected])
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.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.