Sunday, 09 February, 2003

SimCity 4

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.

Saturday, 08 February, 2003

Snow in Central Texas?

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.

Thursday, 06 February, 2003

A New KVM Switch

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 1600x1200 mode, but it's also noticeable at 1280x1024.  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?

Monday, 03 February, 2003

Web Services for Interoperability

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.

Saturday, 01 February, 2003

Columbia Reactions

Debra and I were driving up to the little town of Salado to spend our 12th anniversary wandering around the shops and just enjoying each other's company.  Turning on the local NPR station, as we often do on Saturday mornings, we heard them talking about some kind of accident.  A few minutes later we just stared at each other, unbelieving.  Initial reports had debris landing near the town of Athens, about 2-1/2 hours from here where we had visited a friend about 18 months ago.  And we were heading that way.

We listened to the reports on our way to Salado, and then tried to put it out of our minds as we browsed the antiques stores and tourist shops, enjoying the fine weather and spending time together.  Periodically we'd walk into a store that had the report on, but mostly we tried to ignore it for the day.  Plenty of time to think of those things later.

Our prayers are with the families and friends of the astronauts.  Please know that Debra and I share in your grief for the loss of your loved ones.