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

Month: August 2009

Raw PIX data for gratuitous space battles

I’ve never seen anyone share data like this, but I don’t see why they wouldn’t, it’s hardly source code. PIX is a free program from Microsoft that lets you analyze your games directx performance. I haven’t analyzed this data or changed any code yet, but here is a quick 2 minute start of a battle in the game (release build) analyzed with pix. Click the image for a larger version

This is great for working out why you get occasional slow frames, or working out where bottlenecks are. TYhe FPS seems to never go above 60 FPS, because the game caps it there, making a note of the ‘headroom’ available for potentially enabling higher-demand effect (not all done yet).

This is under Vista, 2 gig RAM, Core 2 Duo 6600 2.4 gig CPU and a Geforce 8800 GTS with latest drivers.

Please feel free to comment on how the numebr compare to agmes you might have worked on or develop now. I’d lvoe to see other peoples pix data as a sanity check. Is 83 set textures a frame a lot?  it seems to depend on what else is going on.

RangeFinder

In my play testing and balancing sessions, I found myself really wanting to know what the ranges were of a specific weapon mid-battle. You get to see this in pre-battle deployment, but that’s only the initial formation. There is nothing more frustrating than watching your ship sit there, minding its own business while an enemy ship sits just out of range and missiles it to pieces :D I should adjust the ‘retaliate’ AI order to allow it to move within range

So anyway, I’ve added in a new range-display GUI to the battles. Basically you just click on your ship to show the window with its details, then click a module with a turret on that window for it to highlight that weapons range on the map. I’ve toggled on the background grid here for extra ‘tactical display mode’ fun.

The last few days have been really hard work battling an obscure texture corruption bug. I was working on it at 1AM last night. I’ve completely rewritten my vertex buffer code to use a different locking strategy, and I’m pretty sure it’s for the better, although I do too much memory copying for my liking. Still, the game runs pretty fast even so.

Victory Conditions for GSB

For a long time the code that checks for the end of battle has basically looked for the first fleet whose number of live hit points as a ratio to its total (damage is ignored, only active or destroyed ships matter) drops below 10%. At that point you lose.
Theoretically you can pull back from 10% of your fleet to victory, but the code is there to prevent the game going on for hours trading shots between two closely balanced fighters.

Some play testing today has made it obvious that there are other clear cases of victory / defeat that need detecting. You may well have played an RTS where it’s pretty flipping obvious whose won, but you have to endure another hour of it. Hopefully this won’t affect GSB.
The new rules include this:

  • If three minutes has gone by without any ship being destroyed, and one fleet is less than 50% of the strength (in percentage terms, not absolute hitpoints*) of the other, then it loses.

also:

  • If one fleet is reduced to nothing but fighters, and the other fleet is not, AND that other fleet outnumbers you by two-to-one in hit points. You lose.

As I code this, I’m wondering if that initial 10% calculation should also be contingent on the three minutes without a ship destruction being introduced too. It should at least consider extending it if it’s a close battle.

This is the kind of stuff that gamers who want to be game-designers think designers do all day. In fact a lot of the time its more obscure crap like “If the player designs a cheap ship, then edits it in the editor and goes back to the deployment screen, but the fleet is now too expensive, do we prune ships automatically? or do we put up a dialog or disable the fight button? zzzzzzzzzzzzzzzzzzzzz

*on expert difficulty, the AI outnumbers you, so this needs to be calculated as a fraction of totals.

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.