Posted
by
kdawson
on Saturday January 12, 2008 @03:01PM
from the but-you-can't-call-it-that dept.

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!"

There's nothing wrong with the copy at all. This is just the open source version. To get it working:

1. Reinstall your OS, taking note of which libraries you compile into the kernel and which you merely reference as modules (this will be used later).

2. Scan all the ansi files in the download and replace references to other hardware with the.c files representing those in your own system. Re-Make the game and the installer and install it to a folder accessible by all users on your system, unless you're the only user and have a separate partition for your/usr path and wish to install there.

3. Start the game, turn off sound and network options (don't kid yourself; it's for the best) and start a new game.

4. If it runs too slowly, go back to step one and change the kernel\module mix to something more suitable.

Yes, this was an OSS troll and a superficial attempt at light humour... take a breath, count to ten, then mod me down.

There's still a lot of craptastic code in there, but the heart of the software (the simulator) hasn't changed.

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

Sim City and all the Sim games worked very well on my High Res black and white Mac Plus. When I tried the Windows versions, in colour no less, they looked and felt so cheap and amateurish (back in the DOS and Windows 3.1 days).

But from a quality-of-product point-of-view, very little could match (and can match) SimCityWell, 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]

That Microsoft would make an accommodation six years later doesn't strike me as an instance of bad coding- heck, if you present most game developers today with the choice of the "right way" or an expedient that works much better, and caution that the expedient will only work for six years, what do you think they'll pick?

Using memory after releasing it is bad coding, however you spin it. It's also bad coding even if "most game developers" would do it. It's pretty much guaranteed that even the DOS version crashed because of this: it just didn't do it everytime. So the "works for six years" excuse is probably bollocks (although if you did QA for that version too, you probably know better:)).

Lunix [encycloped...matica.com] 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.

Lunix runs on an 8-bit Commodore computer. Programs written in C or in C++ generally don't run fast on 8-bit machines, in part because C and C++ make heavy use of a data type called int, whose size varies from compiler to compiler but must be at least 16 bits.

I thought that SimCity 2000 was the best myself. I tried SimCity 3000, and while it was cool and had some awesome ideas, all the micro-managing eventually got annoying (a common flaw it seems with strategy/simulations game sequels as computers get more powerful, the Master Of Orion series also suffered from this). I want to design and lay out my city, not having to constantly run around replacing the dozens of bloody water pumps as they wear out. A close second might be SimCity for the Super Nintendo, wh

The only thing I'm missing from 4 is the government buildings-only view. Now I can't hide the tall buildings to be able to get at that subway or bus station next to it. (and in my layout I have a lot of those)

You can switch to Zone view and you'll see bus stops, subways, etc but not buildings, and you can also view different types of buildings and they get highlighted. For instance, you can click Health and all the hospitals show up bright green on the map.

My gripe about SimCity 4 was money. It was really hard to have any sort of budget that profited money for projects and expansions. (And I've played my share of SimCity). This is something that worked much better in SimCity 3000. I did however love the regions, the way the transport systems built, the better graphics, and the ability to rotate the camera as I see fit. My $.02.

The original version of SimCity was developed by Maxis on the C64, and ported to various platforms, including the Macintosh. Maxis licensed the Macintosh SimCity source code to DUX software, to port to Unix.

DUX Software contracted me (Don Hopkins) to port SimCity to Unix, and I developed "SimCity HyperLook Edition", while working at the Turing Institute on HyperLook with Arthur van Hoff. The user interface was written in PostScript, which ran on the NeWS window system on Sun workstations, and it supported multiple zoomable views, pie menus, annotating and printing maps, and many user interface improvements.

After Sun canceled NeWS, DUX Software contracted me to rewrite the HyperLook user interface in TCL/Tk for X11, and I developed a multi-player networked user interface using the X11 protocol. The TCL/Tk version of SimCity has been ported to various Unix and non-Unix platforms, including SunOS, Solaris, Irix, HP/UX, OSF/1, Quarterdeck Desqview/X, NDC X Terminals, Warp, and Linux. The contract to sell SimCity for Unix expired after ten years, so the TCL/Tk version was no longer commercially available.

OLPC SimCity is based on the TCL/Tk version of SimCity. SimCity is a trademark of Electronic Arts. Don Hopkins adapted SimCity to the OLPC, thanks to the support of John Gilmore. OLPC SimCity will be shipped with the OLPC, and it has been run through EA's quality assurance process and reviewed for integrity. EA reserves the right to review and approve any version of the game distributed under the name SimCity.

So it looks as if it's some kind of mutated version of SimCity Classic which dates back to the C64 version.

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.

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.

Seriously, reading shit like this kinda freaks me out. This is a phenomenon only found on/.. Not only does some dude go around remembering that an ancient game had problems with stuff happening left of the city center (which makes me slightly worried regarding his mental health), but someone else comes up with an answer to it (which makes me really worried about his mental health). And this isn't just some kind of "I wanna post, just to post", bullshit, kind of answer, he actually seems to know what the hell his talking about. I think I should change my thesis to discuss this, and name it "Slashdot, we're all freaks, and we have the GPL'd code to prove it".

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

I hope fires have also been removed as a result of California fires, tornadoes as a result of the Indian ocean tsunami and the big monster invasion as a result of Cmdr Taco. Other wise it wouldn't be very respectful for the victims you know.

I hope fires have also been removed as a result of California fires, tornadoes as a result of the Indian ocean tsunami and the big monster invasion as a result of Cmdr Taco. Other wise it wouldn't be very respectful for the victims you know.

Let us not forget: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.

No. This code is heavily dependent on Xlib. You could try compiling it with Cygwin and running it with one of the X servers for Windows, but word on the street is that this is unsuitable. Your best bet is to just install Linux, and run it on that.

Ditto to this. The original version of SimCity Classic for Windows technically runs, but besides not working under 64bit versions of Windows (no 16bit compatibility layer) it runs far too quickly on modern machines. It would be great to have it playable on Windows again.

(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)

Contrary to the title, this doesn't seem to be the actual SimCity source code. I'm interested in source code like this, but I want the 'original', not something that has been mashed up and modified by a middleman. This is as useful for historical insight a klingon version of the new testament.

Just download the source and unzip/untar it, put it in/tmp, download the patch that stargo put together, into the/micropolis-activity directory.

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 tha

So lets have the Lincity project absorb this project. Lincity NG is graphically on par with Simcity 2000, but its playability is lower and it misses features. Simcity 2000 was just a graphically enhanced Sincity Classic with a few playability enhancements and more structures. I see no reason why the LinCity project can't just assimilate this project, call it Super Lincity, and use the nessessary areas from Metropolis to fill its deficencies.

...this, of course, probably back before they called anything "skins".

But I remember a friend who found various themes for his Simcity -- there was an "old west" style theme, and a futuristic one and one or two others. The game itself wasn't any different, but instead of, say, gas stations, you'd have horse pastures or something.

I should probably JFGI (again), but I have tried in the past to find anything about them and have been unable.

If you're looking for a legal/legit version of the SNES version, it's 500 Wii Points on the Nintendo Wii VC.:) (that and the Internet browser are first on my list for when I get off my butt and buy a points card)

At least here in the UK, you can use a credit/debit card to buy points directly through the Wii Shop. No need to buy a points card unless you find it cheaper. Or don't have a credit/debit card, I suppose.

In the long term, Micropolis can be recast from C to C++ classes, so it's possible to define clean interfaces between software modules, and make multiple instances of the simulator that don't interfere with each other, as well as easily interfacing it to Python using the SWIG interface generator. That should be done in a language-neutral way, so you could plug the simulator engine into many different languages and programming systems. Then mo

"Micropolis can be recast from C to C++ classes, so it's possible to define clean interfaces between software modules, and make multiple instances of the simulator that don't interfere with each other"

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

``The more important question of whether or not systems like C++ and X-Windows cause actual permanent brain damage in humans, will have to wait for the autopsies of human brain doners. That won't be soon, since they're still only in the animal experimentation stages. But I think it's reprehensible how they're exposing all those poor innocent bunnies to shoddy static class libraries without garbage collection, and high doses of raw Motif.''
[From comp.lang.functional, ``Re: Effect of programming languages on thought'', Don Hopkins]

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.

C++ & Python does seem to be a weird and cumbersome choice though. But when all you have is a hammer everything looks like a nail

One person's hammer is another person's "right tool". If you read the article, it appears to me that the guy who ported the code has a clue about a few things. I'm gonna bet that his choice of Python was thought through. Likely he is leveraging some existing infrastructures that he knows, thus speeding the time-to-release. To me, that's a very handy hammer.

The code is now open. Feel free to hack onto oblivion the design choices you don't appreciate.

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.

Now, I wouldn't point to Civ IV to illustrate that using Python won't hurt performance. The reasons for the performance issues (especially before the patches) were complex, but Python didn't exactly help.

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

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.

And Python uses a form of precompilation. The first time a Python module is loaded, it's compiled into Python bytecode, and stored in a.pyc file alongside the source code. Further invocations use the bytecode. Python's bytecode compiler is blazingly fast, and that's why it's suitable for the modern 3D games listed above.

You make a statement about bytecode, then claim its blazingly fast? Granted, it is faster than an interpereted language, but its nowhere near the speed of compiled language.

While your 2 GHz processor may be more than fast enough to run Python code, it will NEVER be as fast as a compiled binary. So while your quad core processor running at 3.2GHz will run these products just fine, you will probably find that it chokes on a 133 MHz Pentium machine in Python when the original sorce, written in C, ran just fin

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.

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.

Nate man, what have you been smoking? We're talking SimCity here. You know, the game where all you need to do is build one rail square next to a building development and its transportation needs are taken care of, even if that railway leads to nowhere. It's predicated on the grid system of urban planning -- a system that was in disrepute when the game was made. COINOPS? Yeah, okay, what you need is a modded SimCity backend wired into an Armed Assault/VBS2 FPS frontend.

Think about it. The purpose of SimCity is to get a populace to like your administration, and to make the town as productive as possible.The purpose of a counter-insurgency, from the Brits in Malaysia to the Marines in Anbar, is to deny the enemy the use of the populace as cover by getting the people to want to turn them in. Sometimes it's shooting the bad guys (and making darn sure you shoot JUST the bad guys), sometimes it's building a school or making sure they get power.

Funny. When I was playing SimCity, my first reaction was what a right wing approach it took, especially with the ridiculously low limits on tax rates etc. compared to the level of taxation common in most of Europe for example.

Other people wanted to use SimCity for the less noble goal of teaching people what to think, instead of just teaching them to think.

Everyone notices the obvious built-in political bias, whatever that is. But everyone sees it from a different perspective, so nobody agrees what its real political agenda actually is. I don't think it's all that important, since SimCity's political agenda pales in comparison to the political agenda in the eye of the beholder.

Some muckety-muck architecture magazine was interviewing Will Wright about SimCity, and they asked him a question something like "which ontological urban paridigm most influenced your design of the simulator, the Exo-Hamiltonian Pattern Language Movement, or the Intra-Urban Deconstructionist Sub-Culture Hypothesis?" He replied, "I just kind of optimized for game play."

NeWS [wikipedia.org] was like AJAX, but with PostScript instead of JavaScript for programming, with PostScript instead of DHTML for rendering, and with PostScript instead of XML for data representation.

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!)

Im guessing part of the reason is that it takes time to release code in "open source"-able format... Often, commercial software is written assuming that no one else will ever need to use it, so it may very well have weird dependencies...stuff like, to compile it you need a machine named "JOESBUILDER" with a X drive mapping to some network ressource, and all that is hardcoded... internally it didnt matter, but when you open source it, that doesn't work.Cleaning up code -production code- is often not an optio