tonytins/citylimits
1
0
Fork 0
mirror of https://github.com/tonytins/citylimits synced 2025-06-25 09:24:44 -04:00
Code Issues Projects Releases Wiki Activity

Initial source commit

Browse source
This commit is contained in:
Tony Bark 2024-05-03 22:50:34 -04:00
commit 5f7cefb98e
1794 changed files with 40615 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

322
notes/ASSETS.txt Normal file
View file

@ -0,0 +1,322 @@
Micropolis Art Assets:
This is a list of required and optional assets for Micropolis.
As noted, some of them are for the current TCL/Tk based version of
Micropolis that we want to get out right away. Others are for the more
advanced Python version that we're developing after releasing the
TCL/Tk version.
The TCL/Tk version currently works ok with its current assets, and
these are just suggestions that would improve it but are not
necessary. The Python version is not yet fully designed or
implemented, and it will be more open-ended and powerful, so this is
just a rough estimate of the assets it will need.
Sound
NeWS and TCL/Tk sound servers supported playing sounds back at different rates, and repeating.
Sound effects for tools.
Currently playing vocal vowles at different pitches.
User Interface Graphics and Icons
These aren't all necessary, but it would be nice to have some of
them to make the interface look nicer, more graphical, and kid
friendly.
The style should be international, kid oriented, big, bright,
saturated, simple.
Icons should look good and be readable when shown in desaturated
gray scale on the OLPC's monochrome screen in low power reflective
mode. The brightness detail can be full resolution but the color
detail should be lower resolution by about half (not depending on
color detail as fine as brightness detail), because of the nature
of the OLPC's screen: 200 dots per inch monochrome gray scale,
with lower resolution color. For example, text on an icon should
be a noticeably different brightness than the background color,
instead of relying on color variation, which is not as detailed
and won't show up in monochrome mode.
SVG is the idea source format, because it can be scaled to any
size, rendered with antialiased edges, and will be easily used in
the Python version. Illustrator exports SVG. For now the TCL/Tk
version can use versions of the SVG files converted to "XPM"
format (which I can do).
Later, the Python user interface will require a bunch more icons
and graphics, depending on the user interface and features we
decide to support. It would be great to be able to use the same
SVG source graphics in the Python version, scaling them as
appropriate to adapt to the screen layout. We should revisit the
icons and graphics after we port Micropolis to Python.
What follows is a complete list of graphics we could use in the
TCL/Tk version. SVG is ideal but PNG is sufficient for this time.
Micropolis icon for use in Sugar user interface, in SVG or PNG.
Logos:
Micropolis logo
Micropolis lettering
OLPC Project logo
XO Laptop logo
Linux Penguin logo
Python Programming Language logo
Small menu item icons for map overlay menus:
Zones
All
Residential
Commercial
Industrial
Transportation
Overlays
Population Density
Rate of Growth
Land Value
Crime Rate
Pollution Density
Traffic Density
Power Grid
Fire Coverage
Police Coverage
Small menu item icons for File menu:
Save City
Save City as...
Add Player...
Choose City!
Quit Playing!
Small menu item icons for Options menu:
Auto Budget
Auto Bulldoze
Disasters
Sound
Animation
Messages
Notices
Small menu item icons for Disasters menu:
Monster
Fire
Flood
Meltdown
Air Crash
Tornado
Earthquake
Small menu item icons for Time menu:
Pause
Slow
Medium
Fast
Small menu item icons for Priority menu:
Flat Out!
Zoom Zoom
Whoosh Whoosh
Buzz Buzz
Putter Putter
Drip Drip
Snore Snore
Small menu item icons for Windows menu (maybe the same as ones used in buttons):
Budget
Evaluation
Graph
Small menu item icons for Map Options menu:
Auto Goto
Palette Panel
Chalk Overlay
Small "OK" button for confirmation dialog buttons.
Small "Cancel" button for confirmation dialog buttons.
Large "Question" icon for dialogs asking questions (ok/cancel questions).
Large "Notice" icon for notice window (informational).
Large "Query" icon for zone query window (zone tricorder).
Medium "Generate New City" icon for button to generate new city, on start screen.
Medium Game Level icons for start screen radio buttons:
Easy
Medium
Hard
Big "Load City" icon for load city dialog.
Meduim "Load City" icon for button to load city, on start screen.
Big "Save City" icon for save city dialog.
Small "Save City" icon for button to save city.
Big Evaluation icon for evaluation window.
Small Evaluation icon for button to bring up evaluation window.
Big Graph icon for graph window.
Small Graph icon for button to bring up graph window.
Big Simolean/Budget symbol for Budget window.
Small Simolean/Budget symbol for button to bring up budget window.
Big Quit symbol for Quit confirmation dialog.
Small Quit symbol for button to bring up Quit confirmation dialog.
Big About symbol for About dialog.
Small About symbol for button to open About dialog.
Big Choose City symbol for Choose City confirmation dialog.
Small Choose City symbol for button to open Choose City confirmation dialog.
Simulation and User Interface Sounds
Right now it's using the original sounds, plus some interface
sounds I recorded. I can convert them to the format required by
the Linux sound interface we use.
I can supply a list of required interface sounds, but I think we
can go with the sounds we have right now without any trouble.
Later, the Python version will require a bunch more sounds for its
user interface, which will depend on the user interface features
we decide to support. So we should revisit the sound effects
later once Micropolis is ported to Python.
To be authentic, I would like to use the original sounds that the
simulator made (like the Skywatch One helicopter), or re-record
high quality replacements. Maybe we can get Will to record a fresh
version of "Skywatch One reporting heavy traffic!" in his own
voice (he made that original sound) and the sound people can add
in the helicopter sound over his voice to re-create the original
sound at high quality. The other sounds could be re-made from
scratch without any problem or help from Will.
Voice overs reading the user interface text, notices, help text
and documentation would be great for pre-literate children. Would
need to be translated to other languages.
Update Documentation
I have translated the Micropolis manual to HTML.
It's the original version that applies to the multi player
X11/TCL/Tk version, which needs to be update in a few places where
it's specific about the user interface or installation instructions.
It would benefit from some nice reformatting and CSS styles, as well
as some illustrations and screen snapshots.
After we port Micropolis to Python, the interface-specific
documentation will have to be rewritten, re-illustrated, and then it
will have to be translated to different languages.
The documentation consists of the following files:
Index
Introduction
Tutorial
User Reference
Inside the Simulator
History of Cities and City Planning
Bibliography
Credits
Help Text
There are also HTML files corresponding to user interface help text.
The user interface components are tagged with help ids that are the
base names of html files. The existing HTML help files are just
placeholders that don't have any useful help text, and there are
some help files for user interface components and windows that have
since been removed, as well as some help files missing for user
interface components and windows that have been added.
To finish implementing help, we need to go through the code and
identify all help tags and opportunities for adding missing help
tags to the user interface, then make all help files corresponding
to the existing tags, delete obsolete help files, and write all the
help text. It would be nice for the help text to hsve illustrations
of the corresponding windows and components in use.
After we port Micropolis to Python, the help files will have to be
re-inventoried, rewritten, re-illustrated, and translated to
different languages.
Courseware
We need to include any Micropolis courseware or teacher's guides with
the documentation, and update it to relect the current user
interface.
After we port Micropolis to Python, we will need to update the
courseware to reflect the features and user interface of the new
user interface.
--
Micropolis, Unix Version. This game was released for the Unix platform
in or about 1990 and has been modified for inclusion in the One Laptop
Per Child program. Copyright (C) 1989 - 2007 Electronic Arts Inc. If
you need assistance with this program, you may contact:
http://wiki.laptop.org/go/Micropolis or email micropolis@laptop.org.
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or (at
your option) any later version.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details. You should have received a
copy of the GNU General Public License along with this program. If
not, see <http://www.gnu.org/licenses/>.
ADDITIONAL TERMS per GNU GPL Section 7
No trademark or publicity rights are granted. This license does NOT
give you any right, title or interest in the trademark SimCity or any
other Electronic Arts trademark. You may not distribute any
modification of this program using the trademark SimCity or claim any
affliation or association with Electronic Arts Inc. or its employees.
Any propagation or conveyance of this program must include this
copyright notice and these terms.
If you convey this program (or any modifications of it) and assume
contractual liability for the program to recipients of it, you agree
to indemnify Electronic Arts for any liability that those contractual
assumptions impose on Electronic Arts.
You may not misrepresent the origins of this program; modified
versions of the program must be marked as such and not identified as
the original program.
This disclaimer supplements the one included in the General Public
License. TO THE FULLEST EXTENT PERMISSIBLE UNDER APPLICABLE LAW, THIS
PROGRAM IS PROVIDED TO YOU "AS IS," WITH ALL FAULTS, WITHOUT WARRANTY
OF ANY KIND, AND YOUR USE IS AT YOUR SOLE RISK. THE ENTIRE RISK OF
SATISFACTORY QUALITY AND PERFORMANCE RESIDES WITH YOU. ELECTRONIC ARTS
DISCLAIMS ANY AND ALL EXPRESS, IMPLIED OR STATUTORY WARRANTIES,
INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY, SATISFACTORY QUALITY,
FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT OF THIRD PARTY
RIGHTS, AND WARRANTIES (IF ANY) ARISING FROM A COURSE OF DEALING,
USAGE, OR TRADE PRACTICE. ELECTRONIC ARTS DOES NOT WARRANT AGAINST
INTERFERENCE WITH YOUR ENJOYMENT OF THE PROGRAM; THAT THE PROGRAM WILL
MEET YOUR REQUIREMENTS; THAT OPERATION OF THE PROGRAM WILL BE
UNINTERRUPTED OR ERROR-FREE, OR THAT THE PROGRAM WILL BE COMPATIBLE
WITH THIRD PARTY SOFTWARE OR THAT ANY ERRORS IN THE PROGRAM WILL BE
CORRECTED. NO ORAL OR WRITTEN ADVICE PROVIDED BY ELECTRONIC ARTS OR
ANY AUTHORIZED REPRESENTATIVE SHALL CREATE A WARRANTY. SOME
JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF OR LIMITATIONS ON IMPLIED
WARRANTIES OR THE LIMITATIONS ON THE APPLICABLE STATUTORY RIGHTS OF A
CONSUMER, SO SOME OR ALL OF THE ABOVE EXCLUSIONS AND LIMITATIONS MAY
NOT APPLY TO YOU.

197
notes/AnimationSequences.txt Normal file
View file

@ -0,0 +1,197 @@
# Tile animation sequences
#
# FIXME: This needs to be regenerated since I tweaked the animation sequences.
#
# This file can be processed with genAnimationTable.py to generate the same
# table as ../animate.cpp
#
# TODO: Remove water animation sequences as it animates the same tile (all
# those tiles are copies of each other)
#
# x08f -> x07f -> x06f -> x05f -> x08f
# x0cf -> x0bf -> x0af -> x09f -> x0cf
# Fire
x038 -> x039 -> x03a -> x03b -> x03c -> x03d -> x03e -> x03f -> x038
# Light traffic
x080 -> x070 -> x060 -> x050 -> x080
x081 -> x071 -> x061 -> x051 -> x081
x082 -> x072 -> x062 -> x052 -> x082
x083 -> x073 -> x063 -> x053 -> x083
x084 -> x074 -> x064 -> x054 -> x084
x085 -> x075 -> x065 -> x055 -> x085
x086 -> x076 -> x066 -> x056 -> x086
x087 -> x077 -> x067 -> x057 -> x087
x088 -> x078 -> x068 -> x058 -> x088
x089 -> x079 -> x069 -> x059 -> x089
x08a -> x07a -> x06a -> x05a -> x08a
x08b -> x07b -> x06b -> x05b -> x08b
x08c -> x07c -> x06c -> x05c -> x08c
x08d -> x07d -> x06d -> x05d -> x08d
x08e -> x07e -> x06e -> x05e -> x08e
x08f -> x07f -> x06f -> x05f -> x08f # Water, but all tiles are the same
# Heavy traffic
x0c0 -> x0b0 -> x0a0 -> x090 -> x0c0
x0c1 -> x0b1 -> x0a1 -> x091 -> x0c1
x0c2 -> x0b2 -> x0a2 -> x092 -> x0c2
x0c3 -> x0b3 -> x0a3 -> x093 -> x0c3
x0c4 -> x0b4 -> x0a4 -> x094 -> x0c4
x0c5 -> x0b5 -> x0a5 -> x095 -> x0c5
x0c6 -> x0b6 -> x0a6 -> x096 -> x0c6
x0c7 -> x0b7 -> x0a7 -> x097 -> x0c7
x0c8 -> x0b8 -> x0a8 -> x098 -> x0c8
x0c9 -> x0b9 -> x0a9 -> x099 -> x0c9
x0ca -> x0ba -> x0aa -> x09a -> x0ca
x0cb -> x0bb -> x0ab -> x09b -> x0cb
x0cc -> x0bc -> x0ac -> x09c -> x0cc
x0cd -> x0bd -> x0ad -> x09d -> x0cd
x0ce -> x0be -> x0ae -> x09e -> x0ce
x0cf -> x0bf -> x0af -> x09f -> x0cf # Water, but all tiles are the same
# Rotating radar at top of airport
x2c7 -> x340
x340 -> x341 -> x342 -> x343 -> x344 -> x345 -> x346 -> x347 -> x340
# Fountain
x348 -> x349 -> x34a -> x34b -> x348
# Rotating radar (elsewhere)
# TODO: Figure out whether we use this
x34c -> x34d -> x34e -> x34f -> x350 -> x351 -> x352 -> x353 -> x34c
# Smoking chimney
# BUG-FIX: x26d was x26c originally! (which is the last tile of empty industry)
x26d -> x354 # IND1
x354 -> x355 -> x356 -> x357 -> x358 -> x359 -> x35a -> x35b -> x354
# Explosion
x35c -> x35d -> x35e -> x35f -> x360 -> x361 -> x362 -> x363
x363 -> x363
# Chimney
x281 -> x374 # IND2
x374 -> x375 -> x376 -> x377 -> x374
# Chimney
x284 -> x378 # IND3
x378 -> x379 -> x37a -> x37b -> x378
# Chimney
x289 -> x37c # IND4
x37c -> x37d -> x37e -> x37f -> x37c
# Chimney
x28a -> x380 # IND5
x380 -> x381 -> x382 -> x383 -> x380
# Chimney
x2a4 -> x384 # IND6
x384 -> x385 -> x386 -> x387 -> x384
# Chimney
x2a5 -> x388 # IND7
x388 -> x389 -> x38a -> x38b -> x388
# Chimney
x2ae -> x38c # IND8
x38c -> x38d -> x38e -> x38f -> x38c
# Chimney
x2b1 -> x390 # IND9
x390 -> x391 -> x392 -> x393 -> x390
# Chimney at coal powerplant, relative position (2, 0)
747 -> 916
916 -> 917 -> 918 -> 919 -> 916
# Chimney at coal powerplant, relative position (3, 0)
748 -> 920
920 -> 921 -> 922 -> 923 -> 920
# Chimney at coal powerplant, relative position (2, 1)
751 -> 924
924 -> 925 -> 926 -> 927 -> 924
# Chimney at coal powerplant, relative position (3, 1)
752 -> 928
928 -> 929 -> 930 -> 931 -> 928
# Stadium (top part, bottom part)
x3a4 -> x3a5 -> x3a6 -> x3a7 -> x3a8 -> x3a9 -> x3aa -> x3ab -> x3a4
x3ac -> x3ad -> x3ae -> x3af -> x3b0 -> x3b1 -> x3b2 -> x3b3 -> x3ac
# Nuclear swirl (at nuclear power plant?)
820 -> 952
952 -> 953 -> 954 -> 955 -> 952
# Non-used tiles
956 -> 0
957 -> 0
958 -> 0
959 -> 0
960 -> 0
961 -> 0
962 -> 0
963 -> 0
964 -> 0
965 -> 0
966 -> 0
967 -> 0
968 -> 0
969 -> 0
970 -> 0
971 -> 0
972 -> 0
973 -> 0
974 -> 0
975 -> 0
976 -> 0
977 -> 0
978 -> 0
979 -> 0
980 -> 0
981 -> 0
982 -> 0
983 -> 0
984 -> 0
985 -> 0
986 -> 0
987 -> 0
988 -> 0
989 -> 0
990 -> 0
991 -> 0
992 -> 0
993 -> 0
994 -> 0
995 -> 0
996 -> 0
997 -> 0
998 -> 0
999 -> 0
1000 -> 0
1001 -> 0
1002 -> 0
1003 -> 0
1004 -> 0
1005 -> 0
1006 -> 0
1007 -> 0
1008 -> 0
1009 -> 0
1010 -> 0
1011 -> 0
1012 -> 0
1013 -> 0
1014 -> 0
1015 -> 0
1016 -> 0
1017 -> 0
1018 -> 0
1019 -> 0
1020 -> 0
1021 -> 0
1022 -> 0
1023 -> 0

79
notes/CALLBACKS.txt Normal file
View file

@ -0,0 +1,79 @@
Callback("UIAutoGoto", "dd", x, y);
Useful.
Callback("UIDidGenerateNewCity", "");
UI notification.
Callback("UIDidLoadCity", "");
UI notification.
Callback("UIDidLoadScenario", "");
UI notification.
Callback("UIDidSaveCity", "");
UI notification.
Callback("UIDidTool", "sdd", name, x, y);
Callback("UIDidntLoadCity", "s", msg);
Callback("UIDidntSaveCity", "s", msg);
Callback("UIDoPendTool", "ddd", tool, x, y);
Callback("UIDropFireBombs", "");
Callback("UILoseGame", "");
Callback("UIMakeSound", "ssdd", channel, sound, x, y);
Callback("UINewGame", "");
Callback("UIPlayNewCity", "");
Callback("UIReallyStartGame", "");
Callback("UISaveCityAs", "");
Callback("UISetCityName", "s", CityName);
Callback("UISetDate", "sdd", str, m, y);
Callback("UISetGameLevel", "d", GameLevel);
Callback("UISetMessage", "s", str);
Callback("UISetSpeed", "d", speed);
Should stop timer if speed == 0, and start timer if speed > 0.
Callback("UIShowBudgetAndWait", "");
Callback("UIShowPicture", "d", id);
Callback("UIShowZoneStatus", "ssssssdd", str, s0, s1, s2, s3, s4, x, y);
Callback("UIStartEarthquake", "");
Callback("UIStartLoad", "");
Callback("UIStartScenario", "d", scenario);
Callback("UIStopEarthquake", "d", magnitude);
Callback("UIWinGame", "");
Callback("UINewEvaluation", "");
Callback("UISimRobots", "");
Callback("UIUpdate", "s", name);
Called when an aspect of the model has changed:
map: when small overall map changes
Called by stubs.cpp.
Called by python micropolis engine subclass.
graph: when graph changes
Called by graph.cpp.
evaluation: when evaluation changes
Called by evaluation.cpp.
budget: when budget changes
Called by budget.cpp.
date: when date changes
Called by update.cpp.
funds: when funds change
Called by update.cpp.
demand: when demand changes
Called by update.cpp.
gamelevel: when game level changes
Called by utilities.cpp.
cityname: when city name changes
Called by utilities.cpp.
paused: when game is paused or resumed
Called by utilities.cpp.
speed: when speed changes
Called by utilities.cpp.
passes: when passes changes
Called by utilities.cpp.
options: when an option changed
Called by update.cpp.
taxrate: tax rate
Called by budget.cpp.
message(dddbb): message changed
Called by message.cpp.

57
notes/CODING-STYLE.txt Normal file
View file

@ -0,0 +1,57 @@
C++ coding style:
- Functions/Methods:
- Functions/methods use CamelCase names.
- Private/local functions/meyhods use camelCase, except for the first letter.
- Try to give functions/methods a name with at least two words (so they are
different from variables).
- Variables:
- Variables are lowercase_only, with an underscore connecting the words.
- Globals start with an _underscore_character.
- Do not use 'register' (compilers are much smarter about assigning variables
to registers).
- Constants:
- Constants are written in UPPER_CASE with an underscore character between
words.
- Related constants should have a short common prefix.
- Single constants are declared with "static const <type> MY_CONSTANT = <value>;"
- Groups of related constants are declared with an enum.
- Use decimal notation for values.
- Use hexadecimal notation for bitmasks (or better, express the mask as a
computation).
- End with "_BIT" in the name for bit positions.
- Layout:
- Indentation should be 4 at each level.
- No TAB characters.
- No white space at end of the line.
- Lines should mostly fit in 80 columns.
- Put a space between the keyword "if", "while", and "for" and the opening
bracket of the expression.
- Use space around operators ("1 + 2" instead of "1+2") and assignment
("x = 1" instead of "x=1").
- Expressions:
- Avoid assignments in expressions (compilers will shuffle them into the
expression if that is better).
- Be explicit in comparisons, "if (ptr == NULL)" and "if (val != 0)".
- No brackets when not needed.
- Avoid floating point computations.
- Documentation:
- Document everything with Doxygen.
Not decided:
- Comment style.
- Use of "this" in methods.
- Use "0" instead of "NULL" ("0" is the official C++ NULL value, but "NULL" seems
clearer).
- Python coding style (maybe simply use PEP-008)

48
notes/DevelopmentPlan.md Normal file
View file

@ -0,0 +1,48 @@
_(This page is several (at least 16 or so) years old. Much progress rewriting the code towards those goals has been made since it was written! Technology has changed a lot, but the same basic approach applies, but with Emscripten, Embind, and JavaScript/TypeScript and HTML/Canvas/WebGL instead of SWIG and Python and GTK/Cairo.)_
# Notes on a development plan, in progress #
I (Don Hopkins) have been cleaning up and translated the Micropolis (SimCity) source code to C++, and used SWIG to integrate it with Python.
It runs and animates the city on the screen, but it's not yet a playable game.
The ongoing Micropolis Core development work is checked into subversion on google code, in the "MicropolisCore" subdirectory: http://code.google.com/p/micropolis/source/browse
Micropolis Core is still a work in progress, of course -- the game is not yet playable, but you can scroll and zoom around the map, and I've hooked up the pie menus for switching tools.
I've been working on the editing and navigation tools -- they are not actually hooked up for editing the map yet, but the tool framework is in place.
The TileTool base class represents an editing tool, including the tile based SimCity map editors, the ink drawing and eraser tools, and the panning tool. The TileDrawingView distributes events to the appropriate tools. There is a current editing tool, as well as a spring loaded navigation tool (for panning and zooming), which activates when you press a key.
One consideration is that I'm factoring the TileDrawingView and TileTool code into two layers: one generic layer that is specific to the tile view but not specific to Micropolis, and then a higher level layer which subclasses the generic classes. There is a set of subclasses specific to Micropolis, as well as another set of subclasses specific to a cellular automata machine (CellEngine). This layer of abstraction makes it a bit more complicated than it would be if it were monolithic, but it's well worth it, because I want the tile engine to be useful for other projects. Using the generic classes for more than one project ensures that they will be well factored and support other projects without special cases.
The C++ code still needs to be reorganized and cleaned up a lot -- I've just done the first cut of a translation. There is still a lot of old cruft in there that needs to be stripped out. But the tool stuff was a good obvious place to start working.
The essential thing is to decide what is user interface stuff that goes on the outside and should not be handled by C++, and what is essential simulation stuff that goes on the inside and should be handled by C++, and then defining a nice clean simple interface between them.
For example, one thing that I did to support the new tool stuff was to eliminate all the old "view" and "x11" oriented structures from C++ code that were being passed into the tool editing API. The old "view" was a TCL/Tk widget in the old micropolis-core code, with lots of X-Windows cruft hanging off of it. So now the view and user interface layer is implemented in Python (and another independent module, TileEngine), totally independent of the simulation engine. So somebody else could write a 3D view, or a web server view, or whatever.
Now the C++ code does not know about any view stuff -- it just knows how to expose the information that any kind of view might need to know. The "tile engine" is a kind of view that draws the map with zoomable tile images, using the Cairo graphics library. The "Micropolis engine" (the city simulator) has an interface for getting a pointer to its tile memory buffer. Python code directly introduces the Micropolis engine's tiles to the tile drawing engine, along with some information describing the layout and format of the tiles in memory, and a bitmap of tiles to use. So there is no Python interpreter overhead when drawing the tiles.
The high level tool user interface layer written in Python transforms mouse coordinates to tile coordinates, and calls micropolis to edit on the map in terms of tile coordinates. So the core simulator does not have to know anything about view transformations.
The tile engine has a lazy optimization to make it zoom faster, by not scaling all possible tiles in advance. The first time it draws a tile at a certain scale, it calls back into Python to render that tiles on demand. The Python code can scale a bitmap or draw scaled graphics with Cairo or SVG. Only the needed tiles are cached at any particular scale, which makes it possible to zoom in close to the map quickly without wasting a lot of time and memory.
There is lots of stuff that needs to be done along the lines of cleaning up and rationalizing the C++ code and interface.
The code is cluttered with unnecessary layers of indirection, superfluous methods and unused variables, much of which is left over from the old legacy platforms like TCL/Tk, X11 and MacOS.
Right now it is one giant public cluster fuck of a C++ class that encapsulates the entire simulator. In the long term it would be good to refactor it into multiple classes that don't know as much about each other. But the prerequisite to that is to strip it down, minimalize and privatize it as much as practical, then judiciously build it back up by adding useful utilities and interfaces, to support all kinds of interesting views and editors.
I've tried to do all the hard stuff first that requires intimate knowledge of the code and its history, and leave the stuff that is more obvious and straightforward (and fun) for other people to do.
The C++ header file and source code is organized to reflect the files that the original code was arranged in. This was useful for the clean-up process, just getting the code to work, but now that it works, there is no reason for it to be organized the arbitrary way it is.
For example there are several groups of randomly jumbled miscelaneuous functions, thunks, adaptors, compatibility libraries, glue, utilities, etc. Like functions that emulate old Mac APIs that are no longer necessary. They need to be ripped out and replaced by better organized code that does what is needed instead of doing what was being done for historical reasons.
A typical example is the random number generator, which should be standardized and seedable (so it can be synchronized for the multi player game) and replaced with a much better one. Another example is the diverse set of formatting utilities (like money and time and text messages): those don't really belong in the core, because they should be part of the user interface layer because of internationalization issues. The core should just expose raw data like floating point numbers or dates, and the user interface should fish them out and format them according to the locale.
Something that needs to be done systematically is to remove all strings hard coded into the code, and replace them with symbols that can be looked up by the user interface layer in translation files to display to the user. So any C++ code that formats messages should be rewritten to just expose the raw data, and then Python code should be written to take that data and properly format and display it so it can be internationalized and translated to other languages.
There are a bunch of old Mac resource oriented things inherited from the old code, which are ugly and brittle, and only make it harder to internationalize the code and manage its resources. Anything that looks like it's using Mac resources should be rewritten to use a simpler lower tech way of accomplishing whatever it's trying to do, or defer the work and decisions to Python code if appropriate, and just export raw essential data out of the C++ code.
It would be great for programmers to read over the C++ code with fresh eyes and write some notes and questions about "what the hell is it doing here" and "why is this so weird". Please send any notes or questions you have to me, and we can come up with a more detailed battle plan about what needs to be done to clean up and rationalize the code.
-Don

88
notes/DocTCL.txt Normal file
View file

@ -0,0 +1,88 @@
editorview .editor
-display host:0?
.editor
configure ...
position ?x y?
size ?w h?
Pan ?x y?
ToolState ?state?
ToolMoveTo x y
ToolDragTo x y
PanStart x y
PanTo x y
Visible ?0..1?
KeyDown key
KeyUp key
TileCoord x y
mapview .map
?-display host:0?
.map
configure ...
position ?x y?
size ?w h?
MapState ?0..8?
ZoneType ?0..3?
PopnRate ?0..1?
PoliceRadius ?0..1?
PanStart x y
PanTo x y
ViewAt x y
Visible ?0..1?
sim
GameStarted
InitGame
SaveCity
GenerateNewCity
ReallyQuit
UpdateMaps
UpdateGraphs
UpdateEvaluations
UpdateBudgets
DoBudget
Pause
Resume
CheckLicense
StartBulldozer
StopBulldozer
MakeFire
MakeFlood
MakeAirCrash
MakeTornado
MakeEarthquake
MakeMonster
MakeMeltdown
SoundOff
LoadScenario 1..8
LoadCity filename
SaveCityAs filename
MakeExplosion x y
InstallKey 0..1 key
MakeSound id
StartSound id
StopSound id
CityName ?name?
GameLevel ?1..2?
Speed ?0..7?
Delay ?int?
HeatSteps ?steps?
HeatFlow ?flow?
HeatRule ?rule?
Funds ?funds?
TaxRate ?0..20?
FireFund ?int?
PoliceFund ?int?
RoadFund ?int?
AutoBudget ?0..1?
AutoGoto ?0..1?
AutoBulldoze ?0..1?
Disasters ?0..1?
Sound ?0..1?
FlushStyle ?0..2?
MonsterGoal ?x y?
TornadoGoal ?x y?
HelicopterGoal ?x y?
MonsterDirection ?-1..7?

474
notes/MultiPlayerIdeas.txt Normal file
View file

@ -0,0 +1,474 @@
Notice window
welcome
scenario descriptions
warnings
zone status window
display live map picture
reconfigure to support various tasks
editors for chaging zone
invest $ => develop zone => increase land value
population density
crime prevention
environmental cleanup
enhance growth
editor
pie menus
demand gauge
budget
multi user dialog
hour glass timeout
auto budget toggle
pause/resume toggle (to allow changing budget while simulation is running)
map
drag rectangles to pan map views
menus on palette
generate terrain mode
lengend
rearrange
switch overlays
dynamic zone finder
graph
2x3 palelet, 10/120 years
double buffering
communicate data. hard wire in c?
evaluation
historical graphs?
surveyor
other editors
dynamic zone finder
washboard filter sliders
get key dialog
new city -- or "use map"?
"lobby"
name, level
scenario selection
random terrain generator
player can propose a city by selecting a scenario, loading a city, or generating a random terrain.
all players must vote unanimously on a city to play
selecting a new city clears all votes
players can press next/previous to page through proposed city history
you can go back to randomly generated terrains, because it saves the random number generator seed
clears votes, proposes new or old city
terrain editor todo:
Integrate terrain editor code into map editor,
and have a button on the new city map to run in terrain editor mode.
Terrain editor will include only terrain editing tools,
plus random terrain generation interface,
and simulator will be paused.
print dialog
Newspaper printing and publishing metaphore.
Optionally save a snapshot of the city state, to link to from the newspaper article.
Publish in newspaper, print on paper, save to disk, copy to clipboard,
add to journal, blog, etc.
Allow user to enter text to be printed along with an image, like blogging.
Can print any map or editor view with data overlay and chalk drawings,
entire map (fit on one page, or split across multiple pages),
or other windows like graph, evaluation, notices, messages, chat log, etc.
Export text content as html with embedded images.
Make an html/image city overview and journal, like The Sims family view and scrapbook.
Printable windows and views should have a "print" button or function that pops up a
pie menu of possible destinations, for quickly making snapshots in your journal, etc.
Publish illustrated newspapers in the game, like The Sims storybook, with newspaper
articles composed of pictures of the city, text excerpts from chat logs, etc.
A player could be a "reporter" interviewing other player politicians via chat,
before and after the vote on building a stadium, asking them to make their case for
or against the stadium, and publish the interviews in the game's newspaper, the
"Micropolis Journal".
Players can browse each others newspapers over the net, and download the city snapshots
the articles write about.
Flash: Monster invades Micropolis, near nuclear reactor!
(story and link to saved city so you can read the story, then bring up the city and
play it live from the point the story was written)
quit
confirm
multi player logout
save dialog
load dialog
network city browsing and sharing
"What-If?" history tree.
Publish your cities on the net.
Download other peoples cities.
Use a URL to point to a saved city.
Grab a live snapshot of somebody's running city.
Checkpoint and branch timelines.
Save a city back to the point where it branched,
to create an alternate history that other players can load.
Multiple players build a tree of saved cities with branching alternate histories.
Like the parallel universes in Niven's All the Myriad Ways.
Rewind any city up the tree and select available alternate histories at each branch point.
Play back alternate histories edit by edit, stop them at any point and take over,
making a new branch point at that location.
When you play together in the same city, you have to discuss and agree with other players
about what to do, and convince other people of your ideas.
You can try an idea out yourself, by branching your own private history,
giving your idea a try, and reporting back to the other players in the main shared timeline
what happened (with links to the save file and history so other players can see for themselves).
GUI: Branching history tree outline viewer of saved files.
Drag and drop a history point into the chat log which other players can click on to open a
live view playing that history.
status control
views
players
new player
new view
Keep and export logs of simulation values
r, c, i demand
evaluation
tax rate, collected
funds
funding levels
event logs
simulation events
extend simulator to log all interesting simulation events,
so newspaper reporters can write stories about them
editing commands
Log enough information to replay all edits against a save file to recreate same city.
This is the key to high level multi player protocol between
multiple parallel lock-step simulations, like The Sims Online,
better than using low level x11 to implement the multi player
interface.
Treat any editing command as a "what-if" branch point where it could go another way.
Give players an easy interface to replay a simulation up to a branch point, and
and re-make the decision, to see how it would turn out differently.
chat logs
everything else of course
web service to access logs
export logs as xml for programs or csv for spreadsheets
import and export chalk overlay as vector drawing
support image overlays with transparency (begs for photoshop-like drawing interface)?
Careful how far down that road you go, because you could use it to paint the image of
a happy emerald green city over a dreary industrial wasteland.
The simple white chalk overlay has the advantage that you always know what's chalk and what's not.
opml outline with geo-codes
store city overlay information in opml
register the corners of the map with real-world lat/long values
allow rotation and scaling but not arbitrary shearing or distortion
register nodes of the opml outline at lat/long points and areas on the map
what's a good way to associate an opml node with an arbitrary area on the map?
an attribute with a polygon in lat/long coordinates?
a list of rectangles in lat/long coordinates?
a list of tiles in row/col coordinates?
associate geo-coded opml nodes with features on the map like
zones, buildings, streets, neighborhoods
use opml nodes to give names to features,
take notes about them,
attach pictures to them,
write stories about them,
support overlapping features, so roads can cross,
and each tile can belong to any number of features.
allow users to plant signs on the map, like micropolis 2000.
represent signs with an opml node.
signs can contains arbitrary opml outlines
with links to other opml nodes
like a sign at a crossroad, linked to the nodes representing each road,
and the regions of the city that the roads bring you to.
use opml to write a city guide
attach chalk overlays and signs to opml nodes so you can show and hide them hierarchically
head window
Represents root window of Micropolis application to TCL, and ties all the other windows together.
Contains the application's main menus and scrolling message and chat log.
An artifact of the way TCL/Tk/X11 works.
With another gui, might be the main base window that contains all other subwindows.
In X11, we depend on the user's chosen X11 window manager to manage all the separate windows.
In a better world (Sugar) Micropolis should let users save and restore windows
configurations and multiple views, tailored for various roles and tasks.
When a new player joins, the select a role to play, which will grant them
permissions and customize the interface, opening and positioning the appropriate
windows and tools for their role.
Each role supports various tasks that might themselves reconfigure the user interface.
User interface configurations should be selected based on the role and the task.
Users first select a role that stays the same (forever or most of the time)
and which grants them a set of permissions.
Each role supports a set of tasks (like Eclipse's "aspects"), which users may
switch between, to reconfigure the user interface.
Players can hold elections to grant each other roles
(like mayor, treasurer, planner, builder, reporter, god, etc).
Ownershop
This vastly complicates the game, so I didn't try it, but I wrote down some ideas.
Consider the screen area of the user interface it would require to
enable the user to micro-manage all the ownership issues, in terms of
the number of acres of city map it would cover.
It seemed like it would be too complicated to be fun.
Even if it could be magically implemented with a simple gui, would it be any fun?
That said, here are some ideas.
Ownership plane: 0 => nobody, 1-256 => user id
(note: Can't save ownership user ids into save files if we want multiple
players to enter and exit independently from the city itself, or if we
want to support an open-ended, possibly large number of players over time.
As I said, this gets complicated pretty fast, without a lot of beneficial fun.)
Players have separate funds.
This raises issues about: who gets paid how much of the city's overall income,
and who pays for city services?
Could have a main shared city budget, then certain players can be appropriated
funds from that budget earmarked to perform various tasks.
But again, that gets pretty complicated, and how is it fun?
Competition or cooperation?
Should we attempt to make the game support competition between players,
or is it better to keep it cooperation-oriented, by requiring unanimous votes,
sharing the budget, etc.
I think it's simpler and more educational to give players the freedom to misbehave,
while building in social networking and accountability, to let players discuss,
negotiate, make and break deals, establish reputations, reward good behavior,
and punish bad behavior, by developing real-world social interaction skills.
What fun would politics be if you couldn't have scandals?
Land value
higher resolution land value grid
effected by sales
asking price
Tiles are owned by someone, and may be for sale, and given an asking price by the owner.
Requires complex user interface for selecting tiles, assigning price, etc.
How is that fun?
Groups of tiles: parcels of land, for sale all at once, to highest bidder.
M.U.L.E.-like multi player auctions for land.
Developers can build on empty tiles that are for sale, and they're bought automatically.
What's so fun about being a developer? Nothing to do after setting the price of the land.
Buyers can offer to buy something that doesn't have a price, which initiates an
M.U.L.E. dialog with the owner, and allows other players to join in the auction,
submitting their own bids.
Transaction tool - $ (or local currency symbol)
select group of cells
negitiate deals with the owners
automatically calculates default land value suggested price (upon which the tax rate based)
based on modified land value through worth
communication window
so people can negotiate and talk
irc-like chat rooms where people can have a side discussion
private person-to-person messages
calculate evaluation for each player
Independent and combined scores and statistics.
Hard to define what this means in terms of the current simulation.
Would have to deeply change the way the simulation works,
but then would it still be fun?
Zone ownership.
Develop Micropolis into a more Monopoly-like game: SimCitopoly.
A player can own power plants and other utilities, and makes money
by selling electricity and other services to other players.
Zones don't develop until someone buys them.
Own residential => collect rent, pay maintainence.
Own industrial, commercial => collect income, pay expenses.
All zone owners pay taxes.
Multi player editig tools
Recast editing tools/cursors as sprites/robots.
Navigate tools around the map like a turtle/car/helicopter.
Also move tools with the mouse.
Alternative interfaces:
Tool cursor follows cursor all the time. (current "traditional"
implementation)
Relegates pie menu and panning to secondary status: shift/option keys.
Move tool while shift or option key is down.
Makes it possible to put the pie menu or pan tool on the
primary unshifted mouse click/drag gesture.
Pick up and drag tool.
Properties the interface should support:
Direct manipulation.
http://en.wikipedia.org/wiki/Direct_manipulation
Continuous representation of objects of interest, and rapid,
reversible, incremental actions and feedback.
Real-world metaphores for objects and actions.
Allow a user to directly manipulate objects presented to them,
using actions that correspond at least loosely to the physical
world.
Pick up, drag and manipulate and edit first class objects like
tools, sprites, robots, avatars, etc.
First person.
Represent users with in-game avaters.
Relative polar coordinate system. (Logo turtle graphics.)
http://en.wikipedia.org/wiki/Turtle_graphics
Drive the helicopter around on the map.
Keys to relatively rotate clockwise, counter-clockwise.
Keys to turn to absolute directions (N/S/E/W/NW/NE/SW/SE
keypad).
Keys to go forward and backward in the current direction.
Keys to strafe left and right of the current direction.
Also a remote control panel with graphical control for the mouse.
iPhone app that lets you remotely control the helicopter
(or whatever) form your iPhone.
Doesn't even need to support editing the map. Just fly
around and chat. (voice chat?)
Operate avatar with keyboard, game controller, control panel,
etc.
Natural language based.
http://en.wikipedia.org/wiki/Natural_language_user_interface
Text command interface in chat window.
Fully usable via keyboard input and speech recognition.
Conversational interface with intelligent, helpful "chat bots",
as well as on-line teachers and mentors.
Educators and entertainers can write interesting, informative
personality simulation scripts for chat bots, that interactively
chat with students playing the game, answer frequently asked
questions, perform various utilities (like a banker or loan
shark you can borrow money from), and refer them to web links,
wiki pages, discussion groups, etc, for more information and
interaction with real people. Scripts can be triggered by
pattern matching on chat text from player, or monitoring game
events and conditions. Chat bots can remember things about
players, and continuously tell long stories and share
personalized knowledge over a long period of time.
Text based command interface inspired by ideas from Jeff and Aza
Raskin's work.
The Humane Interface
http://en.wikipedia.org/wiki/The_Humane_Interface
The book puts forward a large number of interface design
suggestions, from fairly trivial ones to radical ones. The
overriding theme is that current computer interfaces are
often poor and set up users to fail, as a result of poor
planning (or lack of planning) by programmers and a lack of
understanding of how people actually use software.
Ubiquity
http://en.wikipedia.org/wiki/Ubiquity_(Firefox)
Ubiquity, an add-on for Mozilla Firefox, is a collection of
quick and easy natural-language-derived commands that act as
mashups of web services, thus allowing users to get
information and relate it to current and other webpages. It
also allows Web users to create new commands without
requiring much technical background.
Multi-player tools that require more than one person to operate.
The X11 multi player version required players to vote on expensive
zones including stadiums, seaports, nuclear power plants, coal
power plants and airports.
When a player places an expensive zone, it is not immediately
drawn on the map.
Instead, a shadow is cast over the tiles
where it would be placed, and the zone is animated bouncing up
and down above the shadow.
This draws the user's attention, and makes it obvious that the
zone has not been "plugged in" yet.
A "voting dialog" opens up in a window, that says "Don has
proposed to build a nuclear power plant for $5000. Do you
support that proposal?", with an animated view of the bouncing
building, and a "YES" and "NO" button. Or a hand with a thumb,
that you can turn up or down (a two item pie menu).
Besides pressing the "YES" button, There is a shorthand way to
vote yes to a proposal: select the same tool, and draw the same
zone in the same place.
When enough people have voted for the proposal (unanimous), the
zone lowers down, plugs into place, and starts simulating.
Ideas for new design for multi player building tools:
It takes several people to agree to buy an airport, and where to
put it.
In-game voting dialog, around the proposed site of a building.
Like the bouncing buildings in the X11 multi player game, but
with a in-game voting interface on the map, instead of in a
separate dialog. (direct instead of indirect manipulation)
When you place an airport, it doesn't actually get built
immediately. It just places a "proposal" hovering over the map,
represented by a suitably ghosted image of the airport, floating
up and down, with adjacent text describing the proposal and
voting buttons.
I think this is simpler and more "local" than the X11 voting
interface, since the text and voting controls are drawn over the
map next to the zone, instead of displayed them in a separate
window. Also, several proposals can be going on at the same time
at different (or the same!) places on the map, which the X11
version did not support.

366
notes/OLPC-notes.txt Normal file
View file

@ -0,0 +1,366 @@
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.

317
notes/PLAN.txt Normal file
View file

@ -0,0 +1,317 @@
Plan for developing Micropolis for OLPC and other platforms.
DONE:
First, get the old TCL/Tk/X11 version cleaned up and running on
the current OLPC platform, and passed through EA's legal and
quality assurance process.
DONE:
Screen depth and size: fixed size of OLPC screen.
Window management: one window.
Simplify window management. Single map and editor view. Tiled graph and evaluation windows.
Rearrange startup screen so it works in the full window mode.
Make budget window and file dialogs be transient popup windows.
Add "Enable/Disable Auto Budget" button to budget window.
Click on small R/C/I gauge to toggle evaluation window.
Click on small graph to toggle graph window.
Click on funds or tax rate to show budget window.
Disable multi player features by default (added -m flag to enable multi player mode).
Disable other experimental features (cellular automata, dynamic query, etc).
Add -S flag to enable Sugar features, and TCL access to test flag.
Enable audio: Use Sugar audio server.
Convert sounds to new audio format (currently wav).
Fix fonts.
Pick nice Sugar fonts to use, based on Sugar flag.
Make Sugar activity wrapper in Python.
TODO, in progress:
Update manual and documentation.
Put new graphics and icons into interface and menus.
DONE:
Replace TCL/Tk with Python/GTK, and use Pango/Cairo for graphics.
Implement custom components in PyGTK.
Map view.
Editor view.
Date view.
Graph view.
Pie menus.
Cellular Automata Machine view.
DONE:
Implement web based interface with TurboGears/Cairo/OpenLaszlo/Flash/AMF.
TODO for OLPC:
Integrate with Sugar and OLPC hardware.
Audio.
Support CSound audio mixer.
Switch to a smaller audio format.
Record better sounds.
Internationalization.
Graphics.
Hires monochrome.
SVG graphics and icons.
Create better icons.
Sugar integration.
Integrate with OLPC activity system, window manager, etc.
Rework user interface to follow Sugar user interface guidelines.
Keyboard control.
Support OLPC keyboard layout and device buttons.
Game keypad interface for book mode.
Optimization.
Optimize power management.
Optimize size.
Optimize speed.
Documentation.
Integrated help, tutorials, essays on city design from manual, etc.
Voiceovers, demos, journal playback.
Courseware.
Map annotation.
Journaling.
Event history.
Edit history.
Checkpointing.
Branching histories.
Rewinding and fast forwarding.
Publishing newspaper articles linking to save files.
URL to link into a city at a particular location on the map.
Grid networking.
Multi player stupport.
Sharing cities.
Colaborative editing.
Voting.
Chat.
White board.
TODO for Education:
Educational.
Bring old Micropolis courseware up to date, and integrate with the game.
Export simulation data to spreadsheet or xml.
Creative writing, storytelling, newspaper reporting, blogging, etc.
Scenarios and experiments.
What-if?
Branching history at decision point, and comparing different results.
Scripting.
Open up the simulator to Python.
Web services to remotely monitor and control simulation.
HTML or AJAX web server remote control interface.
Support multi player interactions through web server.
Submit a proposal to build a stadium over the web.
Style it like a real civic government web page, that allows citizens to participate online.
Enable extending the graphics, tiles, sprites.
Enable programming behaviors, defining new zones, new global variables, overlays, etc.
Cellular automata.
Visual programming.
Programming by example.
KidSim, AgentSheets.
Robot Odyssey.
TODO for Programming:
Visual Programming
Simplify the Micropolis interface and make it easier for kids to
use it with the game controller, in a way that will support
multi player interaction.
Collapse the separate concepts of game editing tool (bulldozer,
road, residential zone, etc) and agent (sprites like the
monster, tornado, helicopter, train, etc).
Agents with specialized tool represent different roles that kids
can play. A bunch of kids can join together and play different
roles at the same time in the same city. Instead of having a
bunch of editing tools to switch between, you have a bunch of
different agents you can drive around the map, like using a
monster to crush things instead of a bulldozer, or riding around
in a helicopter to scroll around and observe the map. Make a
meta-game like pokemon trading cards or magic the gathering,
about acquiring and deploying and using agents on the map. Give
agents different budgets and constraints.
Use an agent to represent a user in the world, and control an
editing tool. You see other users in the map driving around
their editing tool agents.
Each editing tool can be associated with a particular agent,
with a keyboard/game controller based user interface for moving
around, as well as a mouse based interface for picking it up and
dragging it around.
The road tool becomes a road building vehicle, that you can
easily move up/down/left/right/diagonally with the game
controller directional input. Requires much less coordination to
draw straight roads than with a mouse.
The bulldozer tool becomes an actual bulldozer that you can
drive around the map, crushing things in your wake.
This makes the game easily usable by little kids in book mode.
Also support small children using Micropolis like a drawing tool or
etch-a-sketch, simply doodling with the editing tools for the
visceral pleasure of it, and setting fires and other disasters
to watch it burn and mutate.
Logo Turtles (as a generalization of the monster, tornado,
helicopter, etc)
Implement programmable logo turtles as agents that can move
around on the map, sense it, and edit it.
Like Robot Odyssey agents, so you can go "inside" an agent,
and travel around with it, operate its controls, read its
sensors, and automate its behvior by wiring up visual programs
with logic and math and nested "ic chip" components.
Plug in graphics to represent the agent: use classic logo
turtle and Micropolis sprites, but also allow kids to plug in
their own.
Micropolis sprites have 8 rotations.
SVG or Cairo drawings can be rotated continuously.
Re-implement the classic Micropolis agents like the monster,
tornado, helicopter, train, etc in terms of logo turtles, that
kids can drive around, learn to use, open up and modify (by
turning internal tuning knobs, or even rewiring).
Let kids reprogram the agents to do all kinds of other stuff.
Mobile robots, that you can double click to open up into
Robot-Odyssey-esque visual program editors.
Agents have local cellular-automata-like sensors to read
information about the current and surrounding tiles.
KidSim / Cocoa / StageCraft Creator let kids define visual
cellular automata rules by example, based on tile patterns and
rules. Show it a pattern that you want to match by selecting
an instance of that pattern in the world, then abstract it
with wildcards if necessary, then demonstrate the result you
want it to change the cell to in the next generation.
Sense high level information about zones and overlays, so the
agents can base their behavior on any aspect of the world
model.
Support an extensible model by allowing users to add more
layers.
Add layers with arbitrary names and data types at
different resolutions:
byte, int, float, n-dimensional vector, color, boolean
mask, musical note, dict, parametric field (i.e. perlin
noise or other mathematical function) at each cell, etc.
Edit the world.
All Micropolis editing tools (including colored pens that draw
on overlays) should be available to the agent.
Enable users to plug in their own editing tools, that they
can use themselves with the mouse, keyboard or game
controller, or program agents to use to edit the map under
program control.
Robot Odyssey
Build your own universal programmable editing tool.
Roll your own von Neuman Universal Constructor.
Smart robots you program to perform special purpose editing tasks.
The "Painter" picture editing program had a way of recording
and playing back high level editing commands, relative to the
current cursor position.
Remixing. Journaling. Programming by demonstration or example.
You could use a tape recorder to record a bunch of Micropolis
editing commands that you act out (or you can just select them
from the journal), then you can play those tapes back with
relative coordinates, so they apply relative to where the
agent currently is on the map. You can copy and paste and cut
and splice any editing commands into tapes that you can use to
program the robot to play back in arbitrary sequences.
Program an urban sprawl development-bot to lay out entire
residential subdivisions, complete with zones, roads, parks and
wires. Then program a luddite roomba-bot that sucks them all
up and plants trees in their place.
This becomes really fun when we let players plug in their own
programmed zones for the robot to lay out, and layers of data
to control the robot's behavior, out of which they can program
their own cellular automata rules and games (like KidSim /
Cocoa / StageCraft Creator).
========================================================================
--
Micropolis, Unix Version. This game was released for the Unix platform
in or about 1990 and has been modified for inclusion in the One Laptop
Per Child program. Copyright (C) 1989 - 2007 Electronic Arts Inc. If
you need assistance with this program, you may contact:
http://wiki.laptop.org/go/Micropolis or email micropolis@laptop.org.
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or (at
your option) any later version.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details. You should have received a
copy of the GNU General Public License along with this program. If
not, see <http://www.gnu.org/licenses/>.
ADDITIONAL TERMS per GNU GPL Section 7
No trademark or publicity rights are granted. This license does NOT
give you any right, title or interest in the trademark SimCity or any
other Electronic Arts trademark. You may not distribute any
modification of this program using the trademark SimCity or claim any
affliation or association with Electronic Arts Inc. or its employees.
Any propagation or conveyance of this program must include this
copyright notice and these terms.
If you convey this program (or any modifications of it) and assume
contractual liability for the program to recipients of it, you agree
to indemnify Electronic Arts for any liability that those contractual
assumptions impose on Electronic Arts.
You may not misrepresent the origins of this program; modified
versions of the program must be marked as such and not identified as
the original program.
This disclaimer supplements the one included in the General Public
License. TO THE FULLEST EXTENT PERMISSIBLE UNDER APPLICABLE LAW, THIS
PROGRAM IS PROVIDED TO YOU "AS IS," WITH ALL FAULTS, WITHOUT WARRANTY
OF ANY KIND, AND YOUR USE IS AT YOUR SOLE RISK. THE ENTIRE RISK OF
SATISFACTORY QUALITY AND PERFORMANCE RESIDES WITH YOU. ELECTRONIC ARTS
DISCLAIMS ANY AND ALL EXPRESS, IMPLIED OR STATUTORY WARRANTIES,
INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY, SATISFACTORY QUALITY,
FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT OF THIRD PARTY
RIGHTS, AND WARRANTIES (IF ANY) ARISING FROM A COURSE OF DEALING,
USAGE, OR TRADE PRACTICE. ELECTRONIC ARTS DOES NOT WARRANT AGAINST
INTERFERENCE WITH YOUR ENJOYMENT OF THE PROGRAM; THAT THE PROGRAM WILL
MEET YOUR REQUIREMENTS; THAT OPERATION OF THE PROGRAM WILL BE
UNINTERRUPTED OR ERROR-FREE, OR THAT THE PROGRAM WILL BE COMPATIBLE
WITH THIRD PARTY SOFTWARE OR THAT ANY ERRORS IN THE PROGRAM WILL BE
CORRECTED. NO ORAL OR WRITTEN ADVICE PROVIDED BY ELECTRONIC ARTS OR
ANY AUTHORIZED REPRESENTATIVE SHALL CREATE A WARRANTY. SOME
JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF OR LIMITATIONS ON IMPLIED
WARRANTIES OR THE LIMITATIONS ON THE APPLICABLE STATUTORY RIGHTS OF A
CONSUMER, SO SOME OR ALL OF THE ABOVE EXCLUSIONS AND LIMITATIONS MAY
NOT APPLY TO YOU.

263
notes/ROADMAP.txt Normal file
View file

@ -0,0 +1,263 @@
========================================================================
Roadmap of the Micropolis source code.
========================================================================
Micropolis designed and implemented by Will Wright,
Unix porting, optimization and multi player user interface design
by Don Hopkins (dhopkins@DonHopkins.com), for DUX Software.
========================================================================
Documentation:
manual
User manual and help page templates.
src/notes
Notes, to-do lists, lists of potential bugs to work on, and screen
snapshots.
Resources:
res
Resources, data, TCL code, etc.
Modified standard TCL/Tk widget libraries to support multiple
displays, by removing uses of global variables, and instead
storing screen-specific data in tk_priv map,
keyed by "<variable>@<screen>" where screen is
"[winfo screen $w]", the screen identifier.
Data files:
hexa.112
hexa.232
hexa.384
hexa.385
hexa.386
hexa.387
hexa.388
hexa.456
hexa.544
hexa.563
hexa.999
Scenarios:
snro.111
snro.222
snro.333
snro.444
snro.555
snro.666
snro.777
snro.888
String resources:
stri.202
stri.219
stri.301
stri.356
Audio files:
aaah.au
a.au
airport.au
beep.au
boing.au
bop.au
build.au
bulldoze.au
chalk.au
coal.au
com.au
computer.au
cuckoo.au
e.au
eraser.au
expl-hi.au
expl-low.au
fire.au
honk-hi.au
honk-low.au
honk-med.au
ignition.au
ind.au
monster.au
nuclear.au
o.au
oop.au
park.au
police.au
quack.au
query.au
rail.au
res.au
road.au
rumble.au
seaport.au
siren.au
skid.au
sorry.au
stadium.au
traffic.au
uhuh.au
unix.au
whip.au
wire.au
woosh.au
zone.au
Modified TCL/Tk standard library code:
button.tcl
Modified to support multiple displays.
menu.tcl
Modified to support multiple displays.
text.tcl
Modified to support multiple displays.
tk.tcl
Modified to support multiple displays.
buildidx.tcl
entry.tcl
init.tcl
listbox.tcl
mkindex.tcl
parray.tcl
tclinit.tcl
tkerror.tcl
wish.tcl
wishx.tcl
tclindex
tcl.tdx
tcl.tlb
tk.tdx
tk.tlb
Micropolis user interface code:
micropolis.tcl
Micropolis utilities and shared interface code.
help.tcl
Micropolis help messages.
wask.tcl
Ask question window.
wbudget.tcl
Budget window.
weditor.tcl
Map editor window.
weval.tcl
Evaluation window.
wfile.tcl
File open window.
wfrob.tcl
Frob window (dynamic zone finder sliders).
wgraph.tcl
Graph window.
whead.tcl
Head main application window.
whelp.tcl
Help window.
wmap.tcl
Map overview window.
wnotice.tcl
Notice message window.
wplayer.tcl
Add player window.
wscen.tcl
Choose scenario window.
Micropolis sound server code:
sound.tcl
Code loaded by sound server,
which runs in another process,
and is controlled via the TCL "send" command.
No longer used.
Sound should be built into Micropolis, using a modern standard sound library (and file formats).
Base Libraries:
src/tcl
TCL language interpreter.
Free software.
Modified for unix porting.
src/tk
Tk user interface toolkit.
Free software.
Modified for unix porting, multiple display support, various extensions and bug fixes.
See src/notes/to.ouster (message about multiple display support),
src/notes/TkVersion (description of origin and changes in tk)
src/tclx
Useful extensions to TCL/Tk.
Free software.
Modified for unix porting.
Micropolis source code:
src/sim
src/sim/terrain
========================================================================
Micropolis, Unix Version. This game was released for the Unix platform
in or about 1990 and has been modified for inclusion in the One Laptop
Per Child program. Copyright (C) 1989 - 2007 Electronic Arts Inc. If
you need assistance with this program, you may contact:
http://wiki.laptop.org/go/Micropolis or email micropolis@laptop.org.
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or (at
your option) any later version.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details. You should have received a
copy of the GNU General Public License along with this program. If
not, see <http://www.gnu.org/licenses/>.
ADDITIONAL TERMS per GNU GPL Section 7
No trademark or publicity rights are granted. This license does NOT
give you any right, title or interest in the trademark SimCity or any
other Electronic Arts trademark. You may not distribute any
modification of this program using the trademark SimCity or claim any
affliation or association with Electronic Arts Inc. or its employees.
Any propagation or conveyance of this program must include this
copyright notice and these terms.
If you convey this program (or any modifications of it) and assume
contractual liability for the program to recipients of it, you agree
to indemnify Electronic Arts for any liability that those contractual
assumptions impose on Electronic Arts.
You may not misrepresent the origins of this program; modified
versions of the program must be marked as such and not identified as
the original program.
This disclaimer supplements the one included in the General Public
License. TO THE FULLEST EXTENT PERMISSIBLE UNDER APPLICABLE LAW, THIS
PROGRAM IS PROVIDED TO YOU "AS IS," WITH ALL FAULTS, WITHOUT WARRANTY
OF ANY KIND, AND YOUR USE IS AT YOUR SOLE RISK. THE ENTIRE RISK OF
SATISFACTORY QUALITY AND PERFORMANCE RESIDES WITH YOU. ELECTRONIC ARTS
DISCLAIMS ANY AND ALL EXPRESS, IMPLIED OR STATUTORY WARRANTIES,
INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY, SATISFACTORY QUALITY,
FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT OF THIRD PARTY
RIGHTS, AND WARRANTIES (IF ANY) ARISING FROM A COURSE OF DEALING,
USAGE, OR TRADE PRACTICE. ELECTRONIC ARTS DOES NOT WARRANT AGAINST
INTERFERENCE WITH YOUR ENJOYMENT OF THE PROGRAM; THAT THE PROGRAM WILL
MEET YOUR REQUIREMENTS; THAT OPERATION OF THE PROGRAM WILL BE
UNINTERRUPTED OR ERROR-FREE, OR THAT THE PROGRAM WILL BE COMPATIBLE
WITH THIRD PARTY SOFTWARE OR THAT ANY ERRORS IN THE PROGRAM WILL BE
CORRECTED. NO ORAL OR WRITTEN ADVICE PROVIDED BY ELECTRONIC ARTS OR
ANY AUTHORIZED REPRESENTATIVE SHALL CREATE A WARRANTY. SOME
JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF OR LIMITATIONS ON IMPLIED
WARRANTIES OR THE LIMITATIONS ON THE APPLICABLE STATUTORY RIGHTS OF A
CONSUMER, SO SOME OR ALL OF THE ABOVE EXCLUSIONS AND LIMITATIONS MAY
NOT APPLY TO YOU.

96
notes/SIMULATOR.txt Normal file
View file

@ -0,0 +1,96 @@
Micropolis City Simulation Algorithm Description.
SimFrame
If SimSpeed is 0, then return.
Increment Spdcycle mod 1024.
If SimSpeed is 1, then return every 4 out of 5 frames.
If SimSpeed is 2, then return every 2 out of 3 frames.
Increment Fcycle mod 1024.
Call Simulate, passing the phase parameter of (Fcycle mod 16).
Simulate
Passed the phase parameter, which switches through 16 phases (0 to 15).
Phase 0:
Increment Scycle and wrap mod 1024.
If DoInitialEval:
Clear DoInitialEval.
Call CityEvaluation.
Increment CityTime.
Increase AvCityTax by CityTax.
If Scycle is even:
Call SetValves.
Call ClearCensus.
Phase 1:
Call MapScan on 1st 8th of map.
Phase 2:
Call MapScan on 2nd 8th of map.
Phase 3:
Call MapScan on 3rd 8th of map.
Phase 4:
Call MapScan on 4th 8th of map.
Phase 5:
Call MapScan on 5th 8th of map.
Phase 6:
Call MapScan on 6st 8th of map.
Phase 7:
Call MapScan on 7st 8th of map.
Phase 8:
Call MapScan on 8st 8th of map.
Phase 9:
If CityTime mod CENSUSRATE is 0:
Call TakeCensus.
If CityTime mod (CENSUSRATE * 12) is 0:
Call Cake2Census.
If CityTime mod TAXFREQ is 0:
Call CollectTax.
Call CityEvaluation.
Phase 10:
If Scycle mod 5 is 0:
Call DecROGMem.
Call DecTrafficMem.
Set NewMapFlags for TDMAP, RDMAP, ALMAP, REMA, COMAP, INMAP, DYMAP.
Call SendMessages.
Phase 11:
If Scycle mod SpdPwr[SimSpeed] is 0:
Call DoPowerScan.
Set NewMapFlags for PRMAP.
Set NewPower.
Phase 12:
If Scycle mod SpdPtl[SimSpeed] is 0:
Call PTLScan. (Pollution, Terrain, Land Value.)
Phase 13:
If Scycle mod SpdCri[SimSpeed] is 0:
Call CrimeScan.
Phase 14:
If Scycle mod SpdPop[SimSpeed] is 0:
Call PopDenScan.
Phase 15:
If Scycle mod SpdFir[SimSpeed] is 0:
Call FireAnalysis.
Call DoDisasters.

62
notes/SharedData.txt Normal file
View file

@ -0,0 +1,62 @@
* Notes:
do tile animation in parallel - tileSynch
maps on demand
* Initialize at start of game:
short mickStartingYear;
extern char *cityName;
extern char *CityFileName;
extern short GameLevel;
* Share data:
** global
long CityTime;
short *Map[WORLD_X];
** editor window
short Oframe[OBJN];
short GlobalX[OBJN];
short GlobalY[OBJN];
long totalFunds;
short RValve, CValve, IValve;
** map window
short *PowerMap;
Byte *PopDensity[HWLDX]; /* 2X2 Maps 60 x 50 */
Byte *TrfDensity[HWLDX];
Byte *PollutionMem[HWLDX];
Byte *LandValueMem[HWLDX];
Byte *CrimeMem[HWLDX];
short RateOGMem[SmX][SmY];
short PoliceMapEffect[SmX][SmY];
short FireRate[SmX][SmY];
** graph window
short ResHisMax, Res2HisMax;
short ComHisMax, Com2HisMax;
short IndHisMax, Ind2HisMax;
short *ResHis;
short *ComHis;
short *IndHis;
short *MoneyHis;
short *PollutionHis;
short *CrimeHis;
short *MiscHis;
short Graph10Max, Graph120Max;
short Res2HisMax, Com2HisMax, Ind2HisMax;
** evaluation window
** budget window
short CityTax;
long RoadSpend, PoliceSpend, FireSpend;
long RoadFund, PoliceFund, FireFund;
float roadPercent, policePercent, firePercent;
long roadMaxValue, policeMaxValue, fireMaxValue;
long TaxFund, RoadFund, PoliceFund, FireFund;
* Messages
censusChanged
message(msg, x, y)
earthquake
newMap
formalize all global variable setter functions, to go through tcl

68
notes/TODO.txt Normal file
View file

@ -0,0 +1,68 @@
Work to be done on MicropolisCore:
========================================================================
TODO
========================================================================
Replace explicit world bounds checking with a macro.
Implement sound support.
Implement zooming in laszlo interface.
Implement overlays in laszlo interface.
Need a way to blink the unpowered tiles in laszlo interface.
Integrate map view and editor view with seamless zooming.
Make sure the explosion decays into a static dirt tile and animates properly in the client.
Remove all i18n related code from the simulator, and do it properly in the user interface instead.
Web update client pushes any changes to the sessions looking at the game.
Smart about what needs to be sent, because it tracks what it knows the client has, and sends deltas or nothing if no change.
How do we make this robust against missed updates?
Easy, stupid: If we detect an out of sequence update, just flush all caches and re-send everything.
(Re-sync when connection is lost.)
Hard, smart: Send a simulator timestamp back and forth, so we know how long in the past to update from.
(Re-invent TCP/IP).
Try easy and stupid for now.
========================================================================
DOING
========================================================================
Rework the build system.
Old fashioned crude makefiles need to be brought up to date.
Currently using python setup.py to compile to Python extensions.
Is setup.py the thing to be using to compile SWIG python extensions?
Is using setup.py a good idea or not? What are the alternatives? (Ian Bicking would know.)
To use gnu configure or not?
I can't stand it, but I realize there are reasons to use it.
What about compiling extensions for other languages.
The code and makefiles need to be able to compile any number of wrapers for different extension langauges.
The "make clean" command should not delete the swig generated files, and we should check in and distribute the swig generated wrappers.
Different people have different versions of SWIG, or might not have it at all.
Once things stabilize, most developers won't have to change the swig bindings very often.
Have a "make cleanswig" command to clean out the SWIG output files, so you can regenerate everything from scratch.
Not checking in swig generated files any more.
make clean deletes all swig generated files.
Implement overall map view and overlays.
========================================================================
DONE
========================================================================
Refactor the tool code. Move out of game. Make stateless tool API. All state in client.
Implement sprites in gtk interface.
Clean up and rationalize callbacks.
Make a generic update notification system.
Don't try formatting, converting and passing parameters, if they can be read from the simulator.
Update clients read the data out of the simulator that they need.
Format date, money, translate strings, etc, themselves.

305
notes/Tiles.txt Normal file
View file

@ -0,0 +1,305 @@
Analysis of MicropolisCore/images/tiles.xpm
===========================================
Image is 16 pixels wide, and 960*16 pixels high. Each 16x16 unit is one tile.
Tile N is copied at (0, N*16)--(16, N*16 + 16) exclusive from the tiles.xpm
image. Values N are shown below in hexadecimal notation, with an 'x' in front.
Decimal values are always 3 digits long (they are prefixed with leading 0's if
needed). The decimal values are derived from the hexadecimal values. In case
of conflict, the hexadecimal values should be trusted.
Below, tiles are roughly grouped together.
000: x000 x001: Dirt
002: x002 x003: Water
Coast:
004: x004: Water (copy of x002??)
x005 x006: Coast N
x007 x008: Coast NE
x009 x00a: Coast E
x00b x00c: Coast SE
x00d x00e: Coast S
x00f x010: Coast SW
x011 x012: Coast W
x013 x014: Coast NW
021: x015: Trees (dirt N)
x016: Trees (dirt NE)
x017: Trees (dirt E)
x018: Trees (dirt SE)
x019: Trees (dirt S)
x01a: Trees (dirt SW)
x01b: Trees (dirt W)
x01c: Trees (dirt NW)
x01d: Trees (dirt N)
x01e: Trees (dirt NE)
x01f: Trees (dirt E)
x020: Trees (dirt SE)
x021: Trees (dirt S)
x022: Trees (dirt SW)
x023: Trees (dirt W)
x024: Trees (dirt NW)
x025: Trees (no dirt)
038: x026 x027: ???
040: x028 x029 x02a x02b: Trees (with bit of dirt in the middle)
044: x02c x02d x02e x02f: Rubble (dirt with black dots)
048: x030 x031 x032 x033: Water (with white dots, ocean??)
052: x034 x035 x036 x037: Nuclear explosion?
(x034 is sort-of radio-active tile,
others are black and white dots, 0x026 also looks to belong here)
056: x038 x039 x03a x03b x03c x03d x03e x03f: Fire animation
064: x040: Horizontal (fixed or closed) road bridge
065: x041: Vertical (fixed or closed) road bridge
Road on dirt:
066: x042: Road WE
x043: Road NS
x044: Road NE
x045: Road SE
x046: Road SW
x047: Road NW
x048: Road crossing NWE
x049: Road crossing NSE
x04a: Road crossing SWE
x04b: Road crossing NSW
x04c: Road crossing NSWE
x04d: Road WE, power NS
x04e: Road NS, power WE
x04f: Water
Tiles x050-x05f
x060-x06f
x070-x07f
x080-x08f
each set of 16 as 0x040-x04f, but with light traffic animation
080: x050 x051 x052 x053 x054 x055 x056 x057
x058 x059 x05a x05b x05c x05d x05e x05f
096: x060 x061 x062 x063 x064 x065 x066 x067
x068 x069 x06a x06b x06c x06d x06e x06f
112: x070 x071 x072 x073 x074 x075 x076 x077
x078 x079 x07a x07b x07c x07d x07e x07f
128: x080 x081 x082 x083 x084 x085 x086 x087
x088 x089 x08a x08b x08c x08d x08e x08f
Tiles x090-x09f
x0a0-x0af
x0b0-x0bf
x0c0-x0cf
each set of 16 as 0x40-0x4f, buth with heavy traffic animation
144: x090 x091 x092 x093 x094 x095 x096 x097
x098 x099 x09a x09b x09c x09d x09e x09f
160: x0a0 x0a1 x0a2 x0a3 x0a4 x0a5 x0a6 x0a7
x0a8 x0a9 x0aa x0ab x0ac x0ad x0ae x0af
176: x0b0 x0b1 x0b2 x0b3 x0b4 x0b5 x0b6 x0b7
x0b8 x0b9 x0ba x0bb x0bc x0bd x0be x0bf
192: x0c0 x0c1 x0c2 x0c3 x0c4 x0c5 x0c6 x0c7
x0c8 x0c9 x0ca x0cb x0cc x0cd x0ce x0cf
208: x0d0: Power NS under water
x0d1: Power WE under water
x0d2: Power WE over dirt
x0d3: Power NS over dirt
x0d4: Power NE over dirt
x0d5: Power SE over dirt
x0d6: Power SW over dirt
x0d7: Power NW over dirt
x0d8: Power NWE over dirt
x0d9: Power NSE over dirt
x0da: Power SWE over dirt
x0db: Power NSW over dirt
x0dc: Power NSWE over dirt
x0dd: Rail WE, power NS over dirt
x0de: Rail NS, power WE over dirt
x0df: ?? (blank tile)
224: x0e0: Rail WE under water
x0e1: Rail NS under water
x0e2: Rail WE over dirt
x0e3: Rail NS over dirt
x0e4: Rail NE over dirt
x0e5: Rail SE over dirt
x0e6: Rail SW over dirt
x0e7: Rail NW over dirt
x0e8: Rail NWE over dirt
x0e9: Rail NSE over dirt
x0ea: Rail SWE over dirt
x0eb: Rail NSW over dirt
x0ec: Rail NSWE over dirt
x0ed: Rail WE, road NS, over dirt
x0ee: Rail NS, road WE, over dirt
x0ef: ?? (vertical road, horizontal power lines?)
Residential (3x3):
240: x0f0 x0f1 x0f2 x0f3 x0f4 x0f5 x0f6 x0f7 x0f8: Empty residential
Single tile houses (from small to big)
249: x0f9 x0fa x0fb x0fc x0fd x0fe x0ff x100 x101 x102 x103 x104
// 'population' means number of people in the residential zone.
// 'value' means land value - pollution. Higher is better.
Residential:
261: x105 x106 x107 x108 x109 x10a x10b x10c x10d // population 16, value 0
270: x10e x10f x110 x111 x112 x113 x114 x115 x116 // population 24, value 0
279: x117 x118 x119 x11a x11b x11c x11d x11e x11f // population 32, value 0
288: x120 x121 x122 x123 x124 x125 x126 x127 x128 // population 40, value 0
297: x129 x12a x12b x12c x12d x12e x12f x130 x131 // population 16, value 1
306: x132 x133 x134 x135 x136 x137 x138 x139 x13a // population 24, value 1
315: x13b x13c x13d x13e x13f x140 x141 x142 x143 // population 32, value 1
324: x144 x145 x146 x147 x148 x149 x14a x14b x14c // population 40, value 1
333: x14d x14e x14f x150 x151 x152 x153 x154 x155 // population 16, value 2
342: x156 x157 x158 x159 x15a x15b x15c x15d x15e // population 24, value 2
351: x15f x160 x161 x162 x163 x164 x165 x166 x167 // population 32, value 2
360: x168 x169 x16a x16b x16c x16d x16e x16f x170 // population 40, value 2
369: x171 x172 x173 x174 x175 x176 x177 x178 x179 // population 16, value 3
378: x17a x17b x17c x17d x17e x17f x180 x181 x182 // population 24, value 3
387: x183 x184 x185 x186 x187 x188 x189 x18a x18b // population 32, value 3
396: x18c x18d x18e x18f x190 x191 x192 x193 x194 // population 40, value 3
405: x195 x196 x197 x198 x199 x19a x19b x19c x19d: Hospital
414: x19e x19f x1a0 x1a1 x1a2 x1a3 x1a4 x1a5 x1a6: Church
Commercial buildings:
423: x1a7 x1a8 x1a9 x1aa x1ab x1ac x1ad x1ae x1af: Empty
432: x1b0 x1b1 x1b2 x1b3 x1b4 x1b5 x1b6 x1b7 x1b8
441: x1b9 x1ba x1bb x1bc x1bd x1be x1bf x1c0 x1c1
450: x1c2 x1c3 x1c4 x1c5 x1c6 x1c7 x1c8 x1c9 x1ca
459: x1cb x1cc x1cd x1ce x1cf x1d0 x1d1 x1d2 x1d3
468: x1d4 x1d5 x1d6 x1d7 x1d8 x1d9 x1da x1db x1dc
477: x1dd x1de x1df x1e0 x1e1 x1e2 x1e3 x1e4 x1e5
486: x1e6 x1e7 x1e8 x1e9 x1ea x1eb x1ec x1ed x1ee
495: x1ef x1f0 x1f1 x1f2 x1f3 x1f4 x1f5 x1f6 x1f7
504: x1f8 x1f9 x1fa x1fb x1fc x1fd x1fe x1ff x200
513: x201 x202 x203 x204 x205 x206 x207 x208 x209
522: x20a x20b x20c x20d x20e x20f x210 x211 x212
531: x213 x214 x215 x216 x217 x218 x219 x21a x21b
540: x21c x21d x21e x21f x220 x221 x222 x223 x224
549: x225 x226 x227 x228 x229 x22a x22b x22c x22d
558: x22e x22f x230 x231 x232 x233 x234 x235 x236
567: x237 x238 x239 x23a x23b x23c x23d x23e x23f
576: x240 x241 x242 x243 x244 x245 x246 x247 x248
585: x249 x24a x24b x24c x24d x24e x24f x250 x251
594: x252 x253 x254 x255 x256 x257 x258 x259 x25a
603: x25b x25c x25d x25e x25f x260 x261 x262 x263
Industrial buildings:
612: x264 x265 x266 x267 x268 x269 x26a x26b x26c: Empty
621: x26d x26e x26f x270 x271 x272 x273 x274 x275 // population ?*0, value 0
630: x276 x277 x278 x279 x27a x27b x27c x27d x27e // population ?*1, value 0
639: x27f x280 x281 x282 x283 x284 x285 x286 x287 // population ?*2, value 0
648: x288 x289 x28a x28b x28c x28d x28e x28f x290 // population ?*3, value 0
657: x291 x292 x293 x294 x295 x296 x297 x298 x299 // population ?*0, value 1
666: x29a x29b x29c x29d x29e x29f x2a0 x2a1 x2a2 // population ?*1, value 1
675: x2a3 x2a4 x2a5 x2a6 x2a7 x2a8 x2a9 x2aa x2ab // population ?*2, value 1
684: x2ac x2ad x2ae x2af x2b0 x2b1 x2b2 x2b3 x2b4 // population ?*3, value 1
Port (4x4):
693: x2b5 x2b6 x2b7 x2b8
x2b9 x2ba x2bb x2bc
x2bd x2be x2bf x2c0
x2c1 x2c2 x2c3 x2c4
Airport (6x6):
709: x2c5 x2c6 x2c7 x2c8 x2c9 x2ca
x2cb x2cc x2cd x2ce x2cf x2d0
x2d1 x2d2 x2d3 x2d4 x2d5 x2d6
x2d7 x2d8 x2d9 x2da x2db x2dc
x2dd x2de x2df x2e0 x2e1 x2e2
x2e3 x2e4 x2e5 x2e6 x2e7 x2e8
Coal power plant (4x4):
745: x2e9 x2ea x2eb x2ec
x2ed x2ee x2ef x2f0
x2f1 x2f2 x2f3 x2f4
x2f5 x2f6 x2f7 x2f8
761: x2f9 x2fa x2fb x2fc x2fd x2fe x2ff x300 x301: Fire station
770: x302 x303 x304 x305 x306 x307 x308 x309 x30a: Police station
Empty stadium (4x4):
779: x30b x30c x30d x30e
x30f x310 x311 x312
x313 x314 x315 x316
x317 x318 x319 x31a
Filled stadium (4x4):
795: x31b x31c x31d x31e
x31f x320 x321 x322
x323 x324 x325 x326
x327 x328 x329 x32a
Nuclear power plant (4x4):
811: x32b x32c x32d x32e
x32f x330 x331 x332
x333 x334 x335 x336
x337 x338 x339 x33a
827: x33b Lack of power (flashlight with red cross through it)
828: x33c x33d Left open bridge
830: x33e x33f Right open bridge
Animations:
832: x340 x341 x342 x343 x344 x345 x346 x347: Rotating radar (at top)
840: x348 x349 x34a x34b: Fountain
844: x34c x34d x34e x34f x350 x351 x352 x353: Rotating radar (elsewhere)
//SMOKEBASE
852: x354 x355 x356 x357 x358 x359 x35a x35b: Smoking chimneys (0,0)
860: x35c x35d x35e x35f x360 x361 x362 x363: Explosion
??? x364 x365 x366 x367: ?? (Black and white animation)
??? x368 x369 x36a x36b x36c x36d x36e x36f
x370 x371 x372 x373: ?? (Black and white animation)
884: x374 x375 x376 x377: Animation industry IND2 (top right)
888: x378 x379 x37a x37b: Animation industry IND3 (right)
892: x37c x37d x37e x37f: Animation industry IND4 (middle)
896: x380 x381 x382 x383: Animation industry IND5 (right middle)
900: x384 x385 x386 x387: Animation industry IND6 (top)
904: x388 x389 x38a x38b: Animation industry IND7 (top right)
908: x38c x38d x38e x38f: Animation industry IND8 (top right)
912: x390 x391 x392 x393: Animation industry IND9 (right)
916: x394 x395 x396 x397: Animation coal powerplant (top)
920: x398 x399 x39a x39b: Animation coal powerplant (top right)
924: x39c x39d x39e x39f: Animation coal powerplant (middle)
928: x3a0 x3a1 x3a2 x3a3: Animation coal powerplant (right)
932: x3a4 x3a5 x3a6 x3a7 x3a8 x3a9 x3aa x3ab: Match in stadium (top part)
940: x3ac x3ad x3ae x3af x3b0 x3b1 x3b2 x3b3: Match in stadium (bottom part)
948: x3b4 x3b5: North open bridge
950: x3b6 x3b7: South open bridge
952: x3b8 x3b9 x3ba x3bb: Nuclear atom animation at nuclear power plant
Duplicate tiles:
================
A simple file compare revealed the following duplicates:
x002 x004 x04f x05f x06f x07f x08f x09f x0af x0bf x0cf
x02d x363
x321 x3a6
x325 x3b1 x3b2
x334 x3b8
x368 x372
x369 x371
x36a x370
x3bc x3bd x3be x3bf

262
notes/UserInterfacePlan.txt Normal file
View file

@ -0,0 +1,262 @@
Micropolis Core Engine
By Will Wright and Don Hopkins
[TODO: Write documentation here.]
Here are some notes about hooking up a user interface.
In general, the philosophy is to tell the scriptinging engine that something has changed by sending a callback message out, without any parameters.
(The code may not currently be doing that, but that's how it should work.)
Then the script handler can pull the parameters out of the simulator itself, instead of being passed the parameters in the callback.
This is so that the script can delay updating until the next time it paints the screen, consolidating a bunch of changes into one refresh.
That avoides the overhead of converting and formatting values that don't end up getting used.
Also, we want to defer all formatting to the scripting language, instead of formatting in the core simulator, so the script can internationalize the numbers and text.
Likewise, the simulator should not have any strings hard wired into it -- all those should be looked up by the scripting language, in translation files.
To conserve power on the OLPC, the script might want to schedule an update at the next round timer tick, so all the updates happen at once.
There are a bunch of flags for things like the evaluation changing, the graph changing, etc.
These should be replaced by incrementing revision numbers, so the views can skip updates,
and only update if the version number has changed.
Parts of the simulator that update the user interface:
Budget
SetBudget
flowStr
previousStr
currentStr
collectedStr
tax
SetBudgetValues
roadGot
roadWant
policeGot
policeWant
fireGot
fireWant
ShowBudgetWindowAndStartWaiting
Evaluation
SetEvaluation
changed: deltaCityScore
score: CityScore
ps0: ProblemOrder[0] ? probStr[ProblemOrder[0]] : ""
ps1: ProblemOrder[1] ? probStr[ProblemOrder[1]] : ""
ps2: ProblemOrder[2] ? probStr[ProblemOrder[2]] : ""
ps3: ProblemOrder[3] ? probStr[ProblemOrder[3]] : ""
pv0: ProblemOrder[0] ? ProblemVotes[ProblemOrder[0]] : ""
pv1: ProblemOrder[1] ? ProblemVotes[ProblemOrder[1]] : ""
pv2: ProblemOrder[2] ? ProblemVotes[ProblemOrder[2]] : ""
pv3: ProblemOrder[3] ? ProblemVotes[ProblemOrder[3]] : ""
pop: CityPop
delta: deltaCityPop
assessed_dollars: CityAssValue
cityclass: cityClassStr[CityClass]
citylevel: cityLevelStr[GameLevel]
goodyes: XXX%
goodno: XXX%
title: City Evaluation [YEAR]
probStr
Crime
Pollution
Housing Costs
Taxes
Traffic
Unemployment
Fires
cityClassStr
Village
Town
City
Capital
Metropolis
Megalopolis
cityLevelStr
Easy
Medium
Hard
====
User interface surfaces to implement:
New city dialog (full screen or shared with main city view)
View of selected city (or use main city view if still on screen)
City Name Editor
Difficulty Level Selector
Easy
Medium
Hard
Generate New City Button
Load City Button
8 Scenarios Buttons
Dullsville 1900
San Francisco 1906
Hamburg 1944
Bern 1965
Tokyo 1957
Rio de Janeiro 2047
Boston 2010
Detroit 1972
About button
Quit button
Control Menus (visible while game playing, or disabled as appropriate)
Micropolis
About
Save City
Save city as...
New city...
Quit
Options
Auto Budget
Auto Bulldoze
Disasters
Sound
Animation
Messages
Notices
Disasters
Monster
Fire
Flood
Meltdown
Air Crash
Tornado
Earthquake
Speed
Extra Slow
Slow
Medium
Fast
Extra Fast
Window
Budget
Evaluation
Graph
New Editor
New Map
Date Display
Click to pause
Drag to change speed
Funds Display
Click to open budget window and pause
Tax Rate Display
Click to open budget window and pause
Tax Rate Slider
Drag to set tax rate without pausing
Demand Gauge (called "valves" in code)
Shows Residential, Commercial and Industrial demand
Click to toggle evaluation window or graph window
Message Field
Displays the current message.
Click to go to the location of that message.
Scrolling Text Journal
Scrolling text window of messages.
Click messages to do something useful like scroll to location of event.
Messages can reconfigure the user interface to help deal with the problem described.
Click dates to rewind to save checkpoints
Budget Window
Road Fund Requested Label
Road Fund Percentage Slider
Fire Fund Requested Label
Fire Fund Percentage Slider
Police Fund Requested Label
Police Fund Percentage Slider
Tax Rate Label
Tax Rate Slider
Taxes Collected Label
Cash Flow Label
Previous Funds Label
Current Funds Label
Continue Button
Reset Button
Cancel Button
Toggle Auto Budget Button
Evaluation Window
Is The Mayor Doing a Good Job?
Yes: XX%
No: XX%
What are the Worst Problems?
Problem 1: XXX%
Problem 2: XXX%
Problem 3: XXX%
Problem 4: XXX%
Statistics
Population: XXX
Net Migration: XXX (last year)
Assessed Value: XXX
Category: XXX
Game Level: XXX
Overall City Score (0 - 1000)
Current Score: XXX
Annual Change: XXX
Dismiss
Graph window
Long term graph
Short term graph
Each graph has 8 values it can overlay
Legend showing 8 labels for 8 colors
Labels
Residential: Light Green = (0.50, 0.50, 1.00)
Commercial: Dark Blue = (0.00, 0.00, 0.50)
Industrial: Yellow = (1.00, 1.00, 0.00)
Cash Flow: Dark Green = (0.00, 0.50, 0.00)
Crime: Red = (1.00, 0.00, 0.00)
Pollution: Olive = (0.33, 0.42, 0.18)
Click to toggle each graph
Point to highlight individual graphs, and show scale and value
Advanced scaling, scrolling and data mining features
Dismiss
Edit Window
Selected Tool
Cost of Selected Tool
Tool Palette
Options
Auto Goto
Hide Panel
Show Overlay (for layers and chalk)
Dynamic Filter (for dynamic zone finder: "frob-o-matic")
Map Window
Shows draggable location(s) of edit window(s)
Overlays
Residential
Commercial
Industrial
Transportation
Population Density
Rate of Growth
Land Value
Crime Rate
Pollution Density
Traffic Density
Power Grid
Fire Coverage
Police Coverage
Dynamic ("frob-o-matic")
Dismiss
Notice Window
Shows messages and pictures.
Can display a live animated view of a location on the map, zoomed into wherever the message is about.
Can also be used to ask questions, like "Are you sure you want to XXX?" with yes/no/etc buttons.
Dismiss
Help Window
A xulrunner web browser to read HTML docs.

475
notes/outline.txt Normal file
View file

@ -0,0 +1,475 @@
BUGS:
* multi-user "select city" dialog
** Add about, configure buttons
** draw and erase on map window
* configuration panel
** players
** keys
* sim.
** command to set process nice
** first editor on a display gets a control window
* control window.
** file menu.
*** About (dialog)
*** LoadScenario (confirm)
*** StartNewCity (confirm)
*** LoadCity (file dialog)
*** SaveCity (file dialog if no file name)
*** SaveCityAs (file dialog)
*** PrintCity (print dialog)
*** GetKey (key dialog)
*** QuitMicropolis (confirm)
** options menu
*** auto budget, auto goto, auto bulldoze, disasters, sound
** disasters menu
*** monster, fire, flood, air crash, tornado, earthquake, meltdown
** window menu
defer creating windows
* more controls
** command field
*** type in arguments to menu commands
*** interpret tcl
** icon for each window opened and openable (dim)
*** window name, display name, user name
*** click opened icon to bring to top
*** click openable icon to make new window
*** make nice icons
*** display nice icons in x window icons too
*** save window layout
*** restore window layout
** speed slider
** priority slider
* editor window.
** editor view.
** tool pallet.
** various text fields.
*** funds, date, message, cost.
** initialize controls
** autogoto is a per-editor flag
** autogoto toggle
** coal/nuclear toggle
** update frequency slider
** cursor tool outline (preview?)
** pie menus
** earthquake
** demand gauge
** auto scroll
** constrained drag
** arrow keys pan
** fix autorepeat problem
* map window.
** set window title
** initialize pallet and menus
** legend tied to map state
** menu buttons that appear when needed
*** zone type
*** population type
*** service type
** disable manipulation of other peoples maps (unless you're god)
** click on a rectangle to bring that editor to the top
** create a new editor by clicking on the small map
** open new display by typing in a display name and creating a new editor
** update frequency slider
* budget window.
** set window title
** hour glass
** auto budget behavior
do we or don't we pause the simulator?
do we or don't we bring up other peoples budget window?
when AutoBudget, simulator continues, and just your window opens.
when not AutoBudget, simulator pauses, so everyones window opens,
hour glasses starts
how about we just don't pause, and everyone controls their own window.
* graph window
** set window title
** graph object
*** GraphRange ?10|120?
*** GraphType 0..5 ?0..1?
*** set window title
* dialogs
** start scenario.
*** 6 scenario buttons, labeled.
*** new city.
*** load city.
*** get key
*** dynamic scenario description
** generate city
*** label "creating new map"
*** city name text field
*** city level buttons with labels
*** map view
*** generate new terrain
*** use this map
*** load city
*** play scenario
*** get key
** load
*** file dialog
** save
*** file dialog
** print
*** mono / color
*** small map / large map
*** printer command text field
*** print button
** key
*** Instructions, Address, Phone Number (labels)
*** License Type: Node/Network (exclusive settings)
*** License Code: (field)
*** Enter Key: (text field)
*** Install Key (button)
** zone status
*** zone type label
*** Density, Value, Crime, Pollution, Growth (fields)
** notice
*** city size
**** city size label, description message
**** town, city, capital, metropolis, megalopolis, winner
*** warning messages
**** warning name, description message
**** pollution, crime, traffic, monster, meltdown, riots, demo, impeachment
** about
*** text, pictures, noises
** confirm
*** message, yes button, no button
** error
*** message
*** ok
* evaluation window.
* help
* printing
* sound
* new elm interface
* tk
** masked pixmap object for canvases (or a regular componant)
** pie menus
* stacks
** Audio
implement audio interface
** Micropolis
About box
*** messages
/StartGame { % HomeDir ResourceDir StackDir KeyDir => -
/ReallyStartGame { % - => -
/NewGame { % - => -
/StartLoad { % - => -
/StartScenario { % name|number => -
/DoStartNewCity { % - => -
/DoPlayNewCity { % - => -
/DoLoseGame { % - => -
/DoLoadScenario { % - => -
/DidLoadScenario { % - => -
/DoLoadCity { % - => -
/HeyLoadCity { % name => -
/CancelLoadCity { % - => -
/DidLoadCity { % - => -
/DidntLoadCity { % error => -
/DoSaveCity { % - => -
/DoSaveCityAs { % - => -
/HeySaveCityAs { % name => -
/DidSaveCity { % - => -
/DidntSaveCity { % error => -
/DoGetKey { % - => -
/DoQuitMicropolis { % - => -
/InitializeSound { % - => -
/ShutDownSound { % - => -
/SetUserSound { % bool => -
/MakeSound { % n => -
/StartSound { % n => -
/StopSound { % n => -
/SoundOff { % - => -
/UckfayEthayOlicepay { % - => -
/PrintLargeMap { % - => -
/PrintSmallMap { % - => -
/HyperDrawLargeMap { % - => -
/HyperDrawSmallMap { % - => -
/HyperDrawCityView { % - => -
/DoPrintCity { % - => -
/StartElmd { % - => -
** Budget
Tax Rate Percent: (slider 0% 20%)
/SetTaxRate
Taxes Collected: (field)
Amount Requested (column heading)
Amount Allocated (column heading)
Funding Level (column heading)
Fire Fund: (field) (numeric) (slider 0% 100%)
/SetFireFund
Police Fund: (field) (numeric) (slider 0% 100%)
/SetPoliceFund
Trans. Fund: (field) (numeric) (slider 0% 100%)
/SetTransFund
Cash Flow: (field)
Previous Funds: (field)
Current Funds: (field)
Hour Glass (inactivity timer)
goes for 20 seconds then takes down budget window and continues
Go With These Figures (button)
/GoWithTheseFigures /ResumeSim /Hide
*** messages
/SetBudget { % [($flow) ($previous) () ($current)] ($collected) tax => -
/SetMaxFunds { % [($road)] [road] [($police)] [police] [($fire)] [fire] => -
/StartWaiting { % - => -
shows hour glass
** Editor
File (menu)
{ NIL /DoLoadScenario /Micropolis Send }
{ NIL /DoStartNewCity /Micropolis Send }
{ NIL /DoLoadCity /Micropolis Send }
{ NIL /DoSaveCity /Micropolis Send }
{ NIL /DoSaveCityAs /Micropolis Send }
{ NIL /DoPrintCity /Micropolis Send }
{ NIL /DoGetKey /Micropolis Send }
{ NIL /DoQuitMicropolis /Micropolis Send }
Options (menu)
[exch] /SetOptions ClientSend
Disasters (menu)
{ NIL /MakeMonster ClientSend }
{ NIL /MakeFire ClientSend }
{ NIL /MakeFlood ClientSend }
{ NIL /MakeAirCrash ClientSend }
{ NIL /MakeTornado ClientSend }
{ NIL /MakeEarthquake ClientSend }
{ NIL /MakeMeltdown ClientSend }
Time (menu)
/Action {
[exch] /SetSpeed ClientSend
} def
Priority (menu)
/Action {
{ {1000 5} {500 4} {250 3} {120 2} {60 0} {25 0} {0 0}
} exch get cvx exec
[exch] /SetNice ClientSend
[exch] /SetDelay ClientSend
} def
Windows (menu)
{ NIL /UpdateBudget ClientSend }
{ NIL /UpdateEvaluation ClientSend
/MicropolisEvaluation ShowStack }
{ /MicropolisGraph ShowStack }
{ /MicropolisSurveyor ShowStack }
{ /MicropolisNotice ShowStack }
{ /MicropolisMap ShowStack }
{ /MicropolisEditor ShowStack }
Funds: (field)
Date: (field)
Message: (field)
Editing Icons (exclusive settings)
/InitGame
/DoSetWandState /SetPowerType
Demand: (gauge)
/SetDemand { % r c i => -
Zoom In/Out (rocker switch)
Zoom Reset (button)
Tool Cost: (field)
Editor View
Editing Icons (pie menu)
/DoSetWandState
Cursor outline showing where tool will operate
color codes for tools
query gray
bulldozer brown
road black white
wire black yellow
rail black brown
park brown green
residential green
commercial blue
industrial yellow
police brown blue
fire brown red
stadium gray green
coal gray yellow
seaport gray blue
airport gray white
nuclear gray yellow
monster orange
helicopter red
draw (colored pen)
Panning with arrow keys
Panning by dragging
Dynamic panning & bouncing
Earthquake
Mouse tool handling
Tools connect corners
Constrained drag
Auto scroll
*** messages
/InitGame { % - => -
/DoEarthQuake { % - => -
/DoSetWandState { % state => -
/JustSetWandState { % n => -
/SetMessage { % str => -
** Evaluation
Public Opinion (column header)
Is the mayor doing a good job? (field)
% yes, % no (fields)
What are the worst problems? (field)
% problem, ... (fields)
Statistics (column header)
Population, Net Migration, Assessed, Value, Category (fields)
Overall City Score (field)
current score (field)
anual change (field)
*** messages
/SetEvaluation { % [strings] => -
** Graph
Graph Plot
/InitGraph /GraphMe
/SetGraph { % [range year month res com ind money crime pollution] => -
10/120 Year (exclusive toggle)
/SetGraphRange
Residential, Commercial, Industrial, Money, Crime, Pollution (toggles)
*** messages
** Map
Scenerio Screen
Noisy Grill (toggle)
Duck (button)
Key (button)
New City, Load City (buttons)
6 scenarios (buttons)
scenario names (labels)
Map Background
Map View
Shows rectangles for editor views
Drag rectangles to scroll editor views
Terrain Generator
Generate New Terrain, Use This Map (buttons)
City Map
Map State Icons (exclusive settings)
Zone Type (menu)
Population Type (menu)
Service Type (menu)
/OnInit
/SetMapState /SetZoneType /SetPopNRate /SetPoliceRadius
Legend
Max/Min / +/- / none (picture)
*** messages
/InitGame { % - => -
** Notice
Welcome Notice
New City (dialog)
Creating New Map ... (label)
City Name: (text field)
Game Level: Easy/Medium/Hard (exclusive settings)
Are You Sure?
Yes, No (buttons)
Really Quit?
Save City, Really Quit, Never Mind (buttons)
Print City
Monochrome/Color (exclusive settings)
Edit Small Map, Edit Large Map, Edit City View (buttons)
Printer Command: (text field)
Print Small Map, Print Large Map, Show Printer Queue (buttons)
Install Key
Instructions, Address, Phone Number (labels)
License Type: Node/Network (exclusive settings)
License Code: (field)
Enter Key: (text field)
Install Key (button)
Earthquake Control
Richter Scale: (slider .1% 10%)
Earthquake (button)
Scenario Descriptions
Zone Status
Zone Type (field)
Density, Value, Crime, Pollution, Growth (fields)
Game Level Notices
Warnings
*** messages
/InitGame { % - => -
/ShowNotice { % card => -
/ShowPicture { % id => -
/ShowZoneStatus { % type [s0 s1 s2 s3 s4] => -
/AreYouSure? { % yesResponse => -
/Respond { % target thing|null => -
/Yes { % - => -
/No { % - => -
** Surveyor
Editor View(s)
Zoom In/Out (rocker switch)
Zoom Reset (button)
Single/Multiple View (toggle)
Click on surveyor view to center editor there
*** messages
/AutoGoto { % x y msg => -
/AutoGotoClick { % - => -
** Help
Help Text Display
Done (button)
Dullsville
Philip Glass, Powaqqatsi, That Place
San_Francisco
Grateful Dead, Fire on the Mountain
Philip Glass, Powaqqatsi, Serra Pelada
Hamburg
Yello, Oh Yeah
Bern
Yello, RubberBandMan
Philip Glass, Powaqqatsi, CAUGHT!
Tokyo
Percussions D'Asie
Philip Glass, Powaqqatsi, Serra Pelada
Detroit
Boston
Rio_de_Janeiro
Philip Glass, Powaqqatsi, From Egypt

12
notes/prompt-code-review-file.txt Normal file
View file

@ -0,0 +1,12 @@
For each file provided:
Write a concise summary that would be a good comment at the beginning of the file, explaining what it does.
The summary should be formatted as a C++ doxygen file comment.
Break lines at 72 characters. Example:
/**
* @file micropolis.h
* @brief Header file for Micropolis game engine.
*
* Bla bla bla...
*/
After the comment code section, write as normal text a concise review of the code, mentioning any possible problems, especially relating to emscripten.

18
notes/prompt-code-review-member.txt Normal file
View file

@ -0,0 +1,18 @@
For each function, variable, constant, method, class, or whatever:
If there is no doxygen comment, then create a new one concisely summarizing and (if a function) defining all the parameters and return values.
If there is an existing comment, then update it with a concise summary, but keep any useful information already in the comment, integrating it in with your own comments.
Keep any todos or bugs or other doxygen comments.
The summary should be formatted as a C++ doxygen comment.
Break lines at 72 characters.
Example:
/**
* Deduct \a dollars from the player funds.
* @param dollars Amount of money spent.
*/
void Micropolis::spend(int dollars)
{
setFunds(totalFunds - dollars);
}
Write the output as a compact diff patch that I can apply to the source code, which only includes insertions and deletions with minimal context.
This prompt will be followed by the entire file. Process the whole file chunk by chunk, as much as you can at a time.