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.

Frustrating case woes.

I have a nice made-to-measure desk that has a fake-drawers cupboard to put a PC base unit in. Hurrah. The problem is my PC case is maybe 1cm too tall to go in the cupboard. Words can’t express how annoyed I was the day I realised that.

For the last few months, since getting the desk I’ve just soldiered on with the PC underneath it, but the noise of the thing is starting to bug me now. It’s not deafening, but it is annoying, especially once you start to notice it. Also, the noise is loud enough during playing games that I really need headphones on, or to blast out the games music, it’s *that* distracting.

I’ve experimented with various fixes but none work, and I really have a few unsatisfcatory options right now.

1) Buy a new case and transfer all the components. Make sure the case fits! The downside here is hassle. I have limited recent experience of transferring entire PC innards, and am not 100% confident on the whole ‘connecting front panel lights and sockets to the motherboard front. There is always the non-zero chance of frying the board, or having a case with 1 single wire that is not long enough, or a single motherboard socket not lining up with the case. That would just bug me big time. I used to be a PC hardware engineer, and have seen things go wrong to often. This PC is absolutely system critical to me.

2) Buy a new PC. Obviously this is overkill, as my new PC was bought in October 2010, it’s a quad core intel i7 2.80 GHZ 8gig RAM Radeon 5770. Not a dud, and able to play modern games. Next year is definitely upgrade year, but not yet. That would be a silly expense

3) train myself to just deal with it. This is cheap!

4) stuff the empty PC drive bays with acoustic foam and try other wooly solutions to prevent the noise being too bad. for the sake of £30ish, this might be worth it.

Anyone have some better ideas? Anyone used that acoustic foam stuff? I considered building a wooden box around the PC. Is that madness?

Independence & control Vs productivity

There is a tension as an indie dev between these forces.

if I rely entirely on middleware and someone else’s engine (Unity + EZ-GUI + some sound stuff + whatever) I can be extremely productive. I don’t waste any time wondering about correct vertex buffer creation flags or optimising sprite rendering, i can just work on the game.

But then when there is a bug in EZ-GUI or a feature missing from Unity, I am totally screwed. Suddenly I’m coding what they support, not what I want to create.

Similarly in business, if I rely entirely on steam for my sales, I don’t waste any time worrying about website design, visitor numbers, bounce-rates, chargebacks or coupon/discount processing, no worries about web server stability, demo download speeds, CDNs and other fluff. I can just work on the game.

But then when steam turn down a game, say they don’t have a slot for a promotion, or change a royalty rate, or screw up a payment (this has NEVER happened to me with steam), then suddenly I am screwed. I become entirely financially dependent on another company, and in that case the term ‘indie’ becomes somewhat shaky.

It’s a constant war between which is more important, and the answer depends on your circumstances, your skills and your attitude, not to mention your free time and team size.

As a lone indie, obviously I have pursued the totally insane route of complete independence in all areas. Even energy independence. Ahahahaha!!! I code my own engine for GSB and GTB, and all my games. I use 3rd party sound libraries just because I frankly find sound coding dull, but everything else is pure me. It’s a big concession to even resort to using phpbb and wordpress, I can tell you…

But something has to give. I am possibly taking on too much and maybe not doing the best job of everything. I need to give way in some direction. Shockingly, and maybe surprisingly, I find myself thinking of giving way more on the business side than the technical side. The thought of abandoning direct sales is madness, but the thought of obsessing less about them, and spending less time on trying to eek out every last bit of direct sales profitability certainly appeals. It also appeals regarding PR. GTB *may* be the last game I handle my own PR for exclusively. (pls don’t email me offering to be my PR guy. The best PR people are already known to me, and frankly if you’re not, then you possibly aren’t that good… :D)

I think I need to spend more time on design, and less on code and less on business. The code side is slimmed back easily by just picking less insanely complex projects for a bit. I also need to spend more time actually relaxing and maybe even enjoying life. A close relative of mine is unwell, and it makes me realise how important it is to enjoy life while you can. I may even manage to sneak in a trip to a nice sunny beach soon.

The only *wrong* decision for me at this point would be to bumble along as I am. I think cracks are starting to show.