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 demo shows an early version that runs the WebAssembly simulator and animates the tiles with WebGL, but most of the user interface is still a work in progress.
Live MicropolisWeb Site: https://MicropolisWeb.com
GitHub Repo with source code and documentation: https://github.com/SimHacker/MicropolisCore
Much more Info in Chaim Gingold's book, "Building SimCity": https://mitpress.mit.edu/9780262547482/building-simcity/
Chaim Gingold's "SimCity Reverse Diagrams": https://smalltalkzoo.thechm.org/users/Dan/uploads/SimCityRev...
Micropolis Web Space Inventory 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/
BTW, here's a little game that I ported to the browser. Getting it to run was very straightforward (Emscripten+SDL2 is a great combo), but honestly making it fully playable on a phone took the most effort: https://play.neverball.org/
Are we sure this isn't just some janky crypto miner in disguise?
And if it isn't, what's the point of publishing something that doesn't work?
https://www.youtube.com/watch?v=MlFu-y1LDbs
One thing I really disliked about the SNES port of SimCity Classic was how slow the interface was. Having to access the menu for everything was a pain. For my port, the cursor would move faster, and snap instantly to the next tile if it was tapped. The analog stick could be used for fast cross map movement. The menuing was replaced by mapping every command to a button combination, with different palettes of commands available depending on what shoulder buttons were pressed.
If you weren't holding a shoulder button, the ABXY buttons were set up for A (primary action button) for roads, X (secondary action) for rail, Y (the green button) for parks, and B (cancel button) for bulldozer. Holding L was reserved for system commands, you could zoom in or out with A or Y, and adjust the speed with X and B. Holding R completely would allow building zones, color coded to the controller's buttons, with the red (A) button to build residential, blue (B) for commercial, and yellow (X) for industrial. There were two more palettes, accessed by either pressing L+R, or half pressing the R button, for infrequently built things like power plants and airports. It might sound complicated from the description, but I think it would be pretty easy to get used to if you actually tried it a bit.
I did a bit more work after I made the video, like adding map overlays (pollution, traffic, etc) and a display of what the current face button palette is, to help learn the combinations.
I was also adding split screen, for multiplayer. I was planning for you to be able either build a city together with someone else, or do competitive city building, like race to clear a scenario, or get the highest population or funds in a certain amount of time. I think I got the split screen two different cameras on the same city working, but no controls for anyone besides player 1.
I spent some time optimizing the simulation, because I wanted absolute solid 60 FPS. There would be occasional 1 or 2 frame stutters on large cities went certain phases of the simulation ran. The worst was when it calculated power.
The power grid connectivity is calculated in a bizarre way. Instead of a regular, scanline based flood fill, it basically has a Logo turtle walk the power grid. It uses the exact same class that the monster uses for movement, tracking the facing of the turtle, with functions to turn, take one step forward, etc. The version of GCC I was using was not automatically inlining the movement functions (they were in .CPP files, and no LTO), so it added a ton of overhead to an already slow algorithm. I moved the functions into the header so they would be inlined, which helped a lot, but was still planning to replace the whole thing with a real flood fill.
Even after inlining the walker, there were still single frame stutters. A lot of the map data for things like pollution and land value have filters applied to them, and the filter has a slow implementation. It does X and Y bounds checking on every tap of the filter, even in the middle when it can't go out of bounds. A better filter implementation would have helped.
The C++ simulation seemed to have some kind of bug, which would cause periodic mass abandonment, that I never figured out. I never noticed the Java version having the same problem.
I just ported Quake 3 and I'm having some fun with it: https://thelongestyard.link/