SimCity Source Code Is Now Open 360
Tolkien writes "Source code for SimCity has been released under the GPLv3. For legal reasons the open source version was renamed Micropolis, which was apparently the original working title. The OLPC will also be getting a SimCity branded version that has been QA'ed by Electronic Arts. Some very cool changes have been made by Don Hopkins, who updated and ported what is now Micropolis. (Here is an earlier Slashdot discussion kicked off by a submission Don made.) Among other things, it has been revamped from the original C to using C++ with Python. Here is the page linking all the various source code versions. Happy hacking!"
Version? (Score:5, Interesting)
I'm assuming the classic, which is a shame as I felt 2000 was one of the few times a sequel actually made the game better. Unfortunately 3000 and 4000 continued to suggest otherwise however.
Even if it's just classic however I'm sure I remember even that had some differences between platforms.
Perhaps I'm just blind but it'd be interesting to know which version this is!
Boo-hoo (Score:5, Interesting)
Win32 binary versions available? (Score:3, Interesting)
Re:The Brown Sheet of Paper (Score:3, Interesting)
(historical note- there was an early binary edit 'exploit' for SimCity that worked for bypassing the 'Brown Paper' copy protection, but as soon as you bought and installed an Expansion pack it quit working)
Re:Win32 binary versions available? (Score:2, Interesting)
Re:port to win32 (Score:3, Interesting)
Lincity Absorption (Score:5, Interesting)
Re:Craptastic Code? (Score:2, Interesting)
The Mac seemed such a natural platform for Maxis in those days.
Re:What the fuck are you talking about? (Score:5, Interesting)
Agreed. But Java isn't exactly what I'd call a scripting language. What I expect from a scripting language is the easy ability to interact with it on a command line or interactive interpretive interface (like Smalltalk). (It doesn't actually have to be interpreted, just compiled fast enough that I don't notice, like many Lisps and OpenLaszlo implement their interactive command line.) Java's problem is not just that the compilers and tools aren't set up for interactive evaluation, but also that the syntax makes it extremely tedious and required typing a lot of boilerplate structural crap. Of course there are some good interactive interpreted languages like JavaScript (Rhino), Python (Jython) and Groovy implemented in Java.
The great thing about integrating C++ modules like micropolis with Python is that you can play around with it from the keyboard, test and debug it easily, and get it to work quickly. Immediately after I compiled the micropolis module for the first time, I was able to import it, make a simulator, load a city, set the tax rate, and run the simulation loop, all from the keyboard! Then I copied that code I typed into a python file, and I had the first test framework.
-Don
Re:No, its worse (Score:5, Interesting)
The UI is quite abstract. I had to cleanly separate the UI and the simulator engine to port SimCity to NeWS, and TCL/Tk maintained that separation. The new MicropolisCore has all the UI code taken out, so all the rendering and event handing has to be implemented outside of the simulator core, in a scripting language like Python, with a graphics library like Cairo, and a user interface toolkit like GTK.
The new Micropolis core simulator engine talks to the tile engine through efficient raw memory pointers. Micropolis hands the tile engine a pointer to its tile memory and a description of the format, and a tile bitmap and a description of the tile layout (including an indirect tile map). The tile engine uses Cairo to render the tiles. Cairo is a much more advanced imaging library than SDL, and most importantly it supports Unicode and fully internationalized text via the Pango library (OLPC activities must support many different languages). Cairo enables scaling and transformation, vector graphics, anti-aliasing, clipping, SVG, etc. It is more like the PostScript based user interface to SimCity I developed for NeWS. The Cairo tile engine supports zooming into the city, and the old NeWS version used to let you play the game at any scale. Zooming is very important on the OLPC's 200 dot per inch resolution screen, because the unscaled tiles are very small, and kids like to zoom in to look closer at the city, so it's easier to see. Another reason for using Cairo is that it's great for drawing map overlays and data visualizations, with scalable vector graphics, transparency, etc. And also, Cairo is hardware accelerated on Linux, the Mac and Windows, so it can draw extremely fast and still look pretty.
-Don
Re:Finally! (Score:4, Interesting)
Hell, it's more similar to SimIsle than Simcity actually. Lincity was too much of a "everything is a consumable resource" game, which was rather silly...
I would say that Simcity 4 is the most advanced simulator I played so far, that is also playable as a game.
Though in terms of open source simulation games, nothing beats openTTD.
Re:No build on MacOS X (Score:5, Interesting)
My patch agains micropolis can be found at: http://rmdir.de/~michael/micropolis_mac-osx.patch [rmdir.de]
This patch also seems to fix graphic problems on Linux with a 24 bit X server.
Re:Version? (Score:3, Interesting)
I never found it to be a big problem.
Re:Maybe now we can finally find out (Score:4, Interesting)
Re:Craptastic Code? (Score:2, Interesting)
It's a classic type of bug (Score:3, Interesting)
It's a type of bug more common back when memory was limited. Classically, it was a spreadsheet bug. The dumb way to evaluate a spreadsheet is to start at the upper left, evaluating the formula (if any) for each cell. If any formula refers to a value that's to the right or below the cell being evaluated, the spreadsheet values will be wrong. Each time you hit the recalculate key, the values propagate through one more wrong-direction dependency. Once you've hit "recalc" enough times, the values stabilize. Unless the spreadsheet actually has a dependency loop, in which case they continue to change with every recalc.
All the early desktop spreadsheet programs (VisiCalc, etc.) used this dumb algorithm. The correct way to do it was known, but had been patented in 1969 [wikipedia.org]. It's also much more complicated to do it right; you have to build graphs, sort them by dependencies, and detect loops. It's so simple to do it with two nested FOR loops, and most of the time the complex algorithm yields the same answer as the dumb one.
Anything that has in-place updates of a grid of cells with arbitrary dependencies on other cells potentially has this problem. So it crops up in games, in image processing algorithms, and in simulations now and then.