Slashdot Mirror
SimCity Source Code Is Now Open
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!"
... a big scream was heard, as if a thousand hours had suddenly been lost.
I dunno, from the QA side in 88/89, the results were darn clean. The simulation would crash from time to time, but the interface, never. To all those who point to multi-threaded apps and say it's too hard for coders to do, I'd suggest that really good programmers are hard to come by.
So maybe somebody can point to what's being complained about here. Back in the day, we didn't have the luxury of infinite space for code and variables. But from a quality-of-product point-of-view, very little could match (and can match) SimCity
I can't see anywhere stating the obvious, what version is it? Simcity classic, 2000? 3000? 4000?
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!
why it is that commercial zones placed more than a certain distance to the left of the city center never developed. I wonder if it was some kind of subtle political commentary on how leftist policy hurts business or something.
Luckily we already have much more advanced clones on Linux than the old original whose code has been opened.
Though their move is still good, and interesting just to dig into the code.
Why all the effort to port to C++ ? C rocks !
It needed to be updated, because it ran too fast on modern hardware.
It actually states the history of where it's come from in one of the linked articles (emphasis added):
So it looks as if it's some kind of mutated version of SimCity Classic which dates back to the C64 version.
That's amazing. It would be very nice if the code of other titles were released also. Many old (but good) softwares were forgoten because their sources were not available to maintain it's life.
Your post shows a deep lack of understanding of how and where Python is used, and for what purposes. As an example, Civilzation IV is written partially in Python (the user interface, as I recall), and EVE Online has a significant portion written in Python as well. Considering that a lot of what Python does is I/O bound, and a lot more can be done in outside libraries (e.g. DirectX), using Python in game development can make things a lot easier, and a lot easier to modify down the road.
Put aside your prejudices and you may actually learn something.
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.
-Don
Take a look and feel free: http://www.PieMenu.com
It's official, the terrorists have won.
The original SimCity code written in C ran just fine of an 8 bit 1.02 MHz 6510. And I've optimized to run even more efficiently since then. So worrying about Python slowing SimCity down is totally lacking in perspective -- penny wise but pound foolish. SimCity is already many orders of magnitude faster than it needs to be. Anyway, the core simulator is written in C, so Python doesn't slow it down at all. You should learn more about Python programming, developing Python modules in C and C++, and using SWIG for integrating Python and native code, and using Python as an embedded application extension language, before "making such [...] comments".
Using Python drastically speeds up the software development process, which is a great thing when software developer's time is so expensive, and computers are so fast. Python is also is a much easier language for kids to read, learn and program -- and the OLPC is an educational project, not a laptop project.
-Don
Take a look and feel free: http://www.PieMenu.com
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. But I know when it's better to use C++ than C, and this is one of those times.
-Don
Take a look and feel free: http://www.PieMenu.com
From Designing User Interfaces to Simulation Games, a summary of Will Wright's talk to Terry Winnograd's User Interface Class at Stanford, in 1996.:
-Don
Take a look and feel free: http://www.PieMenu.com
Yes, it'll be great to port Micropolis (SimCity) to embedded devices! I'd like to port it to the TomTom, and hook it up so you can operate the bulldozer or road building tool via GPS, just by driving around!
-Don
(Disclaimer: I work for TomTom, and this should NOT be interpreted as a product announcement!)
Take a look and feel free: http://www.PieMenu.com
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
Take a look and feel free: http://www.PieMenu.com
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
Take a look and feel free: http://www.PieMenu.com
What the hell is this Lunix thing that so many keep talking about?
Lunix is one of the most powerful contraceptives evar ....It is an operating system that was the result of really crappy reverse-engineering efforts to create a free version of UNIX. Linus Torvalds and Alan Cox are the perpetrators behind this travesty. Tons of people use it, especially hippies, and no one really likes it except the terminally uncool. Most of them use it in violation of SCO's intellectual property rights. To use Lunix legally, one must pay a $699 license fee to SCO for each processor that runs the Lunix kernel.
I, for one, would like to welcome Don Hopkins: our sim-hacking overlord.
==================
Hippie Logger Jock
==================
Success :-)
My patch agains micropolis can be found at: http://rmdir.de/~michael/micropolis_mac-osx.patch
This patch also seems to fix graphic problems on Linux with a 24 bit X server.
// MD_Update(&m,buf,j);