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

Initial thoughts on game AI

Posted on April 13, 2009

I’ve thought about the AI for Gratuitous Space Battles a lot. I have a lot of ideas, some of which I’ll sketch out, and some I’m keeping secret for now.

When I say ‘AI’ I’m being pretty nebulous. I don’t use AI in the trad comp-science limited sense of it. I’m talking about the whole matter of computer-controlled opponents. Who they are, how they are selected etc. Because GSB is a ‘hands-off’ battle game (for now), there is an element of determinism about how the battles work. In other words, if you design a fleet, in theory the AI can design one that it is assured of kicking your ass with.

There are many ways it could do this. The most obvious bruet force method is to randomly design fleets and pick the one that beats yours. Another would be to have some initial ‘seed’ fleets and do a genetic mutation – evolution algorithm to deduce the ultimate fleet against yours.

However, while I want a challenge, I don’t want you to be beaten every time. Plus, the ‘problem-space’ is colossal, way beyond chess, because there are maybe 40 hull designs, maybe 100 ship modules, near infinite combinations of ships and modules, and that’s before ship placement or ship-behavior/instructions. It’s not possible for the AI to beat your fleet using deep-blue style iteration of possibilities.

So there is a good chance the final AI will be some mixture of pre-designed (by me) AI fleets, combiend with an element of letting the AI battle several thousand slightly randomly mutated sample player fleets, and improving on my initial design.

I’m sure everyone has lots of ideas of where else to go with this, such as machine learning, copying player fleets etc. Needless to say, I’m mulling over them all :D

Space Hulk

Posted on April 11, 2009

I’m testing some stuff where after a big cruiser gets blown apart, there is a drifting blackened hulk of it still floating in space (in 2 or 3 big pieces). It still needs some work but it doesn’t look so bad on a grainy video :D

 

If you like it, rate it :D
Cheers

Updating The GSB website

Posted on April 10, 2009

I just did a minor update of the GSB website:
www.gratuitousspacebattles.com
Please feel free to vote it up on stumbleupon if you have such a thing.
The original page was completely placeholder and had screenshots of crappy spaceships I had designed, alongside some very early particle effects and shield/laser effects. Plus there were no screenshots at all of the non-battle screens in the game.
The new screens are still small, but they give a more up-to-date flavour of the game. Plus I’ve put in the proper GSB logo, and a bit of blurb that I knocked up temporarily to explain what I’m getting at.

Obviously as I get closer to release (still many months off) I’ll add videos, proper screenshots, faqs etc.
I’m quite pleased with how even this one-page site looks though. Iv’e finally got a game that is coming together which will actually look nice in screenshots, and hopefully that will get people to try the demo (which is the major hurdle for an indie developer).
Feedback welcome!

Changing some shield stuff

Posted on April 8, 2009

I did a fair bit of speedup code today, added a new ship, then put some effort into the shield effects. The old graphcis were 512px square, which is pretty big with mipmaps. A basic test showed 1024 px images looked noticeably better, but they get pretty big filesize wise.

So I did what lots of games did, and cut the images down to quarters, and in code I mirror/flip them to draw all four quarters of them. It’s an old trick to save filesize. There’s an image below showing it in game, and file itself.

I also added support for different shield graphics for different races, so you have aliens with their funny foreign-colored shields :D


Optimising day

Posted on April 6, 2009

I’m taking an afternoon to optimise all the code that I added recently. A lot of stuff that makes the game looks cool was being done in a really inefficient way. In some cases, it was a matter of remembering to check somethings onscreen before going to any effort to draw it. In other cases, it’s a matter of caching data.

Caching means ‘keeping a copy of’ effectively. If I ask you the date, and you tell me, I could then ask you the date in 5 minutes time, or I could make a note of the information you gave me earlier, and not bother you. A lot of optimising comes down to caching data. In this case, I was calling the cos() (cosine) function several times in short succession, and getting the same answer. sin() and cos() are pretty slow, if you call them several thousand times a frame, so it really makes sense to cache them.

Things seem much faster now, even with tons going on :D