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

Damage Effects Editor

My editors and tools are always really bad. Something has to give when you are a lone developer and with me it’s tools. I’m slowly getting better at it. It’s just a time thing. Today I spent most of the day getting my feeble ship hull editor to let me graphically position and assign particle emitters to damage sprites. (Screenshot below).

basically when a ship gets hit a pre-defined chunk of a damage texture gets drawn at the impact point, and it comes with a number of attached particle emitters. they are only visible fairly close up. there is also an additional temporary emitter that’s much bigger, but these ones are the tiny sparks that flicker over the burning hull of the ship after the smoke and flames have died down.

It took much longer than it should have to get this in, but it’s good because previously I placed them by hand in paintshop pro, then noted the pixel position and copied it to a text file. (laborious eh?)

This way I can placed dozens a minute and thus there will be a lot more of them :D. Tomorrow I’m going to do nothing but set up fleets and play out battles to check everything works and that the range of weapons and defences is acceptable.

Motion Blur

After a few minutes playing Arm-A II today, it was obvious that camera-motion-blur is really cool, and I needed to get on with putting it into GSB. Half a day of monkeying around with poor documentation and I have it in and working, and togglable etc. It needs some fiddling to get it right still. The nice side effect is that when a big explosion makes the camera shake, the blur kicks in automatically. You can’t really tell with a small jpg, but it’s quite a nice effect in motion. Of course it does have a drawback, in that if you freeze the game in mid-shake-blur and then move the camera, everything is blurred, because you were near the explosion when it happened. I think thats quite acceptable tbh.

I also got some more optimising done today, which means I can consider adding in a few more gratuitous effects for peoples whose gaming PC’s are as good or better than mine, and want the game to look as gratuitous as possible :D

Lazy Execution in games (pseudocode)

I’ve been testing a bit of a worst case situation for the battle screen in the game where there are just TONS of fighters, and they all have contrails and running lights and you try to see as many of them as possible onscreen.

Not surprisingly the game chugs pretty slowly during that. I’ve been looking at ways to speed the rendering up and have realised something I haven’t been doing enough of is lazy execution.

So what is lazy execution in non coding terms?

Imagine your program is designed to tell a robot how to cook (hey why not?). You might have a bit of code that says “Go to the fridge and grab some butter”. That involves a ton of steps, it would involve moving towards the fridge, locating the door, opening the door, removing the butter, etc.

So what you probably do is write some code like this:

FetchItemFromFridge(item)
{
Find fridge
Open Door
Take Item(item)
Close Door
}

And all is lovely and wonderful. Now later on in the programs development you realise you need to do that a lot of items, so your code in another area of the game looks like this:

FetchItemFromFridge(butter);
FetchItemFromFridge(milk);
FetchItemFromFridge(ketchup)

Weird recipe huh? Anyway. this sort of code gets written a lot, especially on big games, because the guy writing the fetchitem code is a different guy to the one writing the recipe code. Often recipe-coder has no idea what happens inside the fetchitem code, so he can’t see any reason to not call it multiple times.

Of course, the sensible re-written code is this:

Find fridge
Open Door
TakeItem(butter)
TakeItem(milk)
TakeItem(ketchup)
Close Door

Now the downside is, that’s a pain to code, because you need to be aware of the circumstances and write code in each case to handle it. This is what lazy execution solves.

Lazy execution means that when I write the code that says “open door”, I don’t actually open the door at all. I just make a mental note that someone wanted the door opened, for reasons we can only speculate about. The good news is, if someone else asks to open the door immediately afterwards, I don’t need to do anything at all.

The real ‘action’ happens when someone calls the ‘takeitem’ code. At that point, the clever lazy stuff says “whoah! you cant take an item without the door being open, I better open that now. At this point, the previous instructions that had been ignored actually get put into action.

The drawback is that the fridge door close needs to be lazy too, which would impact on your carbon emissions :D

Obviously its more complex than that. Incidentally, this is how a lot of directx works. When you call SetRenderState or SetTexture, sod all happens. It only actually does anything if you render something.

The really good news about using lazy code, is that you can optimise anyway all redundancy. In my case the pseudo code causing some issues was stuff like this:

LockVertexBuffer
for each particle
CopyToVertexBuffer
UnlockVertexBuffer

By making the Lock() lazy, the lock is never called (nor is unlock) in cases where no particle needs to be drawn. On big maps, with most of them off screen, this is quite common.

Back to optimising

So the fullscreen / windowed toggling is still shaky, but the game now runs in both windows and fullscreen and in pretty much any resolution, including my own 1920×1200 res. Listening to music from star wars whilst testing the game fullscreen at that res with a big battle is a flipping joy.

I’m in ‘lets minimise the number of textures used’ mode. Even at the start of a battle before much fighting, I have this, and it’s not pretty. (click to enlarge).

The problem is the running lights use a different ‘blend mode’ so putting them in the same texture as the ship saves me nothing :(. Lots to think about here. SetTexture() can be pretty slow, and you ideally don’t want to be doing hundreds of them every frame. Of course, in games programming, everything is a compromise. The good news is I’m only using up 70% of the CPU to do this stuff, given a minimum 60 FPS.

Insane days work just to swap screen res :D

Today, I was awake at 6am as it was holiday morning. Not for me, I’m staying here, but it means I was awake at 6am, and naturally, ended up programming by 7.30am.

Sooo… I thought I’d get the screen res code done today, and here it is at 11.55PM and it’s still not 100% what it should be. I’ve stopped for food twice, and didn’t linger over it. Bah.

Now granted, I spent maybe two hours dealing with the upcoming German translation of Democracy 2, but the rest of the time I’ve had my head buried in the directx documentation trying to find out just how the hell it’s supposed to handle a screen res change under directx9. I finally got there, and I’m still ironing out the bugs in certain circumstances, but my main objective now at least looks doable, which was to retain the feature all my games have of ‘in-game’ resolution toggling.

I HATE it when games ship with a separate ‘launcher’ app that you use to set the screen res. It’s just so fiddly. I much prefer being able to fiddle with such things, especially windowed / fullscreen toggling ‘on the fly’. I doubt it will be possible mid-battle, but at least it will be a part of the main app itself. Plus it makes it trivial for me to test that the GUI works in all resolutions. 768 really pushes it height wise, but I’ll sort it.

Today was not fun, it took longer than it should had, and it was seriously frustrating and involved. The idiot who knocked on my door to try and doorstep-sell me energy supplies got told where he could shove his special offer :D