The Programmer's Dilemma

It's been a long while since I did any coding in the Linux kernel.  I was never a contributor to the kernel.  I never pushed any patches.  I did, however, enjoy the simple changes I made to the code that I ran on my sandbox server.  This was way back around the 0.99 days.  These journeys into the Linux kernel were brought on mostly for "academic exercise" while brute-forcing through my operating systems class in college many years ago.  I was successful at building that kernel.  It loaded with the simple boot loader that I wrote in assembly language and C.  I put a notch on my keyboard and checked off two items on my nerdy bucket list.  I never got more involved in kernel programming beyond these initial steps.

As you might know from previous posts, I am not a professional programmer any longer.  That was many many years ago.  When I switched from programming to systems administration I found that, over the years, my programming skills began to fade.  At one point I was rather good at C and was growing more functionally competent with C++.  Occasionally I would sit back and wish that I had stayed with programming.

When I started getting back into programming I found that, although going back to basics wasn't entirely necessary, I needed a refresher in how certain things worked.  Pointers had become rusty and function references were now as foreign to me as the surface of Mars.  I took to task going over each and every page of the C++ Reference which served as an excellent catch up tool.

I then jumped head first into the waters of game engine design.  And drowned almost immediately.

I had forgotten Rule 1 of learning programming.  Stay in the shallows until you learn to swim.

As much as I wanted to write my pet project game engine I realized that I absolutely had to start smaller.  The years away from formal programming had taken their toll and I was no longer able to "think like a programmer".

Troubleshooting Gnomoria

As you might have read from my earlier post about my favorite games, I have a fondness for Dwarf Fortress.  Gnomoria (available on Steam) is a game about gnomes who, much like the dwarves, start out with a cart and some dreams.  Gnomoria takes the Dwarf Fortress idea and simplifies it (greatly) and leaves us with a more managable "city" builder game.

Our intrepid dwarves gnomes take to task building farms, harvesting wood, and digging holes in the ground (across multiple z-levels).  Unlike DF, G comes with some rather nice graphics.  Personally I like the ASCII of DF though I also run with the Phoebus tileset, but that's a story for another time.

Anyway, I have played Gnomoria on occasion for several hours a go.

One day I did some cleaning up of my system.  I got rid of everything that was old and stale.

And when I reinstalled Gnomoria recently I found that it wouldn't start.  It launched and crashed almost immediately.  No logs, no dialog box, no anything that might give some clue as to what was going on.  Even the Internet was quiet about this.  Not surprising since Gnomoria has now gone to version 1.0 and no longer supported.  Or, rather, that's what it seems.

I was determined to fix this issue.  Since I knew I had just cleaned up a lot of old junk, perhaps that had something to do with it.  So I dusted off my old hat from my days as a tech support desk jockey and dove headfirst into the problem.

First things first.  I looked at the Gnomoria directory in the Steam install path.  No logs.  Nothing really except the game files.  Everything looked to be in order.

And then I saw it.  A folder named "XNA".  Wait a minute.  Was this game written (at least in part) using the now defunct Microsoft XNA Game Studio?  There in the folder was the .msi file to install the XNA redistributable.

These redistributables are essentially library files that contain the shared data that were used to create the game.  You see, a programmer can set their program to link as a static or dynamic executable.  Since static builds are generally larger than dynamically linked, we oftentimes will build our projects as dynamic.  Doing so leaves us a smaller distributable archive and requires the end user (the gamer) to already have (or willing to download) the dynamic libraries that we used during build time.

For convenience, Gnomoria included the installer for the XNA libraries.

I already had the latest XNA redistributable installed from my days of tinkering with XNA Game Studio.  During my cleanup, I removed it since I no longer was testing the XNA waters (and also since Microsoft killed it).

So I grabbed the latest XNA redist from Microsoft, installed, and Gnomoria is running once again.