Game Design, Programming and running a one-man games business…

The mental coding stack, and avoiding interruptions

I was coding something in G4 recently, and it was in theory a simple thing. I was trying to work out why a certain unit in my game was not opening fire on another unit when I knew it should be.

When I was looking at the unit onscreen, it was one of several, and stepping through code is frustrating if you aren’t sure who is who. The best solution in this case was for me to overlay a range UI on the screen so I could check it wasn’t a range issue. That meant writing some new code to display the range UI, which is fine. The problem is that meant getting the range for that unit into the GUI code, and there was no simple way to do that yet. That meant writing some new code to make a note of the range for that unit elsewhere…

In an office, this is normally the point where someone taps you on the shoulder or asks you a question… And then it all falls apart. At this point my mental ‘stack’ is this:

Working on G4
...Debugging the firing bug
...Adding a range overlay
...Writing code to access max range

The longer that list gets, the longer it takes to get back into what you are doing. With really bad bugs (I coded a neural newtork once…eeeek) you can be 10-15 layers in. It can take a good 15 minutes to mentally rebuild that stack accurately if it gets lost, and it *will* get lost the moment you lose your train of thought.

Short summary: Make sure nobody interrupts you when you are coding.

we aren’t in autoexec.bat any more toto…

Because I didn’t make it very fluid, I get an email maybe twice or three times a week about someone who had problems installing an expansion pack for GSB if they bought the base game from stardock or steam. The solution is easy, you need to browse to the place where the base game is installed during the installation. It had not occured to me, when setting things up, that this would be a big deal, but a non-trivial proportion of buyers don’t realise it, and they need me to walk them through it, which is fine.

Obviously I made a mental note to ensure that sort of problem will never arise with future games.

What really strikes me though, is how far we have come from the days of my gaming youth. Go back far enough and the boot-up ‘welcome’ screen on my first computer was this:

You were expecting icons maybe? or perhaps a graphic? or any way to actually launch programs or do anything? Unless you were lucky and had money to buy software, you would actually have to type in the code for each game (the whole program) from a magazine. The operating system was pretty much just a way to support the typing of characters on the screen. No danger of antitrust legislation for bundled apps there…

Fast forward through my days as a rock star and boatbuilder (long story) and I got an IBM 386. These were the days of playing X-wing. Now you might think it’s a pain to get the right drivers these days to run crysis, but back then, you had to literally reconfigure the structure of your RAM in order to run a game. People my age will get a cold sweat remembering autoexec.bat and config.sys, the two dreaded files that between them enabled you to balance your memory allocations just right to get that extra 16k needed to boot up SimCity.

The thing that really strikes me, is that re-configuring autoexec.bat and config.sys was so arcane, so complex, and so fiddly, and geeky, that not only was it much much harder than any problems current PC gamers have to deal with, but it was actually harder than most games. I may have got frustrated with constant deaths when storming the beaches in Medal of Honor, but that was NOTHING compared with the challenges presented by emm386.

As game developers, often geeky ones who are older than a chunk of our audience, we need to constantly remind ourselves that there is a huge swathe of people who never struggled with this crap. To them, sadly, the PC is just like a toaster or microwave. You press the button and then it does stuff. If it doesn’t. you complain to the manufacturer. Sadly, I suspect the nation of geeks and tinkerers we had in the 1980s has become a nation of passive consumers. Understandable, maybe inevitable, but maybe also slightly sad?

Maxxing out the PC

When you are running a new PC game, what percentage of your PC is actually working to produce the experience?

Obviously it depends massively on the game, the specs of your PC, your monitor resolution and other factors, but even in extreme cases I suspect it is pitifully small.

The most obvious under utilisation is the CPU. Most games still run in 1 thread, maybe 2 or 3 if there is some sound streaming, possibly more if they are ambitiously attempting multithreaded streaming in of textured data, and maybe a few more for online play. I don’t think that there are many games that will happily place 8 different threads on the 8 cores of my machine (quad core, but hyperthreaded, so showing up as 8). I can max out the CPU by rendering in a 3d package, or by compiling in visual studio, but I’ve yet to see a game manage it. I can understand why, mutlithreaded code is a bitch.

(One problem is, we don’t have exclusive access to all those cores anyway. Right now, this laptop has 53 processes running 715 threads. There are 17,000 handles open (mostly files, one assumes). All I’m doing is typing in firefox)

The second missed opportunity is hard disk access. Go to windows task manager, performance, then check out the resource monitor. Check out all that disk access. Who is doing that? and what for? You can bet that even during a gaming session, a dozen other apps and ‘services’ will be spamming your disk drive.

Of course the same goes for memory, and access to peripherals, the network yada yada.

It makes you wonder just how jaw droppingly awesome a PC game could be if it didn’t have all that nonsense going on all the time. Imagine a special ‘gamer’ mode of windows 8/9 that effectively locked out all those other services, clawed back all the RAM and the cpu cycles, and let your game have console style complete control.

A pipe dream, of course, because of backwards compatibility and a million other reasons, but I do find myself wondering what percentage of my PC is actually needed to play Battlefield:Bad Company 2.  Is it 5%? 7%? certainly not much more?

Ho! Ho! Doh!

There was a bug in Gratuitous Space Battles: Galactic Conquest until today. It was a bit obscure, and very baffling. Basically, in seemingly random circumstances, regardless of file version, people would develop a bug where the campaign backdrop was just plain white. I could not reproduce this. Re-installing seemed to fix it, for *some* people.

Anyway, someone noticed when I asked about it, that a line in campaign.txt storing the background texture name was missing. They had the latest version, and I KNEW that line was in there. It made no sense. Then they noticed that they could paste that line in, when the game was running, and voila, it worked. How weird.

So I looked at my code, and sure enough found some code which overwrites campaign.txt. Old, boring, unused, debug code for doing the campaign editing from about three months ago. This was before that file had this line in it, so because that code had never been updated, it meant that whenever it ran, and  saved out campaign.txt, it overwrote it with a new copy that had no data for the background texture (it used to be hard coded).

What a dork.

But even worse, I had left in this debug code mapped to the ‘H’ key (S was in use), and never remembered to remove it. So if anyone ever pressed ‘H’ during the campaign, it ran.

What a huge dork.

Anyway, it’s gone now. The bad news is, I am obviously a clueless muppet who could not code his way out of a paper bag. The good news is, I fixed this on Christmas Eve. Hurrah! It’s in patch 1.54, you will get it today / tomorrow.

Happy Christmas / Holidays / Festivus / Ascension of Kahless day to everbody!

Quick bug / code update

version 1.51 is live. This does the following:

version 1.51
1) [campaign] Fixed exploit where you get 1 crew when you scrap a fighter.
2) Added new order 'Last Stand' which overrides the auto-behavior of ships retreating if all of their weapons are destroyed.
3) [campaign] Some difficulty balance changes.

it MAY be causing a bit of a crash. I just spotted it, when looking into something else (typical). I’m working on a  quick 1.52 now. It should only happen if you capture enemy fighters, i think, and it s a popup message you can click ignore to, anyway. Ironically, it’s a pop-up message helping me find a rare bug, that I still can’t find :(

Anyway… I have fixed a bug where fleets dissapear on retreating if you viewed the post-battle stats. that will be in 1.52 as well. Plus, I’m working RIGHT NOW on a fix for a retreat related crash bug. I think it’s caused by retreating with a fleet where there is a friendly planet to retreat to, but your ships cannot move there due to anomalies. It should be fixed in 1.52 as well.

The sheer tonnage of code in GSB is staggering.

I hope I get this bug squashed before the apprentice is on :D BAGGS THE BRAND!