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

Category: game design

How shields do (and will) work

Posted on June 28, 2009

Every space movie has deflector shields, and so does GSB. here is the current system:

You can optionally add shield generators to your ships. The more the merrier, and some provide more shield points than others. The total shield points get added together as the shield strength. This strength needs top be blasted to zero to knock out the shields. In this respect, all generators act as a linked unit.

3% of weapon hits somehow luckily get through the shields anyway (luke skywalker lucky shots)

Shields have strength, but also resistance, and weapons have shield damage, and shield penetration. If shield resistance > shield penetration, the weapon is totally ineffectual. Otherwise, shield damage is applied to shield strength

Shields recharge over time. You need to totally blast a ships shield strength to zero to stop it recharging.

Now for the new bit (working on it now…)

Shields will have ‘stability’ which indicates the integrity of the energy field. Special weapons (probably torpedoes) will be able to interfere with the stability. If the stability is reduced to zero, the shields will temporarily collapse, effectively turning them off and allowing weapons to penetrate. These shield disruptor weapons will ignore shield strength and resistance, working on totally different principles. The only defence against them will be point defence lasers and ECM beams to scramble the torpedoes.

This way I’m avoiding the possibility of just havign seriously ‘shielded-up’ ships that are effectively impossible for enemy ships to overcome. Another possibility I’m toying with is preventing shield generator modules from being 100% additive, but maybe on a sliding scale.

So 1 shield module = 100% of its strength, 2nd shield module adds 80% of its strength, etc etc.

Thoughts?

Better Damage Effects

Posted on June 25, 2009

I have a vaguely usable hacked together damage editor which means I can make a few improvements to the ships now. I’ve only done 1 so far, but with the tools in place the rest shouldn’t take more than a day. Here is a screenshot showing a federation cruiser and the changes:

A) This shows that some damage has knocked out the lighting on the warp nacelle. This is actually just visual and does not correspond to engine damage, that would be a nightmare, but it still looks better than them staying on :D Also, two of the tiny orange lights have been knocked out by another hit (bottom A)

B) These tiny impact ‘scars’ are new. By having a lot of these scattered around the ship, the targets selected by enemy ships seem less predictable and more random, although they are pre-assigned in truth, and then scrambled in order.

C) My editor lets me easily add ‘permanent’ smoke or spark effects to each damage texture, so they don’t seem too similar. Most major impacts result in a complex smoke and flames emitter anyway, but only some of those smoke effects stay around for the lifetime of the ship.

This screenshot was taken using my debugging hacks, so it’s not really representative. Normally a ship hit this much would be flying through a lot of debris and maybe hulks from other ships, so it would look a bit better :D

Comments?

Damage Effects Editor

Posted on June 22, 2009

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.

Gratuitous Deployment Interface

Posted on June 12, 2009

I’ve just made a change to the games deployment-screen UI, so I thought I might as well share it’s current look: (click to enlarge)

I used to have an icon ‘picker’ on the right hand side when you loaded an un-deployed fleet, and you had to drag and drop the ships into position on the left hand side. This was a bodge and tedious with huge fleets and big monitors.

Now the game will auto-deploy the fleet as you load it, and then you can slide them around and fine tune it. This is the same sort of system used by the Total War games, and I think it works much better. I’ve spent a few days working on some heavy duty re-organising of code for it to render faster, and things are much much more efficient now. Even with bazillions fo ships and things going zap everywhere, it seems to run pretty well. My next big challenge is getting it to run on my laptop…

Any thoughts on the design?

Website updated with FAQ and new screenshots

Posted on June 6, 2009

Yesterday I got the GSB website updated a bit, adding the final logo for the game and some small new screen shots and a FAQ. You can see it here:

http://positech.co.uk/gratuitousspacebattles/

And the faq is here:

http://positech.co.uk/gratuitousspacebattles/faq.html

As well as that, I also got the last few bits of GUI done, so the in-game GUI now is generally the final one, not the crappy one in the BBC video, although I’m hoping to add various bits of polish to it here and there. I also have a tutorial to do, and need to code in support for switching screen resolutions as well. From then on it’s back to play balancing and final weapons and data for the simulation.

The screen resolution system will probably support a number of fixed resolutions to choose from, if your card supports them. In the past, I’ve coded games that basically ask the card what it can do and let the player pick, but that can be hellishly awful to support, as some cards return about 100 options, and some can be obscure. Right now, the game needs 1024×768 minimum, but I might try and squash it to 600 for netbooks.

I definitely aim to support at least one stupidly big res, probably 1900 1200 res. If your video card can do it, the game will look real nice at that size.