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

Category: programming

New Video, just some new gfx fluff

Today is a weekend day, so I don’t feel bad adding graphical fluff. I also fixed a few minor bugs in the UI. Amongst the stuff added was Level-Of-Detail particle emitters for explosions here and there, some new particle effects for minor things like shield impacts, and missiles flares fading out as they run out of fuel.

Particle LODS are interesting, because they only half solve the issue. Not drawing them at lower zooms is all well and good, but each particle still needs processing. Its not enough to assume they will remain off-screen when not being drawn either. I guess I could not update them, and just note the time elapsed, and ‘catch up’ when they are next on-screen, but because they may have moved on-screen during that time, you can get artifacts that way. You can maybe do it for ones clearly massively off-screen.

In any case, having LOD levels for some effects makes it easier to turn them off when the GPU is overloaded, or if we need the time to do other stuff.

This vid was knocked together in 10 mins, so it’s nothing special, but you might like it anyway.

Performance stats for GSB

In drawing a typical frame of a biggish battle, the following time is used up:

47% Drawing the ships and their attached particle stuff and effects

12.7% Drawing the debris, and updating debris that is not on-screen

8.3% Drawing missiles and associated effects (it was a missile-heavy fleet, to be fair)

7% Drawing drifting hulks of destroyed ships, and their attached emitters

5.9% Processing gameplay stuff for ships, including target-selection AI

4.3% Post-processing shader stuff

3.18% Drawing the backdrop map.

2.49% Drawing GUI

It seems clear to me that the background map and the missile stuff is slower than it should be, so time to do some digging and stroking of chin, and some speedups…

The tricky thing with all this is making sure that you minimize the amount of work a video card will do, ebcause some people cards may be less capable than mine (GeForce 8800 GTS), but at the same time I don’t want to ‘over-batch’ things, because ideally there is some concurrency betweent he CPU and the GPU. (In other words, the GPU is given things to do while the CPU gets on with non-graphcis stuff, as opposed to the two chips basically taking turns.

There are tools to examine all this stuff, like PerfHUD and Pix. They can be very very complicated to wade through though. I’ll try and gather up some more interesting stats one xactly how its all looking from a performance POV.

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.