Since SimCity was originally designed to run on the C64, I don't think performance is too much of a concern on modern hardware, since it runs more than fast enough, and definitely wasn't intended to run at 120 frames per second running 50 simulation ticks per frame (which is what you get when you press the "9" key, and the user interface is still quite responsive on my M1 Mac).

Although running it that fast is great for fast-forwarding time, but not practical for actually trying to build the city with the editing tools while it's running at such high speeds. Even 30 FPS with one tick per frame is too fast for most people to keep up with.

When I developed it on a SparcStation 2 under the NeWS window system in 1991, the user interface was written completely in PostScript, which was orders of magnitude slower than JavaScript and WebAssembly, since it was interpreted, not compiled or JIT'ed or optimized in any way. But it still worked just fine, orders of magnitude faster than a C64, and could easily run at many years per second.

The pie menus (which I'll implement soon for Micropolis) are able to reliably support quick gestural mouse-ahead interactions, even when the computer lags behind. And they made it a lot easier to play the game at high speeds (or when the computer is busy), because you didn't have to waste your time moving back and forth between the map and the tool palette, and you can quickly and easily change tools with swift reliable mouse-ahead gestures.

When I showed it to user interface critic Don Norman, who makes a strong case for solving problems instead of focusing on technology, he actually complained about pie menus making SimCity too easy to build a city really quickly without even thinking about it.

https://www.youtube.com/watch?v=5GCPQxJttf0

Norman: "And then when we saw SimCity, we saw how the pop-up menu that they were doing used pie menus, made it very easy to quickly select the various tools we needed to add to the streets and bulldoze out fires, and change the voting laws, etc. Somehow I thought this was a brilliant solution to the wrong problems. Yes it was much easier to now to plug in little segments of city or put wires in or bulldoze out the fires. But why were fires there in the first place? Along the way, we had a nuclear meltdown. He said "Oops! Nuclear meltdown!" and went merrily on his way."

Hopkins: "Linear menus caused the meltdown. But the round menus put the fires out."

Norman: "What caused the meltdown?"

Hopkins: "It was the linear menus."

Norman: "The linear menus?"

Hopkins: "The traditional pull down menus caused the meltdown."

Norman: "Don't you think a major cause of the meltdown was having a nuclear power plant in the middle of the city?"

(laughter)

Hopkins: "The good thing about the pie menus is that they make it really easy to build a city really fast without thinking about it."

(laughter)

Hopkins: "Don't laugh! I've been living in Northern Virginia!"

Norman: "Ok. Isn't the whole point of SimCity how you think? The whole point of SimCity is that you learn the various complexities of controlling a city."

X11 SimCity Demo -- Demo of Pie Menus in SimCity for X11. Ported to Unix and demonstrated by Don Hopkins:

https://www.youtube.com/watch?v=Jvi98wVUmQA

Even the Flash client / Python server networked version runs plenty fast over the internet, and also supports pie menus:

https://www.youtube.com/watch?v=8snnqQSI0GE

Micropolis: Constructionist Educational Open Source SimCity:

https://donhopkins.medium.com/har-2009-lightning-talk-transc...

>The NeWS and X11 version both supported advanced user interface features like multiple animated maps and editors, as well as pie menus. The X11 version supported multiple player collaboration, shared text chat and drawing, and voting dialogs. And Unix workstations could run the simulation orders of magnitude faster than home computers, which transformed SimCity into a fast action twitch game!

Of course it's fun to optimize just for the sake of optimization, but I think it's more interesting spending the time taking advantage of browser technologies like WebGL, HTML, CSS, Canvas, SVG, and other tools and libraries, to make a rich beautiful user interfaces with useful visualizations (like publishing analytic data into a time series database, and rendering it in tools like Grafana, or using D3 for data visualization).

https://news.ycombinator.com/item?id=40065764

I want to push as much of the user interface out of the engine and into JavaScript/HTML/Canvas/SvelteKit as possible, since it's so much easier to make much better more advanced user interfaces with a modern stack than trying to deal with a crufty Windows emulation layer, and make improvements to that kind of code.

One thing I want to do is to make both Micropolis and Tower able to export lots of raw and cooked data, telemetry, and events, so I can use d3, Grafana, and other off-the-shelf data visualization tools to analyze and display the game state and history.

A couple decades ago an Earth Science professor Upmanu Lall at Columbia University proposed a great idea about developing an educational version of SimCity to use in his classes aimed at engaging students from other departments and getting them interested in data analysis and science. He wanted SimCity to simply be able to export spreadsheets of data, and have the students perform experiments and analyze the data using standard tools like Excel. A game like SimCity or SimTower would be an engaging way to pique the student's interest, that they could relate to, and motivate and teach a general literacy and understanding of spreadsheets and data analysis and visualization tools!

Upmanu Lall:

https://www.columbia.edu/~ula2/

Here's the Educational SimCity proposal I wrote, but it didn't go anywhere until many years later when we finally talked EA into relicensing SimCity under GPL-3 for the One Laptop per Child project.

https://web.archive.org/web/20050403103131/http://www.donhop...

Yes, his thesis was outstanding, and a lot of the best parts ended up in the book.

I really appreciated the big section at the beginning about Doreen Nelson's life work, Design Based Learning, which he also covered in depth in the Building SimCity book. She and Michael Bremmer wrote the SimCity Teacher's Guide (which Cliff Basinger (LGR) found on eBay, made an unboxing video review about, and sent me his copy of. I have been meaning to scan it and put it online -- I'll see if I can dig it up and scan it, since it would make a great addition to the Micropolis project).

LGR - SimCity Educational Version Unboxing & Overview: An overview of the "School Edition" Lab Pack of SimCity Classic by Maxis. Unboxing, first impressions of the package and testing of the radically rad software ensues.

https://www.youtube.com/watch?v=edXRNtuAGTg

More about Doreen Nelson:

https://news.ycombinator.com/item?id=21049206

DonHopkins on Sept 23, 2019 | parent | context | favorite | on: OLPC’s $100 laptop was going to change the world (...

>There were many reasons the OLPC failed, but I don't think constructionist education was one of them, when it's succeeded in so many other places.

>EA donated SimCity to OLPC because of its relation to constructionist education, thanks to Maxis's collaboration with Doreen Nelson, who wrote the SimCity teacher's guide, and developed "City Building Education" and "Design Based Learning", in which kids built cities out of cardboard instead of pixels:

https://news.ycombinator.com/item?id=20329281

>SimCity can be used educationally, but not in the sense of literally training people to be urban planners or mayors. It's more useful for "Constructionist Education" and "Design Based Learning", as practiced by Seymour Papert and Doreen Nelson.

>[...] One of the teachers [Clair] Curtin hired was Doreen Nelson, a brilliant and innovative educator who had developed a pedagogy called City Building Education, in which students collaboratively built cities out of craft materials and role play. Nelson become a regular visitor to Maxis, and Curtin made some trips to Los Angeles to see City Building in action, where she found the experience of “watching a classroom actually go through a couple of days worth of creation” to be “very inspiring. … I will never forget that experience” (Curtin 2015; Nelson 2015). [5]

>[5]> This translation took the form of a short teacher’s guide, a pamphlet, really, written by Michael Bremer, and published by Maxis in 1989—the same year SimCity was released, explaining the limitations and applications of SimCity, and offering curricular questions and scripts. Within a few years, Maxis became more serious about tackling the education market, and hired Claire Curtin, in 1992, as their first educational product manager, charging her with finding ways to package SimCity, SimEarth, and SimAnt for the school market. Prior to joining Maxis, Curtin had been the senior producer of Brøderbund’s hit educational franchise, Where In The World Is Carmen Sandiego?, a job she had started in 1988, immediately after finishing graduate studies at NYU’s Educational Communication and Technology program, where she had studied with the noted education technology researcher Roy Pea. Over the course of her career at Maxis, Curtin shifted roles and projects, a result of Maxis’s fickle focus and its inability to produce hits beyond SimCity (chapter 5). Later, when Maxis defocused on a hard to reach education market, Curtin would go on to co-design or co-produce the kids’ titles SimTown (1995) and SimSafari (1998). Curtin collaborated closely with Roxana (“Roxy”) Wolosenko, and after Maxis decided not to do any more kid specific titles, the two of them were shifted to Wright’s “Dollhouse” project—a title that was not spoken out loud due to its gender connotations—where they were instrumental, as Wright’s co-designers, in evolving the design focus away from time management and towards people and interactions inspired by everyday life. It is this more human centric vision of Dollhouse that eventually saw release as The Sims, which became, at long last, the second commercially successful Sim title (Curtin 2015).

>page 366> Play has a complex relationship to what is not play. Depending on who you ask, SimCity, the software toy, is either a frivolous diversion or an earnest model—and sometimes both. Right from the start, SimCity had appeal as an educational tool, a quality that Maxis tried to capitalize on. According to Braun, “It was never our intention to go into the education market, but the education market came to us and said: ‘This is what we need if you’re gonna work with us.’ ” What the education market wanted was teacher’s guides that translated and adapted SimCity for classroom use. It didn’t hurt that Brøderbund, Maxis’s publishing partner, was deep into the then hot educational software market, and that along with the investment Maxis received from venture capitalists in 1992, came a hunger for aggressive growth into new markets. Wright, of course, was busy making titles like SimEarth and SimAnt for an uncertain market. Maybe that market was education?

Chaim also wrote a section in his thesis about open sourcing SimCity:

Open Sourcing SimCity, by Chaim Gingold.

https://donhopkins.medium.com/open-sourcing-simcity-58470a27...

>Excerpt from page 289–293 of “Play Design”, a dissertation submitted in partial satisfaction of the requirements for the degree of Doctor in Philosophy in Computer Science by Chaim Gingold.

His book also covered a lot of interesting stuff about cellular automata, including John von Neumann's 29 state cellular automata and universal constructor!

Von Neumann Universal Constructor (wikipedia.org)

https://news.ycombinator.com/item?id=22727228

https://en.wikipedia.org/wiki/Von_Neumann_universal_construc...

My JavaScript CAM6 cellular automata machine simulator has an implementation of it, but it needs a better user interface if you want to build a non-trivial machine (especially a self replicating one!)

https://github.com/SimHacker/CAM6/blob/cbad2920fd0fab5b35baf...

More about the theory of self reproducing cellular automata:

https://news.ycombinator.com/item?id=32960377

https://archive.org/details/theoryofselfrepr00vonn_0

https://news.ycombinator.com/item?id=21855249

"Signal crossing solutions in von Neumann self-replicating cellular automata", page 453-503

https://donhopkins.com/home/documents/automata2008reducedsiz...

https://news.ycombinator.com/item?id=21858465

>>The von Neumann probe, nicknamed the Goo, was a self-replicating nanomass capable of traversing through keyholes, which are wormholes in space. The probe was named after Hungarian-American scientist John von Neumann, who popularized the idea of self-replicating machines.

>Third, the probabilistic quantum mechanical kind, which could mutate and model evolutionary processes, and rip holes in the space-time continuum, which he unfortunately (or fortunately, the the sake of humanity) didn't have time to fully explore before his tragic death.

>p. 99 of "Theory of Self-Reproducing Automata":

>Von Neumann had been interested in the applications of probability theory throughout his career; his work on the foundations of quantum mechanics and his theory of games are examples. When he became interested in automata, it was natural for him to apply probability theory here also. The Third Lecture of Part I of the present work is devoted to this subject. His "Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components" is the first work on probabilistic automata, that is, automata in which the transitions between states are probabilistic rather than deterministic. Whenever he discussed self-reproduction, he mentioned mutations, which are random changes of elements (cf. p. 86 above and Sec. 1.7.4.2 below). In Section 1.1.2.1 above and Section 1.8 below he posed the problems of modeling evolutionary processes in the framework of automata theory, of quantizing natural selection, and of explaining how highly efficient, complex, powerful automata can evolve from inefficient, simple, weak automata. A complete solution to these problems would give us a probabilistic model of self-reproduction and evolution. [9]

>[9] For some related work, see J. H. Holland, "Outline for a Logical Theory of Adaptive Systems", and "Concerning Efficient Adaptive Systems".

https://www.deepdyve.com/lp/association-for-computing-machin...

https://deepblue.lib.umich.edu/bitstream/handle/2027.42/5578...

https://www.worldscientific.com/worldscibooks/10.1142/10841#...

Good question, please don't downvote -- there's an interesting discussion to be had about that!

The best approach is to use it like any other tool, and not expect it to do all the hard work for you, just relieve you of a lot of tedious work, and help you learn how to be a better programmer yourself, not replace you. There's no such thing as a free lunch, but some lunches are tastier and more nutritious and less expensive than others.

I've been using ChatGPT to develop it, and it's helped a lot, and takes a great deal of iteration and guidance, but it's anything but instant.

LLMs won't replace programmers, but programmers with LLMs will replace programmers without LLMs.

Here's an example of how it was helpful in simply explaining the documentation and best practices of tools like Emscripten and Embind, getting the makefile to work, analyzing 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.
    //