micropolis

a T-Rex looking character, but... a few magazine reviews called the monster, Godzilla. That was all it took. Toho called it "confusion in the marketplace". We paid $50k for Godzilla to go away. In all honesty, Toho liked Maxis, they said $50k was the minimum they take for Godzilla infringement. All the box scans are in the Micropolis repo -- high res front, back with the "floods, earthquakes, fires, tornados, meltdowns and monsters" disaster list, side panels, and the platform variants, each with descriptions: https://github.com/SimHacker/MicropolisCore/blob/main/docume... Full email thread: https://github.com/SimHacker/MicropolisCore/blob/main/docume... The back of the box kept advertising monsters as a feature the same year the monster got lawyered off the front. The function names in the code all refered to it like "MakeMonster()", but admittedly there was a "GOD" symbol in the code used to index the Monster sprite likw "GetSprite(GOD)", but Toho could not have know that, since it was a C preprocessor macro that was compiled away in the binary: https://github.com/SimHacker/micropolis/blob/master/micropol...

-scr.txt My compatible CA compiler and glue to the simulator written in C: cam.f.txt: https://donhopkins.com/home/code/cam.f.txt compile.f.txt: https://donhopkins.com/home/code/compile.f.txt An old version of the simulator written C, before I rewrote it in JavaScript: https://github.com/SimHacker/micropolis/tree/master/Micropol... The JavaScript CAM6 simulator: CAM6.js: https://github.com/SimHacker/CAM6/blob/master/javascript/CAM...

dn't manage demand at larger scales, so the spatial reasoning problem discussed here has been hard for RL too, not just LLMs. He described the project and we discussed it on the Micropolis repo in this issue: https://github.com/SimHacker/micropolis/issues/86 He used the old PyGTK interface for his project: https://github.com/SimHacker/micropolis/tree/master/Micropol... These days I'd recommend the MicropolisCore repo instead. It's a C++ rewrite independent of any UI, compiles to WASM via Emscripten/Embind, and runs headless in Node or with any browser UI: https://github.com/SimHacker/MicropolisCore Live demo: https://micropolisweb.com One note on naming: the open source license from EA requires using "Micropolis" rather than "SimCity" (which is EA's trademark). The Micropolis Public Name License allows use of the original name: https://github.com/SimHacker/micropolis/blob/master/Micropol... This matters more than people think. Jeff Braun, CEO of Maxis, told me this story: "Maxis was sued by Toho. We never referred to the name Godzilla, our monster on the box cover was a T-Rex looking character, but... a few magazine reviews called the monster, Godzilla. That was all it took. Toho called it 'confusion in the marketplace'. We paid $50k for Godzilla to go away. In all honesty, Toho liked Maxis, they said $50k was the minimum they take for Godzilla infringement." So please: call the game Micropolis, not SimCity, or EA's lawyers may come knocking. And unlike Toho, EA and their Saudi investors and Jarod Kushner might want to use their bone saws on you, which are much worse than Godzilla.

city/SimCity-Indigo.gif SimCity on Sun OLWM: http://art.net/~hopkins/Don/simcity/SimCity-Sun.gif SimCity on NCD X Terminal: http://art.net/~hopkins/Don/simcity/SimCity-NCD.gif I visited Professor John Ousterhout at his office at UCB with an SGI Indigo to give him a demo and express my gratitude and admiration, and demonstrated it running across two SGIs at the ACM InterCHI '93 conference Interactive Experience to demonstrate the cooperative multi player aspects like multiple views, multiple cursors, collaborative editing, and voting. http://www.art.net/~hopkins/Don/simcity/simcitynet.html Eventually I talked EA into open sourcing SimCity, cleaned up the TCL version, and released it on the OLPC (and renamed it Micropolis to not infringe on Maxis/EA's trademark): Open Sourcing SimCity: https://donhopkins.medium.com/open-sourcing-simcity-58470a27... micropolis activity: https://github.com/SimHacker/micropolis/tree/master/micropol... micropolis.tcl: https://github.com/SimHacker/micropolis/blob/master/micropol...

ce version of SimCity, I scripted a "PacBot" agent in Python: a giant PacMan who follows the roads around, looking for traffic to eat, always turning in the direction of the most traffic. The PacBot only has a limited local view down the roads a few cells, and can't see around corners. Even though they're extremely simple and stupid and short-sighted, they still have interesting emergent behavior when multiple PacBots are competing for the same traffic, like how PacBot will give up and turn around when its competitors eat the cars it was wok-a-wok-a-ing towards. There is a good example of lots of competing PacBots around 0:55: https://www.youtube.com/watch?v=8snnqQSI0GE >Now you have some good, uuh, there's some traffic here. There's this thing called a PacBot. It's this PacMan that follows the road around looking for traffic. And then he eats it. So that's good for your city. And you can have a lot of different PacMans on the thing, and you know, just editing the road gives the PacMan somewhere to go. So their score is how many cars they've eaten. So it's an "agent", and it woks all around, and he follows roads. And you can put a lot of them on the map to keep the traffic low. MicropolisRobot.scanRoads looks down the road in a given direction for a given distance, and counts the number of cars (in the traffic density layer), attenuated by distance (further away cars don't count as much). https://github.com/SimHacker/micropolis/blob/b0c5a3f495ebabb... Then the PacBot simulator calls scanRoads in all possible different directions to get a score, and moves in the direction of the best score. https://github.com/SimHacker/micropolis/blob/b0c5a3f495ebabb... As it turns out, the PacBot is actually the God of the Church of PacMania (each Polytheistic PacMania Church spawns up to four PacBot God Agents, if it's connected to a road), and the church zone itself generates a LOT of traffic, in the hopes of attracting the PacBots. The emergent behavior is that followers of the Church of PacMania happily drive back and forth between church, home, work, and shopping, again and again, in the hopes of sacrificing themselves to their God, PacBot. And the PacBot Gods hang out around the Church of PacMania, eating their followers, and raising their scores -- everybody's happy! class MicropolisZone: def generateRobots(self): https://github.com/SimHacker/micropolis/blob/b0c5a3f495ebabb... class MicropolisZone_ChurchOfPacMania(MicropolisZone): https://github.com/SimHacker/micropolis/blob/b0c5a3f495ebabb...

ork with it, and once you make your peace with XML (which seemed like a prudent thing to do at the time), it's a really productive enjoyable way to program! But that's more thanks to the design of OpenLaszlo itself, rather than XML. https://en.wikipedia.org/wiki/OpenLaszlo OpenLaszlo (which was released in 2001) inspired Adobe Flex (which was released in 2004), but Flex missed the point of several of the most important aspects of OpenLaszlo (first and foremost being cross platform and not locking you into Flash, which was the entire point of Flex, but also the declarative constraints and "Instance First Development" and the "Instance Substitution Principal", as defined by Oliver Steele). https://en.wikipedia.org/wiki/Apache_Flex https://web.archive.org/web/20190318072102/https://blog.oste... The mantle of constraint based programming (but not Instance First Development) has been recently taken up by "Reactive Programming" craze (which is great, but would be better with a more homoiconic language that supported Instance First Development and the Instance Substitution Principle, which are different but complementary features with a lot of synergy). The term "Reactive Programming" describes a popular old idea: what spreadsheets had been doing for decades. OpenLaszlo and Garnet (a research user interface system written by Brad Myers at CMU in Common Lisp) were exploring applying automatic constraints to user interface programming. Garnet started in the early 1990's. Before that, Ivan Sutherland's Sketchpad explored constraints in 1963, and inspired the Visual Geometry Project in the mid 1980's and The Geometer's Sketchpad in 1995. https://en.wikipedia.org/wiki/Reactive_programming http://www.cs.cmu.edu/afs/cs/project/garnet/www/garnet-home.... https://en.wikipedia.org/wiki/Sketchpad http://math.coe.uga.edu/TME/Issues/v10n2/4scher.pdf https://en.wikipedia.org/wiki/The_Geometer%27s_Sketchpad I've written more about OpenLaszlo and Garnet: What is OpenLaszlo, and what's it good for? https://web.archive.org/web/20160312145555/http://donhopkins... >Declarative Programming: Declarative programming is an elegant way of writing code that describes what to do, instead of how to do it. OpenLaszlo supports declarative programming in many ways: using XML to declare JavaScript classes, create object instances, configure them with automatic constraints, and bind them to XML datasets. Declarative programming dovetails and synergizes with other important OpenLaszlo techniques including objects, prototypes, events, constraints, data binding and instance first development. Constraints and Prototypes in Garnet and Laszlo https://web.archive.org/web/20160405015129/http://www.donhop... >Garnet is an advanced user interface development environment written in Common Lisp, developed by Brad Meyers (the author of the article). I worked for Brad on the Garnet project at the CMU CS department back in 1992-3. More about TCL/Tk, OpenLaszlo, Garnet, constraint programming, history of constraints: Coco KVO, Objective Smalltalk constraints, Sutherland, Sketchpad, Geometers Sketchpad, Knowledge Representation frames, push vs pull constraints, etc: https://news.ycombinator.com/item?id=17360883

kipedia.org/wiki/Bufferbloat https://gettys.wordpress.com/2010/12/03/introducing-the-crim... I had a great time using it for the Micropolis (open source SimCity) tile rendering engine, which I wrote in C++, then wrapped with David Beazly's SWIG tool as a Python extension, so Python PyGTK apps could pass their existing Cairo rendering context into C++ and it could render at high speed without the Python interpreter in the way, on either windows or bitmaps. https://en.wikipedia.org/wiki/SWIG The TileEngine is a C++ python module wrapped with SWIG, that uses the Cairo library and knows how to accept a PyGTK Cairo context as a parameter to draw on directly via the api -- Python just passes pointers back and forth between PyGTK by wrangling and unwrangling wrappers around the Cairo context pointer: TileEngine: https://github.com/SimHacker/micropolis/tree/master/Micropol... tileengine.h: https://github.com/SimHacker/micropolis/blob/master/Micropol... tileengine.cpp: https://github.com/SimHacker/micropolis/blob/master/Micropol... pycairo.i: https://github.com/SimHacker/micropolis/blob/master/Micropol... tileengine-swig-python.i: https://github.com/SimHacker/micropolis/blob/master/Micropol... tileengine.i: https://github.com/SimHacker/micropolis/blob/master/Micropol... Then you can call the tile engine from Python, and build GTK widgets and apps on top of it like so, and it all runs silky smooth, with pixel perfect tiling and scaling, so you can zoom into the SimCity map, and Python can efficiently draw sprites and overlays on it like Godzilla, tornados, trains, airplanes, helicopters, the cursor, etc: tiledrawingarea.py: https://github.com/SimHacker/micropolis/blob/master/Micropol... tilewindow.py: https://github.com/SimHacker/micropolis/blob/master/Micropol... tiletool.py: https://github.com/SimHacker/micropolis/blob/master/Micropol... I've written about Cairo on HN before, sharing some email with Jim about it: https://news.ycombinator.com/item?id=20379336 DonHopkins on July 8, 2019 | parent | context | favorite | on: The death watch for the X Window System has probab... Cairo wasn't the library behind the X11 drawing API, it was originally the Xr rendering extension, that was an alternative to the original X11 drawing API. https://en.wikipedia.org/wiki/Cairo_(graphics) >The name Cairo derives from the original name Xr, interpreted as the Greek letters chi and rho. You're right, it doesn't actually make sense to put your drawing functions in the display server any more (at least in the case of X11, which doesn't have an extension language to drive the drawing functions -- but it did make sense for NeWS which also used PostScript as an extension language as well as a drawing API). So Cairo rose above X11 and became its own independent library, so it could be useful to clients and toolkits on any window system or hardware. https://www.osnews.com/story/3602/xr-x11-cross-device-render... https://web.archive.org/web/20030805030147/http://xr.xwin.or... https://keithp.com/~keithp/talks/xarch_ols2004/xarch-ols2004... Here's some email discussion with Jim Gettys about where Cairo came from: From: Jim Gettys <jg@laptop.org> Date: Jan 9, 2007, 11:04 PM The day I thought X was dead was the day I installed CDE on my Alpha. It was years later I realized the young turks were ignoring the disaster perpetrated by the UNIX vendors in the name of "standardization"; since then, Keith Packard and I have tried to pay for our design mistakes in X by things like the new font model, X Render extension, Composite, and Cairo, while putting stakes in the heart of disasters like XIE, LBX, PEX, the old X core font model, and similar design by committee mistakes (though the broken core 2D graphics and font stuff must be considered "original sin" committed by people who didn't know any better at the time). So we've mostly succeeded at dragging the old whale off the beach and getting it to live again. From: Don Hopkins <dhopkins@donhopkins.com> Date: Wed, Jan 17, 2007, 10:50 PM Cairo looks wonderful! I'm looking forward to using it from Python, which should be lots of fun. A lot of that old X11 stuff was thrown in by big companies to shill existing products (like using PEX to sell 3d graphics hardware, by drawing rotating 3-d cubes in an attempt to hypnotize people). Remember UIL? I heard that was written by the VMS trolls at DEC, who naturally designed it with an 132 column line length limitation and no pre-processor of course. The word on the street was that DEC threw down the gauntlet and insisted on UIL being included in the standard, even though the rest of the committee hated it for sucking so bad. But DEC threatened to hold their breath until they got their way. And there were a lot of weird dynamics around commercial extensions like Display PostScript, which (as I remember it) was used as an excuse for not fixing the font problems a lot earlier: "If you want to do readable text, then you should be using Display PostScript." The problem was that Linux doesn't have a vendor to pay the Display PostScript licensing fee to Adobe, so Linux drove a lot of "urban renewal" of problems that had been sidelined by the big blundering companies originally involved with X. >So we've mostly succeeded at dragging the old whale off the beach and getting it to live again. Hey, that's a lot better than dynamiting the whale, which seemed like a such good idea at the time! (Oh the humanity!) https://www.youtube.com/watch?v=AtVSzU20ZGk From: Jim Gettys <jg@laptop.org> Date: Jan 17, 2007, 11:41 PM > Cairo looks wonderful! I'm looking forward to using it from Python, which should be lots of fun. Yup. Cairo is really good stuff. This time we had the benefit of Lyle Ramshaw to get us unstuck. Would that I'd known Lyle in 1986; but it was too late 3 years later when I got to know him. https://cairographics.org/bibliography/ Here's some more of the discussion with Jim about Cairo and X-Windows: https://news.ycombinator.com/item?id=7727953 >In 2007, I apologized to Jim Gettys for the tone of the X-Windows Disaster chapter I wrote for the book, to make sure he had no hard feelings and forgave me for my vitriolic rants and cheap shots of criticism: http://www.donhopkins.com/home/catalog/unix-haters/x-windows... DH>> I hope you founds it more entertaining than offensive! JG> At the time, I remember it hurting; now I find it entertaining. Time cures such things. And Motif was definitely a vendor perpetrated unmitigated disaster: the worst of it was that it "succeeded" in unifying the UNIX gui, which means it succeeded at stopping all reasonable work on gui's on UNIX until the young Linux turks took over. JG> And by '93 or so, the UNIX vendors actively wanted no change, as they had given up on the desktop and any innovation would cost them money. DH>> The whole "Unix-Haters Handbook" thing was intended to shake up the status quo and inspire people to improve the situation instead of blindly accepting the received view. (And that's what's finally happened, although I can't take the credit, because it largely belongs to Linux -- and now that's the OLPC's mission!) DH>> The unix-haters mailing list was a spin-off of its-lovers@mit-ai: in order to qualify for the mailing list you had to post a truly vitriolic no-holds-barred eyeball-popping flame. DH>> I hope that helps to explain the tone of "The X-Windows Disaster", which I wrote to blow off steam while I was developing the X11 version of SimCity. JG> Yup. I won't hold it against you ;-). Though any operating system with ddt as its shell is downright user hostile... JG>>> The day I thought X was dead was the day I installed CDE on my Alpha. [...] And more about Pango, the text rendering library on top of Cairo, the OLPC's Sugar user interface, which was built on PyGTK, and the OLPC Read book reader app that used the Cairo-based Poppler PDF rendering library: https://en.wikipedia.org/wiki/Poppler_(software) https://news.ycombinator.com/item?id=16852148 >I worked on making the Read activity usable in book mode (keyboard folded away, but gamepad buttons usable), and I vaguely recall putting in an ioctl to put the CPU to sleep after you turned a page, but I'm not sure if my changes made it in. [...] >Sugar had a long way to go, and wasn't very well documented. They were trying to do too much from scratch, and choose a technically good but not winning platform. It was trying to be far too revolutionary, but at the same time building on top of layers and layers of legacy stack (X11, GTK, GTK Objects, PyGTK bindings, Python, etc). >Sugar was written in Python and built on top of PyGTK, which necessitated buying into a lot of "stuff". On top of that, it used other Python modules and GTK bindings like Cairo for imaging, Pango for text, etc. All great industrial strength stuff. But then it had its own higher level Hippo canvas and user interface stuff on top of that, which never really went anywhere (for good reason: it was complex because it was written for PyGTK in a misshapen mish-mash of Python and C with the GTK object system, instead of pure simple Python code -- hardly what Alan Kay thinks of as "object oriented programming"). And for browser based stuff there were the Python bindings to xulrunner, which just made you yearn for pure JavaScript without all the layers of adaptive middle-ware between incompatible object systems. >The problem is that Sugar missed the JavaScript/Web Browser boat (by arriving a bit too early, or actually just not having enough situational awareness). Sugar should have been written in JavaScript and run in any browser (or in an Electron-like shell such as xulrunner). Then it would be like a Chromebook, and it would benefit from the enormous amount of energy being put into the JavaScript/HTML platform. Python and GTK just hasn't had that much lovin'. >When I ported the multi player TCL/Tk/X11 version of SimCity to the OLPC, I ripped out the multi player support because it was too low level and required granting full permission to your X server to other players. I intended to eventually reimplement it on top of the Sugar grid networking and multi user activity stuff, but that never materialized, and it would have been a completely different architecture than one X11 client connecting to multiple X11 servers. >Then I made a simple shell script based wrapper around the TCL/Tk application, to start and stop it from the Sugar menus. It wasn't any more integrated with Sugar than that. Of course the long term plan was to rewrite it from the ground up so it was scriptable in Python, and took advantage of all the fancy Sugar stuff. >But since the Sugar stuff wasn't ready yet, I spent my time ripping out TCL/Tk, translating the C code to C++, wrapping it with SWIG and plugging it into Python, then implementing a pure PyGTK/Cairo user interface, without any Sugar stuff, which would at least be a small step in the direction of supporting Sugar, and big step in the direction of supporting any other platform (like the web). [...]

r Micropolis (SimCity), a work in progress, but I haven't written the rendering stuff yet: https://github.com/SimHacker/MicropolisCore/blob/main/microp... Also, here's a video of the Unity3D pie menus I implemented a dozen years or so ago (there's a link to the code in the description, but it's 12 years old and Unity's approach to user interfaces has changed a lot since then): https://www.youtube.com/watch?v=sMN1LQ7qx9g

ng the code, categorizing methods and instance variables as private and public (to be wrapped by embind), generating the boilerplate Embind declarations, and writing the documentation through a back-and-forth discussion of goals and requirements, and acting like a glorified grep that actually understands the code syntax and accepts English queries instead of obscure command line arguments. The comments at the top (included below) were mostly written by ChatGPT in response to me writing the strategy, telling it in detail what I wanted to do, describing my goals, and how I wanted it to work, with lots of iterating and refining and hand editing: https://github.com/SimHacker/MicropolisCore/blob/main/Microp... The process was anything but automatic or instant -- in total it took about 33 years (and counting, I'm not done yet). I had to guide ChatGPT a lot, drawing from my previous experience porting the Mac version of SimCity to HyperLook on the NeWS window system in 1991, and other platforms later on. At the time I considered using a Mac compatibility library for X11, but that would have resulted in a terrible klunky user interface, could not have taken advantages of the Sun Workstation Unix programming and user interface environment (networking, big screen, better window management, pie menus and other nice user interface components, scalable color PostScript graphics and fonts, using native file formats for resources, audio mixing, lots of computing power to animate fast and zoom into the map, run the simulation super fast by skipping screen updates, profiling and optimizing the code, etc), tied the game to a proprietary library that is long obsolete, and would have only supported X11, not NeWS. For a game like SimCity, it was well worth throwing away the Mac UI, cleaning up the simulator to be independent of the UI, and writing a new high quality UI for HyperLook in NeWS (then later another for TCL/Tk in X11). Porting it to NeWS required separating the simulator from the user interface and defining a clean network API and shared memory raster animation library, rewriting the user interface in PostScript, and defining a messaging protocol between the simulator and UI. Then a few years later I ported that to TCL/Tk on X11, refactoring the simulator/UI messaging interface into TCL extensions. TCL/Tk made it possible to develop a networked multi-player version of SimCity. X11 SimCity Demo: https://www.youtube.com/watch?v=Jvi98wVUmQA Multi Player SimCityNet for X11 on Linux: https://www.youtube.com/watch?v=_fVl4dGwUrA TCL Doc: https://github.com/SimHacker/MicropolisCore/blob/main/notes/... Callbacks: https://github.com/SimHacker/MicropolisCore/blob/main/notes/... A couple of decades later, we made SimCity open source, released the TCL/Tk/X11 version for the OLPC and Linux, then I cleaned up and overhauled the simulator code into C++, and used SWIG to define the API and a callback mechanism, so I could plug it into Python. Micropolis Core: https://github.com/SimHacker/micropolis/tree/master/Micropol... Refactoring the code as C++ really helped modularize and organize it, made it easy to use doxygen to generate documentation, and much easier to wrap and port to different platforms. Doxygen documentation (current): https://micropolisweb.com/doc/ Development Plan (old): https://github.com/SimHacker/MicropolisCore/blob/main/notes/... OLPC Plan (old): https://github.com/SimHacker/MicropolisCore/blob/main/notes/... To Do (old): https://github.com/SimHacker/MicropolisCore/blob/main/notes/... User Interface Plan (old): https://github.com/SimHacker/MicropolisCore/blob/main/notes/... OLPC Notes (old): https://github.com/SimHacker/MicropolisCore/blob/main/notes/... I implemented a couple of Python user interfaces, including a desktop based PyGTK/Cairo/X11 interface, and a web based TurboGears/AMF/OpenLaszlo/Flash client/server interface. Micropolis Online (SimCity) Web Demo (old): https://www.youtube.com/watch?v=8snnqQSI0GE Bil Simser used SWIG it integrate the simulator engine with C#. (SWIG's point is to integrate C++ code into many different scripting languages, not just Python.) C# Micropolis: https://github.com/SimHacker/micropolis/tree/master/Micropol... After all that work, and writing and executing on the design documents linked above, I had a pretty good idea how to prompt ChatGPT to write a design for the Emscripten/Embind API, and it was helpful for writing the boilerplate code, and validating the design, but not so much for coming up with the design in the first place. Beyond refactoring and wrapping the API, ChatGPT has also been extremely useful for learning the intricacies and best practices of TypeScript, SvelteKit, node, WebGL, canvas, CSS, HTML, etc, for developing the user interface. //////////////////////////////////////////////////////////////////////// // This file uses emscripten's embind to bind C++ classes, // C structures, functions, enums, and contents into JavaScript, // so you can even subclass C++ classes in JavaScript, // for implementing plugins and user interfaces. // // Wrapping the entire Micropolis class from the Micropolis (open-source // version of SimCity) code into Emscripten for JavaScript access is a // large and complex task, mainly due to the size and complexity of the // class. The class encompasses almost every aspect of the simulation, // including map generation, simulation logic, user interface // interactions, and more. // // Strategy for Wrapping // // 1. Core Simulation Logic: Focus on the core simulation aspects, such // as the methods to run the simulation, update game states, and handle // user inputs (like building tools and disaster simulations). This is // crucial for any gameplay functionality. // // 2. Memory and Performance Considerations: JavaScript and WebAssembly // run in a browser context, which can have memory limitations and // performance constraints. Carefully manage memory allocation, // especially when dealing with the game's map and various buffers. // // 3. Direct Memory Access: Provide JavaScript access to critical game // data structures like the map buffer for efficient reading and // writing. This can be done using Emscripten's heap access functions // (HEAP8, HEAP16, HEAP32, etc.). // // 4. User Interface and Rendering: This part might not be necessary to // wrap, as modern web technologies (HTML, CSS, WebGL) can be used for // UI. However, providing some hooks for game state (like score, budget, // etc.) to JavaScript might be helpful. // // 5. Callbacks and Interactivity: Ensure that key game events and // callbacks are exposed to JavaScript, allowing for interactive and // responsive gameplay. // // 6. Optimizations: Where possible, optimize C++ code for WebAssembly, // focusing on critical paths in the simulation loop. // // Decisions and Explanations // // - Excluded Elements: // // - Low-level rendering or platform-specific code, as this can be // handled more efficiently with web technologies. // // - Parts of the code that handle file I/O directly, as file access // in a web context is typically handled differently (e.g., using // browser APIs or server-side support). // // - Any networking or multiplayer code, as web-based // implementations would differ significantly from desktop-based // network code. // // - Included Elements: // // - Core game mechanics, such as map generation, zone simulation // (residential, commercial, industrial), disaster simulation, and // basic utilities. // // - Game state management, including budgeting, scoring, and city // evaluation. // // - Direct memory access to critical structures like the map // buffer, allowing efficient manipulation from JavaScript. // // - Essential callbacks and event handling mechanisms to ensure // interactivity. // // Conclusion // // Given the complexity and size of the Micropolis class, wrapping the // entire class directly is impractical. However, focusing on key areas // essential for gameplay and providing efficient interfaces for // critical data structures can create a functional and interactive city // simulation in a web context. Further optimizations and adjustments // would likely be needed based on testing and specific requirements of // the web implementation. // // Implementation Notes // // The enum_, class_, constructor, function, and property functions // from the emscripten namespace are used to specify how C++ // constructs should be exposed to JavaScript. You can use these to // control which parts of your code are accessible and how they should // be used from JavaScript. // // I've made some assumptions here: // // The types MapValue and MapTile are simple types (like integers or // floats). If they are complex types, they would need their own // bindings. // // I'm assuming that the copy constructor and copy assignment // operator for the Position class are correctly implemented. If // they aren't, then the Position object may not behave as expected // in JavaScript. // // Micropolis Binding Design // // The Micropolis interface organizes the Micropolis class header into // categories of functions that are relevant for interaction with the // JavaScript user interface, scripts, or plugins. The aim is to expose // functions that could help in monitoring and controlling game state // effectively. //

n packs for The Tower II that were only released in Japan, and I plan on making a more flexible modern version of TowerKit in the form of a Yoot Tower SDK that lets you dynamically script and download extensions in JavaScript instead of modifying and recompiling C++ code. https://github.com/YootTowerManagement/YootTower/tree/main https://web.archive.org/web/20000521002924fw_/http://www.ope... >What's Tower Kit? >Tower Kit is optional software for The Tower II. In The Tower II, you can select the stage where you want to start the game using the concept of a "map." The Tower II package comes with three maps: "Shinjuku Subcenter," "Hawaii Diamond Head," and "Kegon Falls," and the "Tower Kit" adds these maps. By installing this tower kit, a new stage game will begin. Tower kits don't just add more stages. Each map has new features, allowing you to play a completely new game. >Please try the "Tower Kit" which allows for infinite variations. >A love story between you, the person in charge of the Liberty Island redevelopment project, and two men and women who are your subordinates. Your work will have a subtle influence on the course of your love life. The Tower II is the first attempt at a crossover between redevelopment and love, set in New York. What is the ending...? I did a similar thing for Micropolis/SimCity more than a decade ago, but with Python and SWIG, instead of emscripten and embind, so you could program your own agents (like PacBot, who follows the roads and eats traffic) and zones (like the Church of Pacmania, which worships and attracts PacBots, and causes lots of traffic to feed them). Micropolis Online (SimCity) Web Demo: https://www.youtube.com/watch?v=8snnqQSI0GE A demo of the open source Micropolis Online game (based on the original SimCity Classic source code from Maxis), running on a web server, written in C++ and Python, and displaying in a web browser, written in OpenLaszlo and JavaScript, running in the Flash player. Developed by Don Hopkins. Source Code: https://github.com/SimHacker/micropolis HAR 2009 talk: Constructionist Educational Open Source SimCity: https://donhopkins.medium.com/har-2009-lightning-talk-transc... Church of PacMania: https://github.com/SimHacker/micropolis/blob/master/Micropol... PacBot: https://github.com/SimHacker/micropolis/blob/main/Micropolis... https://github.com/SimHacker/micropolis/blob/master/laszlo/m... Back when I was porting SimCity to Unix in the early 90's, Maxis gave me the source code to SimEarth too, but I never had the chance to port it, and don't have permission now unfortunately. I'd love to make a modern version of SimEarth and SimAnt too, but neither of them were as successful or engaging a game as SimCity. Will Wright discusses SimEarth, SimAnt, and SimCity 2000 in this 1996 talk he gave to Terry Winnograd's user interface class, and also demonstrates a very early version of The Sims when it was called Dollhouse. His point was that SimAnt was too simple, SimEarth was too complex, but SimCity 2000 was just right, and Dollhouse was the next thing he was working on, which became The Sims. I'd also love to make a modern version of The Sims 1, but I don't have permission for that either, and have never been able to talk anyone at EA to reproduce the miracle it took to release SimCity. But I'm delighted and grateful to have the chance to work with Yoot Saito on SimTower instead, since he retained all the rights to his code, and we're both on the same page about educational games, constructionist education, and our respect for Alan Kay and Seymour Papert's philosophy about teaching kids to program and motivating it with games. A visual programming language in Micropolis and Yoot Tower would be great (that's the long term plan), like the SimAntics VPL in The Sims 1 (but much easier to use and extend). Will Wright - Maxis - Interfacing to Microworlds - 1996-4-26: https://www.youtube.com/watch?v=nsxoZXaYJSk Here's an article I wrote about that talk right after attending it, that I updated in later years after working with Will on The Sims, and then even more recently when Stanford finally published the video of the talk decades later: https://donhopkins.medium.com/designing-user-interfaces-to-s...

anese bar, but he had some time to chat. >He said he once did a big interview with BBC about SimTower (which would be worth looking up and watching if you can find it), and had a friend who worked in the elevator industry, who told him generally about how elevators worked, but much of it was secret and proprietary, so he had to come up with how they worked in the game himself, based on the general ideas he learned and his own experience and imagination. >He also said he's interested in releasing the original source code of SimTower as free open source software, like I did with the original SimCity Classic source code, so I volunteered to help him and find other people who could help. Anybody interested? ;) Yoot recently sent me a huge code drop of the Windows sources as well as the Gameboy SP and DS versions and production documents, and I'm sorting it out and cleaning it up to make a version that compiles with emscripten and runs in the web browser. We've decided it release it under the MIT license, and develop a version that runs in the web browser using emscripten and SvelteKit. I'd appreciate hearing from people who are interested in helping out, especially people who know Japanese, since there is a lot of great content in The Tower II that was only released in Japan that needs translating to English and other languages. I've also started the process of porting the Micropolis (open source SimCity) code to run in the web browser in the same way as Yoot Tower, since they are both from the same era (and from Maxis) and share a lot of technologies and requirements, so they will both be able to share much of the code and infrastructure (WebAssembly, emscripten, embind, SvelteKit, canvas, html, css, user interface code, github actions, etc), with the eventual goal of being able to embed multiple Yoot Towers in your Micropolis city! https://github.com/SimHacker/MicropolisCore >Open Source Micropolis, based on the original SimCity Classic from Maxis, by Will Wright. >MicropolisCore C++ Core >This is the source code for Micropolis (based on SimCity), released under GPL-3. Micropolis is based on the original SimCity from Electronic Arts / Maxis, designed and written by Will Wright, and ported to Unix by Don Hopkins. >The origin of this repo is the "MicropolisCore" directory of the full micropolis repo, https://github.com/SimHacker/micropolis , but it's been stripped down and simplified. >I am now in the process of converting it to build for WebAssembly with emscripten and bind to JavaScript with embind, and implementing a SvelteKit front-end. Since I know the SimCity code well already and have ported it to many different platforms, and put years of effort into cleaning up the old code to be well organized C++ code with clean interfaces and doxygen documentation, it's a great way to learn the new technologies, work out the approach, and prepare for porting SimTower the same way. ChatGPT has been a huge help, especially analyzing the code and writing documentation and translating the Japanese comments, and now I'm using Aider for them both: Aider: AI pair programming in your terminal (github.com/paul-gauthier): https://news.ycombinator.com/item?id=39995725 Here's a code map for each source file that I made with ChatGPT that focuses on helping me get a high level view of the code, its dependencies, purposes of each file, and porting issues: https://github.com/YootTowerManagement/YootTower/blob/main/Y... The Nintendo Gameboy SP and DS versions of Tower have a whole lot of proprietary Nintendo SDK code and also their precious proprietary content and characters like Mario, which we are certainly not able to release ourselves under the MIT license, so I'm working with the more generic Windows version instead. Yoot owns the rights to the source code to his own games, but we can't just release stuff with Nintendo's crowned jewels like Mario and their SDKs in it as open source. We are being extremely careful not to infringe on anyone’s copyrights or trademarks, of course! Maxis got into a lot of trouble with Godzilla just because they had a big monster on the box but didn’t mention Godzilla by name (but a review in a magazine did, which was too much), and Maxis (now EA) own the SimTower trademark, so we’re calling it Yoot Tower. The Nintendo Gameboy and DS console ports of SimTower have a lot Nintendo content (like Mario), so we definitely don’t want to make Nintendo or EA mad by infringing on their trademarks or copyrights. Jeff Braun (CEO of Maxis) told me the story of what happened decades ago with Maxis and Godzilla, so I want to be careful to avoid stomping on anybody’s property: >Maxis was sued by Toho. We never referred to the name Godzilla, our monster on the box cover was a T-Rex looking character, but... a few magazine reviews called the monster, Godzilla. That was all it took. Toho called it "confusion in the marketplace". We paid $50k for Godzilla to go away. In all honesty, Toho liked Maxis, they said $50k was the minimum they take for Godzilla infringement. I doubt you will need to worry about Toho, as long as there are no magazine reviews that call the monster Godzilla. I guess the lesson is to always make sure to give your monsters a unique name, and don’t leave that up to the user’s imagination.

versity of Cambridge Library Archives: https://www.cl.cam.ac.uk/library/archives.html In 1986 Mike Gallaher and I together came up with the same idea, and I implemented a prototype proof-of-concept for the X10 window system I called "theta menus": https://donhopkins.com/home/pub/piemenus/theta-menus/ Mitch Bradley suggested the name "pie menu", and I implemented them in the X10 "uwm" window manager, which I integrated into Mitch's Sun Forth system so it was possible to script the window manager in Forth: https://donhopkins.com/home/pub/piemenus/pietest/ https://donhopkins.com/home/pub/piemenus/pietest/fuwm-main.f X10 Pie Menu Window Manager: https://www.youtube.com/watch?v=IJhvB6kwmog You could define both pie menus and linear menus in a special menu definition syntax in your .uwmrc file, and configure them to run various window management, application launching, and shell scripting commands. But there was no pie menu editor, just a text file defining the menus. We performed an experiment to compare the speed and error rate of pie menus and linear menus, which I programmed in Forth to randomize and present the menus and measure the error rates and timing statistics. Pie Menu Experiment: https://www.youtube.com/watch?v=s0zEUi6p2ws Implementing a Forth scriptable pie menu window manager for X10 led the way to implementing pie menus in PostScript for various versions of the NeWS window system. It was easy for me to make the transition from Forth to PostScript, which is much more like Lisp than like Forth, and NeWS had an object oriented programming system like Smalltalk which is great for implementing user interface toolkits. Just the pie menus from All The Widgets: https://www.youtube.com/watch?v=mOLS9I_tdKE Ben Shneiderman demo: Don Hopkins and pie menus in ~ Spring 1989 on a Sun Workstation, running the NEWS operating system. https://www.youtube.com/watch?v=8Fne3j7cWzg PSIBER Space Deck Demo: https://www.youtube.com/watch?v=iuC_DDgQmsM HCIL Demo - HyperTIES Authoring with UniPress Emacs on NeWS: https://www.youtube.com/watch?v=hhmU2B79EDU NeWS Tab Window Demo: https://www.youtube.com/watch?v=tMcmQk-q0k4 After NeWS, I made an X11 window manager based on "twm" called "piewm": https://donhopkins.com/home/pub/piemenus/piewm/ https://www.donhopkins.com/home/catalog/unix-haters/x-window... Then I implemented pie menus for TCL/Tk on X11, which I used for the X11 version SimCity (which EA later relicensed under GPL-3 and released for the OLPC). https://github.com/SimHacker/micropolis/blob/master/micropol... X11 SimCity Demo: https://www.youtube.com/watch?v=Jvi98wVUmQA Multi Player SimCityNet for X11 on Linux https://www.youtube.com/watch?v=_fVl4dGwUrA Playing SimCity for X11 on Linux with Pie Menus in San Francisco: https://www.youtube.com/watch?v=1p7_fapUq20 I later implemented the pie menus in The Sims, which you can see an early version of here, including a graphical zooming/rotating pie menu that didn't make it into the game: The Sims Steering Committee - June 4 1998: https://www.youtube.com/watch?v=zC52jE60KjY Another take on pie menus that did make it into the game was the object placement tool that let you rotate objects both as you picked them up and set them down, like an invisible "direct manipulation pie menu" (see the demo of object placement tool placing chairs around the dining room table at 4:45): https://www.youtube.com/watch?v=-exdu4ETscs Not only can you rotate it while placing it down, but also while picking it up. Clicking picks up or places down without rotating, but pressing and moving rotates to face the direction of motion. Unfortunately, later versions of The Sims didn't implement that simple feature, so instead you have to use the keyboard or repeatedly click multiple times until it rotates around to the direction you want, which is much more difficult and less natural than simply dragging in the direction you want it to face when picking up or placing down. Here's a later web based version of Micropolis (open source SimCity) with pie menus implemented with OpenLaszlo / Flash -- at 3:00 it demonstrates how the pie menus work as an alternative to the traditional tool palette, and once you learn the pie menus you can hide away the palette to gain many acres of SimCity "screen real estate": https://www.youtube.com/watch?v=8snnqQSI0GE ActiveX Pie Menus: https://www.youtube.com/watch?v=nnC8x9x3Xag The ActiveX pie menus were implemented as an OLE Control, which supported editing via a tabbed property sheet using traditional gui widgets like buttons, tree editors, text editors, and a wysiwyg (but not editable) preview. One nice feature was that you could simply type in an indented outline into the text editor to produce a whole tree of nested menus, which saved a whole lot of pointing and clicking gui widgets to create the menus and items one by one. But I hit a wall because I wanted more control over the graphical presentation and dynamic feedback, that was extremely difficult to program with MFC/Win32/C++/GDI, and I wanted the full features of a web browser to render each item, including animated gifs, css styles, etc. JavaScript Pie Menu IE5 Behavior Components: https://www.youtube.com/watch?v=R5k4gJK-aWw So implementing pie menus inside the web browser in JavaScript with DHTML and CSS was the obvious next step, which also made it easy to define menu structures with XML and presentation with HTML. You could put anything you wanted into the pie menu center or items. But Microsoft's IE5 Behavior Components were a dead-end. JQuery Pie Menus: https://github.com/SimHacker/jquery-pie So later on after jQuery came along I implemented pie menus for jQuery, using jQuery-UI. Unity3D Pie Menu Demo: https://www.youtube.com/watch?v=sMN1LQ7qx9g Pet Rock Remote Control -- Touch screen pie menu interface on Pocket PC for sending commands to rocks: https://www.youtube.com/watch?v=SG0FAKkaisg

eboard overlay and voting dialogs and pie menus, which I described in my other post: https://news.ycombinator.com/item?id=38155984 Multi Player SimCity for X11 is now available from DUX Software! http://www.art.net/~hopkins/Don/simcity/simcity-announcement... SimCityNet: a Cooperative Multi User City Simulation at InterCHI '93: http://www.art.net/~hopkins/Don/simcity/simcitynet.html Multi Player SimCityNet for X11 on Linux: https://www.youtube.com/watch?v=_fVl4dGwUrA Back when ActiveX was a thing, Mike Perry at Maxis produced a web browser plug-in version of SimCity that was simply integrated with a text chat window, so although you were playing your own local copy of SimCity, you could chat with other users playing their own cities in their own browsers, brag and gossip about your city, ask questions and help each other. It was a huge hit relative to the amount of effort it took to implement, and despite its clunky stripped down user interface, but it demonstrated how essential and engaging communication between players was, even if they couldn't actually affect each others games or share save files. https://en.wikipedia.org/wiki/Mike_Perry_(game_developer) http://www.andywest.org/pr/simcity/misc/introduction.html >Meanwhile SimCity Classic did not die: Maxis/EA has transformed it into a Web game you can play from your browser (after registration). The Web SimCity plays just like the computer game, except that it does not have every feature. Also, since the game is an ActiveX control, you must use Internet Explorer to play it. I also designed and produced two different educational versions of SimCity/Micropolis, one an OLPC XO-1 Laptop interface for kids (X11/Cairo/PyGTK/Sugar) and one a web client/server interface (Python/TurboGears/AMF/OpenLaszlo/Flash) for an online community around shared multiplayer games and a storytelling platform. I completed MVP first-cuts, shipping the single player X11 version on the OLPC, and a web interface supporting multiple players sharing simulations running on the server. https://github.com/SimHacker/micropolis/blob/master/turbogea... https://github.com/SimHacker/micropolis/blob/master/laszlo/m... I haven't fully completed the long term plans for the web based version, because Sugar never panned out then Flash died, and I didn't have the resources or support. Finding support for developing educational software is tough, and I'd rather contribute new stuff to a truly free open educational community inspired by Seymour Papert's philosophy, like Snap!, than sharecrop on EA's intellectual property. https://snap.berkeley.edu/ I believe Seymour Papert's collaborative constructionist educational ideas can be applied to other city simulators, many other types of games, and especially visual programming environments like Snap! It's fortunate that SAP supports Jens Mönig to continue building on top of the block based visual programming ideas that he, Brian Harvey, John Maloney, Yoshiki Ohshima, Alan Kay, the MIT Media Lab Scratch project, and others developed: https://faberllull.cat/en/resident.cfm?id=38258&url=jens-mon... Micropolis Online (SimCity) Web Demo: https://www.youtube.com/watch?v=8snnqQSI0GE Micropolis: Constructionist Educational Open Source SimCity: https://donhopkins.medium.com/har-2009-lightning-talk-transc... Plan for developing Micropolis for OLPC: https://github.com/SimHacker/micropolis/blob/master/micropol... Micropolis for OLCP Sugar User Interface: https://github.com/SimHacker/micropolis/blob/master/Micropol... 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. [... lots more at:] OLPC-Notes.txt: https://github.com/SimHacker/micropolis/blob/master/Micropol... PLAN.txt: https://github.com/SimHacker/micropolis/blob/master/micropol...