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

Back from the mountains

I haven’t blogged for a week because I’ve been away. Unlike many geeks, when I go away I *REALLY* go away. I take a phone, for emergencies, but it has no email access. No computer, no tech. Just a digital camera. Here was one nights accomodation (a mongolian yurt in the alps) and a panoramic picture of the surrounding area..

Back in civilisation now, with much to do, and much to arrange. Plus, battlefield 3 to try…

On Holiday

I’m on holiday for a week. Don’t bother trying to burgle my house, it’s protected by an ex-commando, and my two cats.

SEE YOU SOON

 

Range Modifiers

This is something I really like, and comes in reply to feedback about how people hate having to guess what the underlying numbers are in tower defense games. I got it implemented today *still needs optimising…*. It’s a way to show easily the effects of a range boost augmentation for a unit. The units in GTB are built from GSB-style modules but some are ‘augmentations’ that apply to any module, such as ‘boost range by 10%’. I thought it might be cool, if such an aug is fitted, to show it as a distinct band on the range indicator when you select a unit. It’s the slightly separated strip around the edge of the range indicator for the selected riflemen.

The brighter triangle represents the firing field-of-view for that soldier. Some units have 360, like mechs, but infantry can’t swivel their hips like that :D

Thoughts?

Knowing what your code does

Do you know how your game works? I bet you *think* you do. And if you do, there are never surprises when you suddenly take a look at a frame of it being rendered. Invariably, mistakes mean stuff works differently to how you intended it to.

I use AQTime, which is pricey as hell, but fantastic, as a profiler. You can control it from code too, so I can pause my game mid-battle, hit ‘F’ to go one frame-advance, and that frame is profiled by aqtime. It then will dump tons of stats, telling we call times and counts for every function (or even line)  and let me see this:

This chart immediately tells me that some lightmapbuffer sprite code was being run. It should be skipped in daylight levels, so clearly I have a bug. And that’s before I even begin to look at performance optimisations in this frame.

If you write big complex stuff and don’t have a professional quality profiler, you need one. They are absolutely fantastic.

Fixing my heap crash bug

Well I did it. I am 99.9% sure I finally crushed my random crash bug. Here are the gory details.

It crashed in debug (or release) and seemingly somewhere random. Possibly much later than the actual cause, as is the way with these things. By using Microsoft’s handy CheckHeap functions, I was able to progressively narrow it down to a certain bit of code. (Essentially you check the integrity of the whole heap at two points, then when one of them triggers, you know whether it was inside or outside the enclosed code.

So what I narrowed it down to was some code that command bunkers, hospitals and repair shops run, where they go through their list of ‘supported’ units (the ones they are affecting) and updates them. Essentially this means telling all the units in the list that they now are not supported, then rebuilding a new up-to-date list. For speed reasons this is only done every X frames.

Now the obvious case for a crash is that some unit that was in the list when we added it, has been deleted, and thus when we go to tell them they are no longer being supported, we write to gibberish and cause mayhem. BUT! I know that this is never the case because no units are deleted mid-battle, ever.

Except that it turns out I’m wrong about that :D. They ARE deleted if… I drop a 25 man squad of infantry into a 12-man trench or bunker. At that point 13 of them get deleted. If I dithered when placing them long enough for a nearby command bunker to ‘claim’ them, then when I release them, I set off a time bomb, and after X frames, the command bunker will write to freed memory and hilarity ensues.

All fixed now, obviously. The easy fix would be to not support units until they are placed, but that isn’t nice for the GUI, and also I needed to rewrite the code to use a different system anyway so that multiple bunkers could overlap (they don’t stack though).

2 days. probably 20+ hours of debugging. What a pain. Insert comment about needing to get my act together regarding smart pointers here.

Bah.