MicropolisCore

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

e patterns, that draw into the tiles themselves, so you can play with the tile map like KidPix! More discussion of Micropolis development plans: https://github.com/SimHacker/MicropolisCore/pull/3 An example of what I mean about KidPix drawing with SimCity tiles (without the drawing tools hooked up yet, really just a cellular celebration of the newly added tile sets): https://www.youtube.com/watch?v=319i7slXcbI Integrating Snap! with Micropolis enables procedural circuit bending: https://en.wikipedia.org/wiki/Circuit_bending >Circuit bending is the creative, chance-based customization of the circuits within electronic devices such as low-voltage, battery-powered guitar effects, children's toys and digital synthesizers to create new musical or visual instruments and sound generators. >Emphasizing spontaneity and randomness, the techniques of circuit bending have been commonly associated with noise music, though many more conventional contemporary musicians and musical groups have been known to experiment with "bent" instruments. Circuit bending usually involves dismantling the machine and adding components such as switches and potentiometers that alter the circuit. Will mentions Braitenberg machines in his 1996 talk, "Will Wright - Maxis - Interfacing to Microworlds - 1996-4-26", in response to questions a student asked about modeling interpersonal interaction and I asked about storytelling: https://youtu.be/nsxoZXaYJSk?t=4466 Student: What about from person to person, you talking about the information that's contained within the objects, so there can be information in another person, that you want to interact with in the environment. Have you looked at any reasons why you would want to do that? Will Wright: Oh yeah, I mean, that's that's the hard problem. I mean, simulating ants is hard enough, when you get to people there's really no hope. There are two issues here. You can look at this as a technology. It's not a product right now. And their are a few directions this could go. I could see this becoming, let's say, a multiplayer network MUD kind of a thing. You might have a thousand people playing SimCity from the bottom up, each person building their own house in a big multi-user space. In which case that issue is a little less important, because most of the people are real people, and you're dealing with puppets. As a standalone game, which is probably our our closer target, we have to deal with the problem you're bringing up, which is how do we deal with people to people? And it's hard, I mean there's just -- I'm sure Terry can elaborate on that more than I can. But the best thing we can do is prop up a convincing illusion. We don't have to be doing a valid simulation of human personality. What we have to do is we have to put up something that's ambiguous enough to where somebody can read in what they want. Actually in this thing what I have right now are people come up and they converse, but you don't hear what they're saying, they just gesture, and sometimes they look mad, sometimes they kind of look contemplative. It's kind of interesting how much people will read into that. This is kind of dynamic that we've seen again and again where something happens in SimCity and they said "oh I was running my nuclear reactor near the red line, and then there was so much smoke coming out of it, this plane crashed, and because of that, this and that happened", and they'll describe this long causal chain of events that I know does not exist. I designed the simulation, I know that there's no linkage between the power output of the power plant, the planes crashing, but they're convinced it exists. Don Hopkins: They're using it as a medium to tell stories about. Will Wright: Yeah! Don Hopkins: Where they're using it as a piece of paper, to write. Will Wright: Yeah, that's exactly right. There's a parallel simulation going on here in the game. Everybody's taking a linear path through this, and they're basically, most people will attempt to understand things like this with a story. They'll think about "I did this, then that happened, because of that", and so the story becomes kind of their logical connection, their logical reverse engineering, of the simulation that they're playing inside of. Now on the people's side, I think we can do a lot in this as a product, by propping up that illusion of people. Again, if this is a doll house, we don't want the dolls to be sentient things. We want the dolls to be interesting enough to where I can play games with them. There was actually a really interesting doll that this company came out with. Oh, it was Worlds of Wonder, this really cool doll, I've got a couple of them after they went out of business. It's called the Julie doll. But it was like this $250 doll with voice recognition, and it said all these things. It had just a huge amount of ROM with digitized speech in it, and so it would sit there and try and have stupid conversations with you. And really it was kind of Eliza, or had keywords it would recognize, and give you these kind of non-committal responses. But in the testing of that, well first of all it was a $300 doll. Who's going to buy the kid a $300 doll? So it was really more, it was actually the only doll I've ever seen that appealed to grown men. Grown men love this, I mean this is a hacker's doll. But I talked to the guy who was working this project, and he said they put this in focus groups with girls. And they played with it for a while, and then after about a half an hour they take the batteries out, and keep playing with it. And what was happening is that the girls were propping up this elaborate fantasy in their play, and the dolls were supposed to be a structure for that fantasy, they weren't supposed to be the fantasy. The doll was telling them what the fantasy was, and it was conflicting with what the girls were saying, and so it was interfering actively with their fantasy and their play. So in that regard, I think we can actually kind of take that path with these people. And all we have to do is deal with them at a very local kind of a state machine, Braitenberg Machine kind of level, and say that they're angry, and they're hungry, and they're sleepy. And then we can actually do some things where maybe they have a little, what you might call, structural ambiguity about what they're actually saying. One of the thoughts I had about this project in particular is that you'd see the people go up and they talk, and there would be some kind of a flavor to their conversation, but it would be more like Peanuts. When they did the TV show of Peanuts, you'd hear the adults talking, and the adults would always be like "mwa mwa mwa mwa mwa mwa", or soft, or loud. You can tell if they're mad, or angry, or what, but you wouldn't hear what they were saying. You'd have to read that into it. I think this is the area where we sidestep the issue, just because as a commercial company we have to ship a game, we're not doing a research project. So that's a long winded answer, sorry.

$5 to shut the fuck up for 5 minutes a month about any topic you want. You are free to examine all of the source code on Github, and report bugs, and build it yourself. And your web browser also has excellent built-in debugging and reverse engineering tools that you can use to examine the WebAssembly binary and pretty print the compiled JavaScript, if that would make you less anxious. The WebGL shader is in plain text, so you can read that too, and verify that it matches the source code in the repo. https://github.com/SimHacker/MicropolisCore And if you can find any evidence of janky crypto mining software, you are free to report me to the FBI and Interpol and Github, since it's quite easy to identify where the software came from and track me down, as I'm publishing the source code and binary under my own name from my own Github account and domain. Here's is a great example for you to emulate of somebody helpfully reporting an issue, identifying the system they're using, and including a stack trace identifying the problem, which I was able to fix in a few minutes. https://github.com/SimHacker/MicropolisCore/issues/1 I'm glad you're so motivated to engage with the open source software community, and I hope you can write such a useful bug report yourself, and possibly even fix it yourself and submit a PR! Did you try pressing the numeric keys to control the speed? (I haven't tested it with a numeric keypad, which I don't have, so use the digits along the top of the keyboard.) If you press "1" it slows down to one frame per second with one simulator tick per frame, while "9" runs at 120 frames per second with 50 simulator ticks per frame. That runs smoothly in Chrome on my M1 Mac, and the user interface is still quite responsive. Which controls aren't working? What hardware and operating system and browser and GPU are you using, and did you see any error message printed on the browser developer console? Please include any console stack traces in your bug reports.

ner. What I'm really looking forward to doing is integrating it with visual programming languages like Snap! so you can live code it and write plug-in zones, robots, monitoring and control systems, data visualization and export (i.e. Grafana dashboards, etc), and alternative interfaces via visual programming, instead of raw non-interactive JavaScript or TypeScript! Edit for parasti: You can use a USB cable to attach an Android phone to a Mac or PC, or an iPhone to a Mac, and then use the Chrome (or Safari on Mac) browser's debugger to attach to the phone and remotely see the console messages, debug, and even live code it! It might even work over Wifi if you can get all the stars to align, if Google hasn't canceled that feature, or if Apple hasn't forbidden it in the first place.

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. //

ory Cellular Automata Music 1: https://www.youtube.com/watch?v=BBVyCpmVQew Micropolis Web is the browser based version of Micropolis (open source SimCity), that uses WebAssembly, WebGL, and SvelteKit. Based on the original SimCity Classic code, designed by Will Wright, ported by Don Hopkins. This first video has music by Juho Hietala, Blamstrain, and the Space Inventory Cellular Automata is performed by Don Hopkins. Music by Juho Hietala, Blamstrain: https://blamstrain.com/

io: https://studio.sandspiel.club/ I've written lots more about Sandspiel Studio on Twitter and Hacker News: https://twitter.com/xardox/status/1777401152260247673 >I bet you could make Sandspiel Studio compile those Blockley-based visual programs into WebAssembly or GPU shader code! But actually it might be too fast since the fun is watching the flowers grow. I taught your flower blooming code to grow potatoes too! https://studio.sandspiel.club/post/7718 https://news.ycombinator.com/item?id=34561910 https://news.ycombinator.com/item?id=36003900 https://news.ycombinator.com/item?id=38044329 https://news.ycombinator.com/item?id=38044498 https://news.ycombinator.com/item?id=39601709 https://news.ycombinator.com/item?id=38016554 https://news.ycombinator.com/item?id=33700318

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.

e 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.