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

That steam stutter bug, and tracking it down…

Right from it’s initial launch on steam, there was a bug reported in Gratuitous Tank Battles for a tiny subset of steam players. The bug was basically that the game ran horribly slowly, with stuttering and skipping music.

Regular blog readers will know I am a bit obsessive about optimisation, so naturally this seemed weird to me. Right from the start I doubted that this was actually the games graphics engine or core gameplay code running slow. Not given the specs of the users reporting it, which was a wide cross-section of hardware types. Happily, this was confirmed by the realisation that running the game from the .exe, outside of steam, enabled it to run perfectly. A good workaround, but not actually a fix.

This was followed by weeks, maybe even months of me investigating what on earth it could be.

Initially, I assumed it must be something about the steam integration code. So that resulted in a ton of going through it with a fine tooth comb and checking every parameter, asking valve if I was doing it right, checking with other devs how I was doing it compared with them etc. I ended up moving the code that initialised steams systems from one point in my code to another, as they recommended, but there was no change. I also changed a callback to run every 100 frames rather than every frame, and again, no difference.

Then, finally we found some helpful players who not only had the bug, but were happy to run diagnostic code on their PC for valve to analyze. A very helpful guy from valve then crunched through it, and found that an alarming amount of time was spent in the sound library, and in Heapvalidate(), called from it. This then led to another 48 hours of me looking at heap validation code, memory errors, installing xperf, the application verifier, trying (and failing) to download Microsoft platform SDKs, lots more poking and prodding…

and then eventually  I got a reply from the sound library people suggesting that yes, it *might* be their code occasionally calling HeapValidate() all the time, and to upgrade to the latest build.

So I did that and it has fixed it…(afaik)

How annoying. The one piece of code in the game not written by me, and it had a bug in it! At least it’s fixed now, so all is well. I bet my code has bugs too :D We still don’t know why it was actually caused by the interaction of the game with steam, but that just seemed to be the randomish trigger for the errant memory checking.

I have a new ninja PC on order. I dread re-installing anything. Is there a magic new way to do this, or will I sit there downloading and installing stuff for 2 or 3 days again?

Another Gratuitous Tank Battles patch!

So… I’ve released version 1.014 of GTB. It has some under-the-hood changes nobody will notice (yet) but also this:

1) Added hint to make divisions if you have lots of units and have not created any yet.
2) Changed the way unit icons are created so they make more sense for long-barrelled guns.
3) Added new option to allow the game to auto-manage and update divisions for each type of unit.
4) Fixed bug where if you didn't restart the game, you kept unlocking the same unit.
5) Added support for colorblind mode.

The big change there is 3). I wish I’d thought of this originally, but like all my games, they evolve and improve in response to player feedback. The game will now automanage and keep up-to-date a separate division for infantry, vehicles, buildings and support structures/vehicles, and you can swap between them as before using tab or alt+tab.

because I’ve added this *now*, it’s not the default, and you need to go into the division manager and turn it on. if I was more organised, I’d be tracking that as a stat. The trouble is,¬† you get a lot of people buying games cheap in a sale who play 2 levels, then never return, which is bad for all kinds of reasons (it encourages designing purely for the casual gamer, for one), so ideally I’d be tracking people who play 10+ missions, and then analyzing what percentage of them even use divisions, and how many of them enable auto-management. My stats tracking sucks, yet again. I’ll get it right in my 99th game, I promise!

4) was also an embarrasing bug that I wanted to fix, and is the main reason I suddenly rushed this update out without much fanfare.

In other news, I’ve been working on some future stuff (early days yet) and also re-uploading a bunch of ‘signed’ exes to keep the paranoid gremlins at Norton Internet Security happy (god knows why).

The steam sale was pretty good, but not wallet-burstingly so. We do live in strange times. As a game designer, I’d prefer less, high-margin sales than a whole slew of people grabbing GTB for cheap and hardly playing it. I’m definitely from the hardcore gaming school, rather than the ‘angry-birds’ school of gaming, and I hate to see gaming change to the point where everyone owns hundreds of games, but has played hardly any of them. That’s not a market working properly, it’s like a weird mind game.

It’s amazingly sunny right now in the UK. I know because my solar power readout tells me. Obviously I’ve never gone outdoors. That would be mad.

Gratuitous Tank Battles updated to 1.013

Here are the patch highlights:

  1. Lots more explanation and detail in the various tooltips
  2. Minimap now has a popup explanatory key
  3. mini-design icons now displayed on the design screens loading dialog
  4. Unlock system now ensures important unlocks come first
  5. Changes to armor color so it doesn’t confuse people with damage.
  6. Fixed various bugs
  7. You can now reinforce infantry by dropping new troops onto the top of existing ones where there are gaps.
  8. You can turn off the supplies siren now

Hope that meets with everyone’s approval :D