micropolis

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). [...]