Ari Rahikkala

Farms do pay taxes with RH, but not much. Remember, I-Ag demand doesn't mean "your city needs agricultural industry in order to grow", it means "if you zone farmland in a suitable place, it's likely someone will found a farm there". It might be a good idea to build a decent amount of farmland early on to get the farmer's market for its various benefits: It busts the mid-wealth residential demand cap a lot, it's a *very* nice residential YIMBY, it even has a health effect (which is extremely tiny, though). Thing is, in my games I always had to zone enormous amounts of farmland to get the requisite farming jobs... and since even farmland has a cost, I'm afraid that in terms of investment it would have been better to just build some parks. Still, if you're going to build farms anyway for any reason, the farmer's market is an excellent early reward. (the state fair, on the other hand, is... not so excellent ).

Fundamentally, if you're happy with weak and inconsistent game features, and maybe a slight decrease in performance, it's quite simple to restrict the simulation to an arbitrarily shaped area. It doesn't even take much memory - in fact, at the simplest, one bit in the map array (i.e. one bit per tile), to tell whether you're allowed to modify that tile or not, suffices. You'd probably actually want something more like a byte to actually tell which region the tile belongs to, though, but I'm getting ahead of myself. Most of the simulation would remain easy to code. The actual rendered area would be best kept square or at least rectangular to make playing near the edge of your playable area look nicer. This means that the visible area would be larger than the playable area. So as you see, while there are technical hurdles to playing irregularly-shaped maps, they're a lot more complex than the ones mentioned so far in this thread, and they're intertwined with concerns of economy (of Maxis), user interface and game rules. It's not that it's impossible, it's that adding this feature would have been a rather unwise decision. Note that with "unwise" I don't mean "obviously wrong", only that a company like Maxis wants to play it safe with their cash cow and not introduce too many changes which might have unexpected consequences. Especially not changes that, like this, would have to be made very early on in development due to the way they affect everything in the design and code. SimCity 4's mechanics of city interaction are, to be honest, rather weak. Pollution doesn't pass city borders, commuters can path from one city to another but tend to lose a lot of their (already rather limited intelligence) when they do that, and of course there's the whole matter of cities staying in a frozen state when you're not playing them (which allows you to do things like use one as a garbage dump for hundreds of years for a pittance). The game itself remains quite compelling, though, as you can largely ignore these issues: Either ignore the problem with pollution or handle it in whatever way you find most compelling (don't pollute at city borders? Match up industrial areas with industrial areas, etc.?), don't create traffic networks with features like commuters having to pass through another city to get to their job (well, that's a good idea even in real life...), don't abuse the city-freezing rule, etc.. With irregularly-shaped cities, all of these issues become.. a lot more complicated. First and foremost, do you run the simulation in the entire visible area or just the playable area? If the former, how do you reconcile the changes occurring in the simulation to the other cities in the visible area once you switch to playing one of them? If a disaster strikes or spreads to the other city, who foots the rebuilding bill? What happens at the edge of the visible map anyway (this is equivalent to the question of what happens at the edge of the map in SC4, only even more difficult to answer)? If you choose to run the simulation in just the playable area, on the other hand... how do you handle traffic that might go through another city in the visible area? How do you handle the disparity in the development of the visible areas? Do kids get to walk over the border to the school that's plainly visible five meters away? (and if you decide after reading that paragraph that it would be a good idea to have the visible area == the playable area... well, now you still have the same problems with city interaction as SC4 does, only they're more complex now especially since you might have situations where the best choice to route traffic around your city *would* be through another city. Oh, and screenshots at the edges of cities start looking really weird.) That's not even considering the issues that actually arise when you consider actual map editing at city borders. Do you allow the player to raise and lower land behind a city's border? If not, you end up either completely unable to affect land height at a city's border (which will, due to the inflexibility of the smoothing feature, cause problems when you try to add traffic connections - how many times have you had to demolish an object that fixed its tile's height just to connect a street to an adjacent tile?)... or, alternatively, with a situation analogous to SC4's: You can pile up land or dig a hole on your side of the border but it doesn't affect the other side at all unless you click on reconcile edges when you go to the other side (and considering how buggy this feature is, using it with irregularly-shaped cities would probably end up demolishing the whole city). If you do allow the player to do it, well, that's a whole other can of worms to open.. Of course, we have a lot of people here on this forum who try to make their cities look realistic even at city borders. I can appreciate that they'd love this feature, especially if the visible area were larger than the playable area, as they could deal with all of the infelicities caused by the feature and be helped by seeing the other side of the border they're working on. Cliff's notes: It could have been done. It'd have dozens of possibly negative consequences, and maybe one or two positive consequences, that only the kind of people who post on simtropolis.com would appreciate anyway.

Heh, well, this is... interesting. If the treasury were -2147483648 or something close to it, it would be obvious what happened: The city made too much money and wound up overflowing the money variable. The problem is, that would only work if said variable were a 33-bit one, which does not really sound likely... hm... maybe it's stored with 64 bits but is handled as a 32-bit one (i.e. only the lower half is handled) in some parts of the code... though I'm still not sure how this would cause an overflow to the upper half.