Category: programming

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?

This is much better explained through video so here goes…

There are a bunch of things that could be added to Gratuitous Tank Battles, all of which takes time, and lots of tweaking and balancing, and may or may not add to the gameplay. My pet idea is a ‘safe zone’ extending some distance behind heavy tanks, which gave infantry in that area a cover bonus against fire. Theoretically easy, but might it look a little weird? if there is obviously clear line-of-sight from enemy turret to infantry, how can I justify the bonus?

One thing that I have started on, because it was bugging me, is improving the defensive AI. A lot of people have been complimentary about the AI in GTB, which is very nice, as I am, in my heart a bit of an AI coder, but I see so many battles when the AI does dumb things. The two dumb things that really bugged me (but NOBODY has mentioned it) were as follows:

The Ai building turrets next to attacking units, rather than ahead of them, so they don’t stride past during construction

The AI not effectively demolishing and rebuilding units in the last minute or so of battle

The first problem is hopefully now fixed (The second has always been coded, but obviously needs more work), but it’s actually one of those coding problems that annoys AI people, because management will never understand the complexity (and think you are crap/slacking). In theory, the solution is simple – Don’t analyze the path next to each potential unit-build location, analyze the paths that are 5-10 path tiles ahead of them, so you can know what will be in range when a unit is built, rather than right now. Easy, job done, 10 minutes!

But in practice much harder. There are maps with branching paths, and worse, some with paths that flip back between two tiles (making for some interesting recursive gotchas), so that means that identifying which path squares to keep an eye on and calculate ‘urgency’ for becomes a bit of a pain. It’s also horrendously slow, but thankfully way way faster in release build, and only happens on map load anyway. (Theoretically it could be saved out and rebuilt only on edits, but it turned out to be fast enough not to bother). To code all that, test it, optimise it and debug it (with a debug overlay to check it worked) , took the best part of a day, but I think it’s worth doing.

So today, one thing on the list is the demolishing/endgame stuff for the defensive AI. No reviewer has yet criticised the AI for the game, but I guess I should be aiming at them praising it, and hopefully I’m nudging in that direction.

So I’ve finally released patch 1.005 for Gratuitous Tank Battles, and I’ve been trying to get a patch a week released between beta and eventual final release. This patch might seem to have less stuff than the last, mostly due to one of the items taking a lot of re-working.

Here is a forum thread showing the full changelist:

http://positech.co.uk/forums/phpBB3/viewtopic.php?f=32&t=7210

And here are the highlights:

There is now a direct association between the flames and damage textures on a unit, and it’s current state of health, rather than the semi-random system there seemed to be before! That means that a unit that looks undamaged probably is (although shields and armor may be reduced), and a unit with several plumes of smoke streaming from it is probably in trouble. Of course, for player-units toggling ‘H’ or the health button will let you see the details (or select that unit). This took a lot of fairly tedious re-jigging.

On a similar note, shields now flicker in a strobey-way if they are below 33%. You probably won’t notice on units without big chunky shields, because once down to 33%, they are probably under attack and close to failure, but hopefully this makes things a bit clearer.

There is a gratuitous new visual effect for laser guidance. Previously, those red laser beams were on a lot of units, mostly mechs, semi-randomly. Now, they only appear if that unit is equipped with the top (VI) targeting system. They also swish across and illuminate some smoke, and pulse a bit and generally look pretty cool at night. Expect to see less of them, but for them to look better :D

There is a new campaign map (Tanks for the memories!) added at the end of the campaign. It’s another evening map, this time very trench-heavy, hopefully you will all enjoy it :D

There are some changes and improvements to the explosions, after a LOT of work on the explosion editor. I expect them to be better still in the next patch, now I have seriously tided up my particle & explosion editing code!

Enjoy the new version, and as usual, anyone pre-ordering the game right now gets the very latest version automagically (you won’t need a patch). Don’t forget to tell friends, family members and total strangers if you have played the game and enjoy it, it’s all much appreciated. There is an official patch 1.005 comments thread here:

http://positech.co.uk/forums/phpBB3/viewtopic.php?f=32&t=7225