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

Month: May 2009

Anti-Missile weapons

Currently there are two anti-missile weapons in Gratuitous Space Battles. Point Defence Lasers and ECM beams. The point defence laser basically tracks incoming missiles and just zap them. They always hit (at the moment) and take one out. Of course, they can be overloaded,e specially by multiple-warhead missiles, but they are pretty cool. The other one (ECM beam) does exactly the same, but rather than destroy the missile it scrambles its guidance system and there is a cool wibbly wobbly effect as it veers everywhere. In the final game, the choice between them will probably be some sort of crew/power/cost/weight trade-off.

The thing they share though, is that they can ONLY target missiles that are aimed at their ship. You can’t have an ECM frigate at the spearhead of your fleet zapping all the incoming missiles to screen your capital ships from attack.

Clearly this sucks.

The solution isn’t trivial though. There are a LOT of ships in GSB and a LOT going on. if I’m to enable anti-missile weaponry to select from any missile on the map, that will involve a lot of processing. My mind is agog with quadtrees and other methods of limiting the amount of times each weapon has to do this:

for(each missile)
{
are_you_the_closest_one?
}

etc. It would normally be a trivial thing, but it’s something that isn’t in the game yet because it hasn’t really been necessary. The question is, do I write some big generic system that every piece of taregt selection will reference to find the nearest object? if so, that involves a fair bit of re-work, and it’s likely to be a several-cups-of-tea and a free morning sort of problem.

How the (sort-of) multiplayer will work

Ok, I need some feedback on this, and I can’t shut up about it any longer. Here are my plans for multi player GSB, and they are going quite nicely in terms of being almost playable already…

GSB is a single player game with a number of scenarios each of which has a normal, hard and expert AI fleet to fight against. You will probably play each scenario several times, trying to reconfigure your fleet each time to beat the opposition. You will also gradually unlock new races, so there will be the urge to beat every scenario with every race eventually.

However, nothing beats going up against the brains of another player. The problems with a mutiplayer version are:

  • This isnt a real-time game, so you would sit there for ages waiting for the other guy to design his fleet.
  • Indie games dont have big sales, so finding people to play against is hard.

The solution is PBEM (play by email) but WITHOUT the email. Basically it works like this:

You load up a scenario as usual, having selected your race, and probably already with a big bank of pre-designed ships from battles against the AI. You probably have an uber-fleet that kicks ass against the expert AI already. You then click the ‘challenge’ button. This takes you to a screen where you type in the username of the other GSB player (someone you know, who has the full game), and a taunt to tell them how their pathetic space fleet will be ground to dust by your mighty lasers. You click send.

That uploads a tiny data file onto my server, where it’s stored in a database. The next time your friend launches the game, and clicks ‘refresh challenges’ he/she will see your challenge, with taunt in all its glory. He/she can then download that challenge file and play against your fleet in their own free time. Eventually, they should find a fleet that beats your fleet, and no doubt they will then challenge you back.

Obviously its possible to see how many of your challenges have been beaten, and to even track how many attempts it took. There are also tons of high score and metagame possibilities, as are the theoretical possibility of me posting ‘open’ challenges’ which get sent to everyone.

This is tons of work, especially for a net-coding n00b, but it’s in and working at the server side, I’m just tweaking client-side UI code to get it to work smoothly.

Thoughts?

Current Optimisation targets

Stuff that is currently slow in really hectic games:

  • The ‘smart’ sprite texture for the shield impact sprite gets created and destroyed a lot at runtime
  • The sound engine spends a lot of time looking for free sound channels or cached sounds
  • Drawing of blast textures for bullet turrets is slow somehow. Lots of small 2-primitive draws I suppose.
  • Drawing Missiles and missile glares and trails
  • Drawing debris

I love optimising, and the frame rate isn’t too shabby even with all hell breaking loose, but it would be cool to get it much better in the hope of adding some really gratuitous extra effects later on for fast cards.

Space Hulk particle test video

Now that the hull editor for the game actually does something, I managed to put it to the test by adding some particle emitters to the drifting ‘hulk’ from one of the federation cruisers. This short youtube video shows the ship being destroyed, and then you can just about make out the flickering particles on the damaged hulk. It look much better not in crappy youtube resolution.

Right now they all flicker off at a fixed LOD, but I’ll sort that out so it’s less obvious, then I can add them to all of the ships. I’m aiming for a look where people can zoom in during a battle and be impressed with the amount of silly detail I went to in order to make it all look cool.

This is fun bank-holiday-weekedn stuff. Tomorrow it’s back to php and MySQL. bah!

Making actual tools

I know that editors and level tools are part-and-parcel of most game development processes. Most games companies have at least one full-time tools programmer, who will work 8 hours a day for a year designing, coding and supporting the tools made to build the game. However, when you are a one-man-band, dedicating that amount of time to tools just isn’t viable.

There are several solutions. You can try and hit the happy medium where you spend enough time to get usable tools, but don’t let it eat too much into your schedule. You can produce really good quality tools that make game production a breeze, then realise you have not got close to finishing a game and you have to go get a day job again… Or you can just hack everything in manually using notepad and excel and worry about it later.

I’ve traditionally chosen the last option. I hate MFC, which is the ‘language’ that tools used to be built in, and I’ve never learned java or C#, which is what people often use now. That means that when I coded the few tools I use (like my particle-engine tool), I hand code them in C++ just like the games GUI. This takes ages.

Until now, I’ve been manually editing text files for the spaceship data. I have a master spreadsheet with lots of the data in, to make balancing easier, but there is a lot of manual staring at paintshop pro and memorizing pixel positions to type into notepad. Clearly this is mental.

So this weekend I made my very first steps towards a proper ‘spaceship-hull-editor’ for the game. This is still a makeshift hacked tool which won’t ship in the game, it’s just a quick tool to make it easier for me to tweak some of the graphics data, such as placing particle emitters for burning ship hulks. It’s a small step in the right direction I guess.

In non-tools news, I’ve been fixing a lot of very minor graphics glitches, the odd disappearing piece of debris or mis-aligned laser blast, or slightly crappy looking tractor beam graphic. The game is looking quite nice. Next week will be geared towards some online-integration, and some general gameplay code.