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

Category: gratuitous tank battles

Long slow checklist of stuff

There hasn’t been much to blog about lately. I don’t have a set-in-stone beta-date for GTB, but it’s likely to be the first half of March. This clashes horribly with GDC, and it’s associated press crush, and also with a friend going to Australia, and also with stuff I can’t talk about just yet but will do soon.

Right now I am just slogging through a list of tons of features in the game, making sure they work, and do what they should do. In doing-so, I’m finding all kinds of minor quirks that have crept in. As designs and code changes, stuff often gets left in a paradoxical state, where it no longer makes sense. For example, I had three options when picking defender as a mission:

Scripted AI
Adaptive AI
Adaptive++ AI

And as defender, two options:

Attacker uses scenario-defined designs.
Attacker uses any designs (including yours).

The thing is, the 2nd two defender options are the same as the attacker ones. It was just described really badly, and makes much more sense now I’ve harmonised it. This is one of those things that isn’t a ‘bug’ as such, just a thing that is obviously ‘wrong’ to a newcomer to the game, but has so much code & design history (I won’t bore you…) that it went by un-noticed by me for months.

The one thing that I reckon will confuse people about GTB, and the thing I’m still not happy with, is the vast complexity of different options when it comes to how to play a battle. This isn’t just a tower defense game. It’s more like a tower-defense/attack / RTS/ simulation toolkit. I guess it’s ‘little-big-planet-meets spore-meets tower defense. None of this trips-off-the-tongue. I can see a lot of me waving my hands in videos trying to explain the various permutations of how to play the game. I guess that will make for content-rich interviews :D

 

 

Latest GTB video, very close to beta now.

Here is the latest video showing a few battle clips. I think I am almost at the finish line regarding beta + pre orders now. Just a lot of housekeeping to do in the next few weeks, for stuff like crash testing, multi resolution support, and finalising the installer. I intend a slightly better installer this time, so people can’t get into a muddle with where the game is installed any more.

Anyway… here it is:

Gratuitous Shield Effect

I sneakily stuck in a new effect today as I was play testing. I used some cunning distortion shader cleverness to give a ripple effect to shield bubbles when they take incoming fire. You can see it happen here on a medium mech:

Looks really good in-motion, with everything else going on. It’s also effectively free, in performance terms due to the overhead of the shader pass happening anyway.

I’m currently tweaking a few variables, and improving a few minor things like this. Then I have the final manual, final performance optimisations etc, and then it’s pre-orders + beta. I’m looking forward to doing a few final trailer videos showing off the game in all it’s gratuitous explodey glory.

Gratuitous Manual Battles

A lot of people really liked the manual for Gratuitous Space Battles, and I’m conscious of this fact when working on the one for GTB. As with all complex strategy games, there is a ton of stuff to tell the player, and they will likely want to reference it after playing for an hour or two, in order to look-up or clarify stuff. It’s also a good place to put stuff like lists of hotkeys, or unit stat comparisons, although I probably won’t be doing the latter.

Some trendy designers would suggest that ‘a game that needs a manual is badly designed’. This is just silly. We don’t all want to play games as simple as Bejeweled, and sometimes, a separate reference manual is a good idea for a game that has real depth and a ton of features. I also like doing a manual because it means people can read how to play the game on their laptop, or a work PC, where maybe actually playing through a tutorial isn’t an option. Plus it means people who are really on the fence can read the manual before deciding to buy the game.

The manual is maybe half done. It’s mostly all there, but it will need some more images, some proof-reading, spell checking, and a second pass for actual humour and flavour text to make it more in-keeping with the blackadderish spirit of the game design. I might change my typewriter font to make it more typerwriterish, a tradeoff between authenticity and legibility. I like the idea of a 1914 army document that never got updated during 200 years of war. maybe the army spent all it’s effort on making more deadly lasers and none on word processors?

On the technical side, it looks like the server move went ok. Just quadruple checking it all before I turn off the old one. That still scares me…

Suprisingly complex health indicators

I’ve never liked health bars in RTS and Tower Defence games. They always seemed annoyingly crude to me, like the designer just thought ‘err…health bars? lets just copy the games from 1980 ok?’. They really break immersion badly for me. Worse still, if you wanted 3 different indicators, for health, armor and shields, you got 3 bars, which was silly.

Gratuitous tank battles solves this with cunning health ‘discs’ only on selected units. The image below shows some infantry with full armor and health, and a damaged turret that has lost some armor. I need to change the code a bit to make the colors relative, rather than always splitting them equally, for situations with high health/low armor etc… anyway…

The problem with this system is that to draw the discs programatically you need a lot of triangles to be smooth. Given GTB supports VERY high zoom in and out, that means either blocky hexagons when zoomed in, or triangle-calculation nightmare framerate if you select 500 guys when zoomed out.

The solution is ‘continuous level of detail’ which 3D engines sometimes do with meshes (not sure how common it is), where you basically add triangles as you zoom in, so you have a constantly varying image complexity. The human eye should never notice. With a simple triangle fan, it’s relatively easy. With a big complex mesh, it’s way harder. I know, I worked on Elixirs ‘infinite polygon engine’.

You might think drawing a few hundred triangles here and there makes no difference to frame rates, but it all adds up. I like to write the fastest code I can. It’s also pretty cool to play about with stuff like this. I can’t actually see it happen, even though I know it is, because I can see it happen in wireframe. Nobody playing the game will ever care, but it does add some polish to the game. it makes my GUI look much smoother than it otherwise could have done, given the framerate I’m expecting.