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

Category: programming

Pushing 2D engines further

Posted on August 13, 2012

I have dabbled very slightly in 3D (Don’t be alarmed), and have retreated in terror at the additional grief it requires, and the compromises required, and the general ickiness as it seems to me.

So I am pretty unlikely to release a proper 3D game in the next few years, at least. I personally do prefer 2D games. However, that doesn’t mean I do not enjoy nice graphics, and certainly there are a ton of nice looking 2D games out there. The majority of them are side-scrolling or similar style games that rely more on a very good piece of art direction (Braid, World of Goo), than they do any sheer horsepower or rendering muscle. I’m not aware of many 2D games, indie or otherwise that tax a CPU/GPU as much as Gratuitous Space or Tank Battles.

However, having just bought a new PC, AND watched the latest cryengine demos, it’s pretty clear that modern gamers have enough firepower to render the bejezus out of anything in 2D, so we are in the happy situation of twiddling our thumbs thinking what crazy stuff to add next time-around.

One idea is is to push particle counts through the roof and have seriously complex explosions and smoke trails etc. This could certainly be ramped up, although smoothly transitioning to it from low-spec PC’s is a nightmare

Another idea is to use a LOT of different layers and components to build up individual units to give them a more unique feel. Obviously GTB is a big step up from GSB in that respect, but it’s got way, way more scope.

Shadows and lighting are two other possibilities. GTB infantry uses blob shadows. Animated shadows are certainly doable, but involve a crazy amount of texture RAM to do right. Maybe worth investigating. Faked 3D lighting using that clever deferred rendering thingy is another (fairly tricky) option.

More detailed environments is another. The problem here is art budget. It’s all very well saying we need 120 different bush or pebble models. Someone has to make them, and get paid for it.

More cunning explosions, using some sort of clever physics modelling, or procedural whatnots, or clever multi-layered shader thingies, is another option.

Of course the real problem is TIME. I already have this big scary change to Gratuitous Space Battles waiting for me to release for everyone. It’s just sat in-between holidays, GTB updates, redshirt, and talking to builders. Plus another new thing I haven’t revealed yet. I am quite tempted to just push out my GSB update very soon ‘as-is’. I was hoping to find a cunning way to use it to raise money for charity, but that’s a whole other story…

That steam stutter bug, and tracking it down…

Posted on July 27, 2012

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?

Gratuitous Air Strikes

Posted on April 20, 2012

It’s taken me a while, but I have air strikes in the game, although they still need balancing. Here is a brief demo video:

Air strikes currently come in 2 flavours (although it’s all controllable by text files so modders should have fun). And are presented to the player just like a deployable unit from the deployment bar. I might have to fiddle with that a bit later, because currently they ignore divisions, which might annoy some people?

Air strikes last for a set duration and then drop fairly high damage blasts onto random 9and not-so-random) locations within the given radius over that time. Balancing them will be a pain, but currently my thinking is relatively low cost, high-impact and long recharge times, so that you use just 3 or four of them (max) during a battle.

The difficult bit, as ever, is the knowing you have balanced them right, but I’m sure people will let em know if I haven’t. This is probably the last pre-release added feature for the game, the rest will be mod support, bug fixing and minor tweaks and refinements.

 

Better AI on the way

Posted on April 11, 2012

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.