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

Fixing the AI orders (again)

Some cunning GSB players noticed that the orders were not working correctly in terms of attacking certain classes of ship. If you deleted the ‘attack fighters’ order, the desired behaviour was that the ship ignored fighters until there were only fighters left.

This bit of code was broken and basically needed re-doing. Now you might think it’s an easy algorithm that goes like this:

Go through each intact enemy ship
Pick the optimum one out of the classes we should shoot at
If you still have no target...
Go through each intact enemy ship
Pick the optimum one ignoring class.

Leaving aside the inefficiency of parsing the 300 enemy ships twice each time, this isn’t as simple as it looks, because a lot of the time a ship will fail to find a target within range. Thats because all of the ships its ordered to fight are across the map. Ideally the ship trundles over and shoots them. So the criteria for actually picking a target differs from the criteria for establishing whether or not there are any valid targets. Plus, the idea that once all the frigates and cruisers are dead, that EVERY TIME I look for a target I have to do a dummy run through with invalid orders is just untidy and slooow slooow…

So I ended up coding a convoluted complex system which (as convoluted complex systems often are) is way faster than that. Basically Fleets keep track of if they have any ships of each class. Whenever new ships show up (survival mode) or a ship dies, the fleet recalculates that data. if the data has changed, it tells each intact ship in the fleet. Those ships then compare this against their orders, and deduce whether or not the orders still stand. If they don’t, they tell all their turret AI’s to ignore class-based orders from now on. This involves practically no overhead during a  typical target-acquisition call (which are very frequent)

That took a lot longer to code, debug and test than it did to type here :D

In other news, I fixed some dodgy server-side code that prevented challenges being deleted. I’m amazed more people did not whine at me that the ‘delete’ button on a challenge basically did sod all. It now works :D

Minimum Reqs. We just pull it from out of somewhere

Have you ever bought a game based upon the minimum reqs, and found out it doesn’t run? or it’s a slideshow? have you ever pheared the min reqs, but bought it anyway, and be surprised how well it runs?

Here is the inside track:

WE  (the devs) HAVE NO IDEA. WE MAKE IT UP.

Now obviously as an indie dev, I have less ability than Actiblizzard to tell you if the game will run on a 1 Gig RAM, 64 MB video card rig, because quite frankly, I don’t own one. I currently own 3 working PC’s, 1 Sony vaio laptop, 1 ultracheap dell netbook, and my main Mesh uber-dev PC.  That’s it.

Now when I release a game, I check it on all 3, then on my mates PC, my brothers PC, and a few other peoples PC’s. (other indie devs mainly). Then I take a rough guess, and we call it the min req. You might be thinking that this means it’s just me making it up, and that big publishers have 100 different PC’s and they can be scientific about it. I call bullshit.

Lets laughably assume there are only 10 different video cards on earth, and that there are only 5 different drivers for each of them. lets assume there are 5 different sizes of RAM, and 10 different hard disks, 10 different processors and 5 different flavours of windows. That gives us:
5 X 10 X 10 X 5 = 2,500 combinations. Now lets assume 10 types of soundcard and 10 different configurations of other software running (p2p clients, messenger clients, CD burning stuff, antivirus, firewalls, rootkits, viruses and other malware). Thats 250,000 setups even with these stupidly conservative estimates.

When people ask me if GSB will run on their PC (A very understandable question right now, as there is no demo), I give as honest an answer as I can, and here it is:

“My dev PC is a core 2 Duo 6600 2.40ghz with 2 gig of RAM running Vista on an 8800 GTS video card. The game runs silky smooth at 1920×1200 res with all options at Max. If you have a PC that in any way gets close to my spec, it’s a no brainer. The game also ‘runs’ on my sony vaio which has an intel onboard chip, but I have to disable the shaders for it to look right. It also runs well on lots of people’s PC’s with a lower spec, but if you have on-board video and a maximum screen res height of under 768 I really would wait for a demo”.

I’ve heard some surprisingly good things about GSB performance on MACs running emulators, even under WINE, and on very low-spec PCs, but I honestly have no real idea of min spec. So here, as a service to people on the fence considering the pre-order, if you have bought and played GSB, feel free to post your specs, and the games performance in the comments. (Note that its frame-locked to 60FPS so you won’t see it go faster. It uses any spare ‘headroom’ to do a few fancier effects if it has time)

The perils of patching

Patching a game people are playing is a nightmare. On the one hand, you have all these people experiencing problems with the game, and you desperately want to fix their problems.

On the other hand, is the fear that changes to the code may actually change something somewhere else and cause problems for people who are currently playing the game fine. Everyone has a different setup, with different hardware, and plays differently, so its’ very hard to have an absolute test case when you know you fixed bug A without introducing bug B.

Worse, is the nightmare that without a huge room full of QA experts like the big retail studios, you can either do some basic tests and release a new patch, or wait 3 days while you methodically test the new patch yourself. Neither option is easy, or popular, and whatever you choose you uspet some people.

I know some people have performance issues with the new improved 1.03, the one that fixed the sound issues (AFAIK). So today, rather than working on fun gameplay stuff (area of effect damage) and AI orders, I’ll be profiling the sound system code.

Balls.

Trial By Fire. And Bugs…

I did mention it was a beta didn’t I?
Actually people have been VERY understanding, given all the bugs that leapt out of the woodwork the nanosecond I put this pre-order link up. As expected, its a combination of hardware-related crashes I can’t re-produce (The menu battle bug, the sound crashes) and just UI things that I never thought to check (submitting a blank serial code, deleting every ship, fielding ships with zero modules…)
I’ve fixed a bunch of stuff, the real urgent ones, and released a patch, and hopefully my auto-patcher will automatically update everybody. As of this morning, the game is much more stable and playable.

But

There are a TON of things I need to improve in terms of UI, to get the game more usable. I was amazed to discover so many people prefer mousewheel zoom to be reversed to the way I like it, but that’s an easy fix. I have to totally re-code a lot of Ui stuff (ship hull browser, challenge browser) to make them more usable.
And I’m going to crack on with that passionately, because only when all that is done do I get to do the real fun stuff, which will be the reacting to balance and gameplay issues, ‘stacking’ of ships, better AI orders for the crews etc.
I’m overwhelmed with the feedback from everyone and pleased that people seem willing to put up with a few days of crap in order to get a polished game. My priority this morning is the sound-related crash.
I’m working on it!

Finding and fixing some nasty bugs

It’s amazing what bugs you find when you just sit and play through the game for hours (I’m playtesting and balancing the game so that the AI fleets give you a bit of a challenge).

Two bugs squashed today are these:

Firstly, the code that detected that an enemy target was being ‘painted’ by a target painting laser (and thus easier to hit for missiles) was just not working at all. I’d checked and double checked it many times, but because the ‘is it painted’ code is just one of about 6 factors determining optimum target selection, it was hard to tell if it was working right without stepping through everything each time.

It turns out that code worked fine, but some *other* code which told a targeted module whether or not it even *was* a missile launcher, was buggy, and so the code was never even being run. doh!

The second bug was investigated after I noticed some very slow missiles which looked like multiple-warhead missiles but never split into their sub-munitions. It turns out that this code has never worked correctly! The code works fine the first time a missile splits into sub-munitions, but if it gets to live long enough to shoot another missile later, the sub-munitions are never triggered. That was an easy fix.

Unfortunately, that means I’ve been underestimating the destructive power of multiple-warhead missiles all the time, which means I need to re-play through every battle, on every difficulty, and both re-balance the fleets, and maybe re-balance the cost and strength of the appropriate missile modules too. This will take all of today at least.

Damn :(

One thing I did notice, that was pretty cool was an imperial AI fleet I’d put together that sends its fighters in ahead, and the rest of the fleet shows up afterwards (moving slower). By lucky hap, although the fighters were useless against the heavily armoured federation cruisers, they did manage to blow the crap out of the row of point-defense equipped escort frigates that flew alongside them. So when the Imperial cruisers got into range, they could bombard the feds with missiles without opposition. This is exactly the kind of design and thinking I hoped the game would reward, so it’s cool to see it is all about strategy and not just luck :D (Obviously when you play against that fleet, make sure you don’t have a line of unarmed frigates sitting waiting to be blown up :D)