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

alt+tab works again

For a while i’ve had a problem where alt+tab wouldnt work in the game. I had it working from the main menu, but if you tabbed out mid-battle, it would hang on tabbing back. If you’ve played my older games, you know they always support this easily. I find it annoying when games don’t play well with the underlying O/S, and its often a symptom of a cheap console-port. Nevertheless, the change to directx9 has really complicated matters.

Regardless of this alt+tab works now even mid-battle, no thanks to microsoft. The problem is, you get to a point where you have to call Reset() on the Direct3DDevice. This is fine, and it returns true or false (effectively). If you turn on all the debug output, run with the debug DLLs, and check the debug output at this point you get a message a bit like this:

“Reset failed because you forgot to release a reference count somewhere”.

And the exact piece of code that writes that, knows exactly which piece of your code has its reference count too high, but they don’t bother telling you. Grrrr. In the end I tracked it to me grabbing the render targets surface somewhere (specifically the code that writes fancy layered shield impact effects). If you just grab a surface from a texture, it increases the reference count. Quite why it does this I’m not sure, as the solution is to just call release() immediately.

Anyway, it’s fixed. Several other things are fixed and improved, and the game is looking very playable right now. The actual AI-opponent fleets are not all finished, I need to play through 11 different battles on 3 difficulties, and tweak all those Ai-ships and fleets for a while yet. But then, apart from a few more tutorial things and putting in final music… that will be practically time for a beta.

Game tools and why they arent always released

Have you ever thought it weird that a lot of game developers do not release the tools they use to the modding community?

You might be tempted, in these cynical ‘game devs are bastards’ times, to suspect that this is a deliberate move by evil game devs to make modding harder, so they can sell more DLC and expansion packs. I guess that it might be true in some cases, but I think that the history of PC gaming would suggest quite clearly that a well served and popular modding community is a sales booster for a game.

I have my own theory, and its simply that professional game developers tools are crap.

I’ve always been amazed at how good the tools are that modders put together. Someone even did an editor for some aspect of Democracy that was better than any tools I had. I am notoriously crap at doing tools, and often hack things together using Excel and notepad. It’s really quite tragic.

The reasoning for why the actual developers on a game produce such poor quality tools may include the following

  • Working on tools sucks, and isn’t as much fun as the game engine or gameplay, so the least experienced coders tend  to get assigned to it, as a way of ‘paying dues’.
  • Sometimes devs are quickly hacking the tools together so they can get back to doing the important stuff on the actual game.
  • The game design is always changing, so you are quickly hacking in systems on a temporary basis, and never get time to tidy them up at the end of the project.
  • Producers and money-men dont always schedule time and budget for tools, as they don’t understand their importance, thus they are rushed.
  • An attitude persists that tools will not ship, and are not mission critical, so its ok for them to be buggy, ugly and difficult to use.

And of course this is all applicable to big budget games. With small one man companies like me, the situation is far worse. Literally every minute I spend on tools is time not on the core game. Also tools effectiveness scales with the size of the game. A tool that speeds up 400 hours of level design is worth more up-front effort than one which might save 20 hours work.

My tools do actually exist (as special hidden modes of the main game) but they are very, very basic, hacky and bad. Don’t be surprised if they aren’t released on the same day as the game :D

Big things burning

My smoke and flame textures have always sucked, and now I’ve got a lot of proper gameplay and bug fixing done, I’m having a sneaky graphics-whore day where I make better ones.

My searches for decent smoke clouds took me here:

http://www.herts.police.uk/about/buncefield_incident.htm

Ironically, a rather famous fire in the UK not long ago. Small world etc. Flipping big flames and smoke too.

I also improved my particle effects today. a simple 5 lines of code improvement that means the first 100 milliseconds of any particles life is spent fading and growing into its initial size. This prevents particle ‘popup’ when you are zoomed in, and actually looks really good. It’s something nobody will ever notice, but if I hadn’t done it, the particles would seem less organic.

What would Jack Thompson think?

When I create particle emitters they normally have a parent object, but some, such as missiles being shot down and exploding, do not and are ‘orphaned emitters’.

These die out, but if you quit mid battle, some orphans are left. If you then start a new battle, you see the smoke clouds from the previous one for a few seconds.

So I need to clear them and fix that. So I am writing a new function called

KillAllOrphans()

What would Jack Thompson or the tabloid press think?

Even Bigger, Better Explosions

It’s no good doing a game called gratuitous space battles without serious ship explosions. My current benchmark explosion is this one from revenge of the sith:

I’ve watched it hundreds of times, and taken about 30 still frame captures from the DVD to use as reference. I have quite a complex particle and effects system for GSB, and it’s coming along nicely. Currently, the average cruiser will have 17 distinct events as it explodes, not counting the release of escape pods

Those 17 events are scripted like this:

[explosions]
1 = 0,128,80,EXP_FRIGATE
2 = 11,97,149,EXP_DESTRUCTION_PLACED
3 = 20,199,205,EXP_DESTRUCTION_PLACED
4 = 20,196,238,EXP_DESTRUCTION_PLACED
5 = 101,108,41,EXP_DESTRUCTION_PLACED
6 = 120,143,163,EXP_DESTRUCTION_PLACED
7 = 200,47,189,EXP_FRIGATEBREAKUP
8 = 210,0,0,EXP_STARTBREAKUP
9 = 270,128,128,EXP_CRUISERDEBRIS
10 = 274,53,226,EXP_DESTRUCTION_PLACED
11 = 290,59,229,EXP_DESTRUCTION_PLACED
12 = 310,171,209,EXP_DESTRUCTION_PLACED
13 = 388,61,204,EXP_DESTRUCTION_PLACED
14 = 400,128,175,EXP_FRIGATEBREAKUP
15 = 400,128,175,EXP_PLUMES
16 = 400,128,128,EXP_BLASTGLARE
17 = 900,128,128,EXP_ANGLED_DEBRIS

They relate to particle effects and other graphics. So there are a number of different particle emitters called from different points on the hull, then at 210 milliseconds after detonation the sprite starts to tessellate into pieces. At the same point, the damaged hulk texture starts to cross fade into existence behind it, and the hulk components start to drift.  At 270 milliseconds a shower of permanent debris is spawned. At 400 milliseconds, plumes of wandering particles appear, accompanied by a bright flickering white glare which also generates a shockwave blasting existing debris out of the way. A final shower of temporary particle system debris is triggered right at the end.

This is all configured per-ship-hull, so different ships can detonate in different patterns and styles.

It looks cool :D