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

Victory Conditions for GSB

Posted on August 18, 2009

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

Posted on August 16, 2009

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.

Game ‘downloaders’

Posted on August 14, 2009

I hear that a certain game portal is now not only giving away a game for FREE, but it actually gives you some vouchers for use at an online store with the ‘purchase’. Effectively they are PAYING you to have the game.

What generosity!

But of course, there is a catch. You HAVE to install the game by downloading their ‘game browser/downloader/client thing’

I understand why they do this. They want to get a foothold on your desktop / web-browser. They figure that if they bombard you with enough ads and promotions and pop-ups and reminders through the thing, that you will end up spending more money with them. It probably works. It’s probably good business. But I hate it, which is why I don’t do it

The ferengi businessman in me would love to do it, but the part of me that is actually a gamer, and someone who wants to entertain, rather than pester/nag people, stops me doing it.  Like most people who program computers, I’m always fixing friends and families PC’s, and its a rare day indeed that you find someone whose PC isn’t running a load of startup crapware/bloatware/adware that they didn’t want, use, need or remember even saying yes to. Even if I forget all sense of morals and trying to be the nice guy, I’d still be opposed to it, because anything that makes it annoying or ‘risky’ to download and buy a game is bad news in the long term for devs like me.

When you buy a game from me, or from people like me (sillysoft, puppygames, winter wolves etc), you just get a game installer. No crap that runs at startup and send you adverts, just a game. The game you bought.

Isn’t that how it should be? Imagine if everyone you bought a DVD from had their own stupid system of ‘launchers’ and ‘players’ that you needed to keep around while you owned them? You just want to buy a DVD, or in this case a game. Don’t put up with anything else :D

Performance stats for GSB

Posted on August 13, 2009

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

Posted on August 11, 2009

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.