Pew Pew Pew, etc

No release yet, but that’s because some of the stuff I’ve been working on made the game a bit slow and crashy for a while. So what’s new?

Level data.
In the last screenshot I posted, your ship was being assailed by a swarm of randomly generated enemies. I hummed and hawed and changed my mind several times over when thinking about how to define real levels. I knew I wanted it to be easy to create them, tweak them, and plug new ones in, with the possibility of adding extra level packs after the game is complete. At first I considered a custom xml format, then LUA scripting, then finally thought to myself “why not just use Java?” So now levels are Java classes that implement a particular interface and have access to a fairly simple API that allows them to define events that will be triggered at certain times during the level; spawning a new enemy being the most common, but they could be almost anything. Level definitions should be easy to read and write in any case, obfuscated enough to prevent easy cheating by changing in a text editor, but extendable with a minimum of programming ability.

Your shots now go “pew”, enemies go “boom” when destroyed, and your ship goes “BOOOOM” when hit. Unfortunately this introduced an annoying crash bug that would sometimes kill the game when you got hit, but I tracked that one down the other night and stomped on it. Sounds are all stored as .WAVs at the moment, which is fine for short spot-effects, but when I add music and the like later on, I’m going to have to figure out how to load .MP3 or .OGG files.

There’s now a subtle “glow” around all the on-screen entities, reinforcing the old-school vector monitor effect. This isn’t a particularly difficult effect to implement, though it took me far from my comfort zone, and there was a lot of head-scratching and beard-stroking before I actually got it working to my satisfaction. Keep in mind that this is my first foray into graphics programming in many years, and I’m totally new to the world of OpenGL, 3D graphics and >gulp< shaders, so there is something of a learning curve. I was pretty chuffed to see it in action.

If anyone’s interested, how it works is this: First the scene is rendered to an offscreen buffer. Then the contents of that buffer are drawn to another, but this time with a fragment shader attached. Shaders are small programs written in their own C-like language that are run on your graphics card. In this case, the shader is run once for every pixel in the scene, and it has the final say on the colour of that pixel. For Shootah I use a shader that blurs the original image. Then both the original unblurred image and the blurry one are rendered to the screen, one of top of the other, giving everything a nice glow.

Originally this really killed performance and dragged the frame-rate way down. Remember that the shader is running for every pixel, and my scene is rendered to a 1024×768 pixel buffer, meaning that it was running 786432 times per frame. Yikes. But after some optimization, including reducing the size of the “blurred” scene to half that of the original before rendering it, thus cutting down the number of shader invocations, seems to have helped a lot. I’ll still have an option to turn it off though. Other than the glow effect, it’s a pretty simple game, graphically-speaking, and it’d be nice if it could be played on older hardware, even if it doesn’t look quite as good.

Next up: I’m writing a simple editor to make defining vector entities simpler than typing long lists of integers into the source code, and finally releasing version 0.0 to see if the thing at least runs for anyone other than myself.

Leave a Reply