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!"
Re:Version? (Score:2, Informative)
Re:Version? (Score:5, Informative)
Looks a lot like Classic.
Tried it, builds but doesn't work. (Score:4, Informative)
Re:Version? (Score:3, Informative)
(there is a larger version on the website but I'm trying NOT to set fire to his provider's systems)
Re:Finally! (Score:5, Informative)
Though their move is still good, and interesting just to dig into the code.
If you read the article... (Score:3, Informative)
This is actually clearly explained in one of the linked articles [donhopkins.com]:
It's stated in the article (Score:5, Informative)
It actually states the history of where it's come from in one of the linked articles [donhopkins.com] (emphasis added):
So it looks as if it's some kind of mutated version of SimCity Classic which dates back to the C64 version.
No build on MacOS X (Score:5, Informative)
Re:SNES version? (Score:3, Informative)
Re:Boo-hoo (Score:4, Informative)
Nuclear meltdown because of Chernobyl.
Earthquakes because of California, Kobe Japan, and Pakistan.
Alien Invasion because of Orson Welles war of the worlds radio broadcast.
Re:Finally! (Score:3, Informative)
Re:No, its worse (Score:5, Informative)
To clear up some confusion: The old version of SimCity/Micropolis uses TCL/Tk to implement the user interface. That is the version currently being distributed on the OLPC. The new version is rewritten in C++, and has all the TCL/Tk and user interface stuff ripped out of it. I converted it to C++ for the reasons I described in other posts (quoted above), so it is now modular and can be run through SWIG to integrate it with many different scripting languages.
But the core simulator is independent of Python, and runs extremely fast (the TCL/Tk version can run more than a year a second on the relatively slow OLPC). The OLPC uses Python as its standard system wide programming language, and all of its important libraries (like Cairo and Pango) are integrated as Python modules. So it makes the most sense to use SWIG to cast Micropolis into a Python module, first. Of course SWIG also makes it easy to integrate it with any other scripting language.
If it's not immediately obvious to you (or even if it is), why anyone would want to integrate SimCity with a scripting language, instead of just writing the whole thing in C, then you should read some of the discussions I've been having with Alan Key about that topic, on my blog [donhopkins.com].
-Don
Re:Version? (Score:2, Informative)
Re:If you read the article... (Score:5, Informative)
You can do anything in C you can do in C++, but it's a total pain in the ass. Why, you can even write a C++ compiler in C that compiles C++ into C, and call it CFront.
If you want to see what happens when you try to simulate C++ interfaces in C, then look at Microsoft's COM header files, which do exactly that.
The reasons I translated the C code to C++ were: 1) eliminate all global variables, so multiple simulators could exist simultaneously without interfering with each other, 2) define all interfaces in one place so it's easier to work with and evolve the code, 3) enable SWIG to automatically generate an object oriented wrapper for any of a large number of scripting languages, like Python, 4) Impose some sane programming conventions on the code, for reliability and readability's sake.
I hate C++ as much as anyone else does, probably more than most [google.com]. But I know when it's better to use C++ than C, and this is one of those times.
-Don
Re:Maybe now we can finally find out (Score:5, Informative)
left of the city center
Probably because they borrowed some of the code from SimAnt, which had less ant growth towards the upper left due to a processing order issue in the updating algorithm. It's one of those problems where step N+1 is computed incrementally from the current state, rather than from a frozen copy of step N.
Where's *my* pity? (Score:1, Informative)
Re:If you read the article... (Score:5, Informative)
In order to modify a C program to use structures and function pointers instead of global variables, you have to meticulously modify almost every line of code. And that is simply far too much work to do, and would be extremely tedious and error prone.
The one thing C++ is really great at, is taking a C program with global variables and global functions, and easily transforming it into a C++ class that encapsulates all the variables and functions, without disrupting every line of code. Because "this" is an implicit argument. Because member references don't have to explicitly go through "this".
But if you did that kind of a transformation on C code by hand, you would have to rewrite every function signature to take an explicit "this" argument, and rewrite every variable or function reference to go through the "this" pointer.
Actually, I really dislike GTK's Python binding mechanism. It's horribly complex, totally undocumented, and very brittle. It doesn't handle other languages, either. SWIG is a much more advanced, much easier to use tool. I also don't like GTK's "yet another object system". It accounts for most of the time spent by OLPC Sugar python applications initializing. It takes a horribly long time for GTK to initialize, and it's not Python's fault, it's GObject's fault. There's nothing worse than having several object systems, especially when some of them are slow, non-standard and difficult to work with.
Have you ever looked at or used the COM macros for generating C++ vtable layouts? It's attrocious! Actually, I really like COM for what it is (I use XPCOM at work, since we use xulrunner to implement TomTom Home), but COM's C bindings are total crap. It's much easier to use from C++ with templates, ala ATL (ActiveX Template Library), WFC (Windows Foundation Classes), etc. The MFC COM and OLE stuff is much worse, but not as bad as the C stuff.
C++ templates can't hold a candle to Common Lisp macros. C++ templates are a totally different animal, totally inferior to the macros that Lisp has had for many years. The arcane C++ syntax makes it impossible to support the kind of high level metaprogramming macros that Lisp so easily supports.
-Don
Re:Craptastic Code? (Score:4, Informative)
Well, except for the use after free bug that required a special case in Windows 95 so that the game would keep working.
See e.g. here (look for SimCity):
http://www.joelonsoftware.com/articles/APIWar.html [joelonsoftware.com]
Re:Win32 binary versions available? (Score:3, Informative)
Hide teh LUnix (Score:2, Informative)
Re:iMicropolis (Score:3, Informative)
Re:No build on MacOS X (Score:3, Informative)
In regards to patching the files...
Just download the source and unzip/untar it, put it in
Then execute the patch command, like this for example: patch < micropolis_mac-osx.patch. The the paths are off, it will ask you what file to patch, take a look at the "diff" line and simply supply the file name from there, for example (src/tclx/ossupp/makefile), or whatever the right path is for you to that file.
Then run make from the src directory (assuming you have the developer tools installed of course).
Then, assuming it compiled with no errors, run make install (you don't need to be root to do any of this by the way).
Then launch X11 (assuming you have it installed of course) and from the top level directory run
Works great so far!
Re:Craptastic Code? (Score:3, Informative)
Re:Craptastic Code? (Score:5, Informative)