Monthly Archives: February 2003

SimCity 4

Posted on by

When I was at Fry’s on Thursday, I also picked up a copy of SimCity 4.  This was, perhaps, not the best idea I’ve ever had.  Why?  Because I get involved in resource management games.  I played Civilization II for over two years.  Railroad Tycoon II lasted at least that long.  Sure, I got annoyed with both games, but it took a long time for me to get tired of playing them.  SimCity 4 looks like it might keep me entertained for much longer than that.

I guess I’ve logged 10 or 12 hours playing with the game since Friday night.  At the moment, I’m pretty impressed.  The basic idea is easy enough:  you’re the mayor and it’s up to you to make the city grow.  You have to make it a place where people will want to live, make sure there’s enough power, police presence, fire protection, schools, and other infrastructure so that the city will prosper.  You have a limited budget, so you can’t just throw money at the problem (although you have to do that at the beginning).  After a few false starts, I finally got a working city (more of a town, actually, at the moment) whose budget is in the black.  There’s a lot to do in the game.  I had resisted the earlier SimCity versions because I was afraid I’d get stuck micro-managing every little part of city life in the same way that Civilization II and Raliroad Tycoon II make you micro-manage everything.  In SimCity, although you have the ability to micro-manage every little detail, it looks like you don’t have to do that if you don’t want to.  You can set funding levels for individual items like schools and medical clinics, and things “just work”.  As the city grows, one of the game’s automated advisors will let you know if a service’s funding level needs to be adjusted.  So far, the micro-management doesn’t seem onerous, but again I’m just starting with the game.

In addition to individual cities, SimCity 4 also includes regions.  You’re given a map of the region, which is carved up into rectangular city-sized blocks.  You can create a city in each block, and form trading deals between the cities.  Apparently you can create a network of interdependent cities within a region, but the documentation is kind of sketchy in that area and I haven’t tried building an adjoining city to test it out.  I can see where region play would add a completely new dimension to the game.

My only gripes at the moment are performance.  The minimum system requirement is a 500 MHz Pentium with 128 MB of RAM and a 16 MB DirectX compatible video card.  The recommended configuration is a 1 GHz machine with 256 MB and a 32 MB Direct3D compatible video card.  My machine falls right in the middle there, and response time is a bit sluggish.  I figured I could turn down some of the graphics options (disable cloud and fog effects, for example) to save a few cycles.  That works, except that doing so ends up causing some really annoying rendering bugs—large portions of the screen go black, or get drawn with a bright green background.  The rendering bugs are way more annoying than the sluggish UI response.

My initial response to the game is very favorable.  I’ll report back here after I’ve had a bit more time to play with it.

Snow in central Texas?

Posted on by

Can you believe it snowed here over night?  When Debra got up this morning, there was a good solid quarter inch on the ground in some places.  I got my pictures around noon.  A light mist was falling and much of the snow had melted, but you can see that there’s still a good covering in some places.  The last time I saw snow here was six years ago, and I don’t think it was quite this much.

The weather around here plays havoc with our peach tree.  With the warm spell we had a few weeks ago, the peach tree got confused and started budding.  Combined with the last few days of freezing, today’s snow probably ruined any chance we have of harvesting peaches this year.  I think the person who planted the peach tree (the previous owner) didn’t know to check the chilling hours requirement when selecting a fruit tree.

A new KVM switch

Posted on by

I went to Fry’s today to pick up a USB cable for Debra’s new printer.  I walked out with the USB cable and a LinkSys 4-port KVM switch (model PS2KVM4).  I finally got tired of having two big monitors and keyboards on my table, and continually banging my knee against the diagonal support when  I’d scoot over to work on the other machine.  I should have done this 3 years ago when I got this new computer and was using the other for writing the Kylix book.  This thing will save me a lot of frustration.

I’ve had KVM switches before—the manual kind—that were very unreliable.  It seemed that more often than not, at least one of the ports would fail to switch well, and I’d lose my keyboard or mouse connectivity on one of the computers.  This digital switch is much nicer:  I can switch computers by pressing a button on the front of the switch, or by using hot keys.  Pressing Alt, Control, Shift, 2, Enter (in sequence, not all at the same time) will switch to the second computer.  Very nice.  And since I got the 4-port model, I can plug in my Linux server that I’ve been monitoring with SSH and still have a port left over, perhaps for a laptop if I ever decide to get one.

My only gripe is that there’s some ghosting on my monitor, especially in 1600×1200 mode, but it’s also noticeable at 1280×1024.  Hopefully I can fix that by getting some shielded monitor cables.  [Note 02/07:  Yes, shielded monitor cables solved the problem.]

Now what to do with all that extra space?

Web services for interoperability

Posted on by

The other unattainable goal (other than “thin client”) that Web services just might finally put to rest is the wrong-headed insistence on portable code.  The idea of write once, run anywhere is no closer to reality today than it was when the first COBOL compiler was developed 40 years ago.  It’s another one of those things that looks nice on paper but can’t possibly be implemented.  Why?  Because differing hardware capabilities, feature sets, and user interface customs result in code being written to the lowest common denominator.  The resulting applications usually end up being portable…and irrelevant.  Or the programs are so full of special cases and conditionally compiled code that they really aren’t portable, but rather separate programs that just happen to share some common functionality.  All too often, the goal of portability is met at the cost of functionality and maintainability.

Portable code is not the answer to the problem of interoperability.  The answer lies in defining a simple and flexible method for applications to share data.  From where I sit, it looks like Web services are currently our best bet.