Category: programming

I recently got far enough in GSB2 to start fiddling with the particle effects for various things, and various low-level engine changes mean all of the particle configs for the original game are kind of screwed up and don’t really work right with this engine, so they all need re-doing, which is fine, as CPU/GPU horsepower has risen enormously since then, and it would be good to up the detail count on them anyway.

This reminds me that I never really had a decent particle editor when I started making Gratuitous Space Battles. it was all pretty poor. I had a MUCH better one for Gratuitous Tank Battles, (Which actually used two entirely separate rendering systems for different particle effects…) but ideally I wanted something I could have integrated into the game as an easy to use tool, maybe not for public consumption, but who knows?

Anyway it took me a day to knock this up: (click to enlarge)

Which isn’t too bad given I use my own GUI code, and it gives me a very easy way to stay within one project and one app, and have the source code for the editor readily available, and using the same functions as the actual game, so if I update the particle engine, it’s updated everywhere. I now need to go and create some cool particle effects with it, but obviously that’s the fun part!

My approach to particle effects is pretty simple. I have discrete LODs for some of the more expensive effects, where if you zoom in, a more detailed effect with a lot more particles will appear. That certainly isn’t as smooth as it could be, and of course ideally it would all be procedural and algorithmic, but that sounds like a bit of a nightmare. Expect a smorgasbord of screenshots and videos eventually when I get the hang of using it properly :D

This has taken me all today and part of yesterday to get working. And no it isn’t final, and no, it isn’t optimized yet. And yes, it probably should have been easier. That little asteroid is occluding the bloom flare from that engine. You can see the non-occluded one above. Took me ages, and about a million lines of code. Arrrghhh. Click to enlarge…

I’ve spent the last day or three experimenting with various visual effects for GSB 2. This is kinda fun, but I also think its quite productive. If i was making the game using Unity or some other engine, I’d just pop along to the asset store and browse the effects other people have written and bung them in. Job done, ship the game.

I can see why a lot of people are attracted to doing that, but personally I’ve found rolling my own solutions to be much more rewarding, not just as a coding geek, but from a game design and visuals POV. The lighting effects in GSB 2 will not be the standard Unity effects, or the same effects used in any other engine, ever. they are unique to the game. They may not be ‘radically different’, but I think the distinctiveness helps. Sometimes i end up coming up with pretty wacky solutions to problems which allow me to include features in an unusual way. I think it’s a really good thing for different coders to be approaching each problem in a different way, after all we are supposed to be creating original, and distinct works of ‘art’.

When big movies add special effects, they don’t often copy and paste effects from other films. Arguably Star Wars has already done ‘lasers’ so you could theoretically just copy them. The problem is, you never get innovation that way.

I just watched ‘The Forbidden Planet’, a classic 1950s sci fi movie. it was the first sci-fi movie to have an all electronic soundtrack, which was amazing at the time. It’s cheesy as hell now. I bet one of the reasons for it’s success is how different it sounded as a result. they had to work out how to do that from scratch. Then sci fi movies all tended to sound the same and become tedious until Star Wars, when George Lucas decided classical music could work with a futuristic movie. Now, ALL movies copy that idea.

It would have been easier, simpler, and cheaper, and much more in line with what the audience expected if those innovations had not happened. But when they get it right, they get it right big time. I doubt that GSB 2 will change the future of gaming, but I like to think that by occasionally approaching things from first principles and hacking my own way to make things happen, I’m at least ensuring there is some variety in the way stuff looks.

BTW… On the topic of Robby the robot, what a flipping layabout! He is , if you read-between-the-lines a nightmare to work with. First he does this whole ‘Sorry I was giving myself an oil-job’ excuse (yeah whatever), when he can’t be found when called, then he mocks and sounds incredibly put-out because he is asked to make a new dress. then later, he tells the crew ‘if you need anything, use the beamer’ without ever explaining where or what that is. Plus he moves at about the pace of a snail. if I didn’t know better I’d think he did that deliberately so everyone got sick of asking robby to do something and did it themselves.

‘if you need anything in about 6 hours, use the beamer, otherwise you might as well do it yourself’.

Bah.

So I’m working on various stuff I’m not talking about yet for GSB 2, and I ended up with the image below. All looks fine, it’s a ship nicked temporarily from GSB 1, with some tweaks, and I found a bug. The bug is a bit of a pain, and it’s those 2 little axillary engines in the middle towards the bottom. Those engine glows are not supposed to be there, they are supposed to be under the ship.

But they aren’t.

And I could fix this really easily, but actually, it is kinda cool. I mean…why *shouldn’t* i have a few ships with engines that sit above other elements of a ship? the more creative freedom the artists have the better right? and that way the glow from the engines will illuminate the ship ‘fins’ in dark battles. It will look cool. It also means a shedload of irritating fiddling with code that already looks like a psychotic kitten has had a panic attack in a spaghetti factory.

but hey, I’ve trained myself never to think like that. If it makes the game better, I’m going to commit to supporting it, even if it makes life awkward for me. Expect this game to ship sometime this millennium…

So after a lot of mucking about with render states and blend modes and shaders and reading, and z buffers and other tedious things i think i now have the previously unattainable mixture of proper smoky effects, happening in 3D with my shadow casting and bright ‘burn’ laser and flame effects all working together. This means a ship exploding can look like this (click to enlarge)

Which I’m pretty happy with. Those particle effects are all a mess, placeholder stuff that I can fix easily once I’ve rebuilt my editor for them. Plus I need to add a lot more stuff, and also those ships are obviously just modified GSB 1 ships not designed to take new lighting capabilities into account fully. I also need to fix some boxy depth-of-field artifacts for the distant asteroids. Next on today’s agenda is likely to be getting ship hulks to cast shadows (easy!) and then work on letting hulks drift in pseudo 3D (towards or away from the camera, but always planar, as they are sprites after all :D).

So what was the solution? Well it was as I suspected (amazingly). I just needed to take the key scene objects, the hulks, the ships, the turrets (which are separate items) and the asteroids and draw them to my own depth buffer. I then set that depth buffer to be texture layer 2 when rendering the smoke & flames (so that I can reference it in a shader) and just set alpha to 0 for any pixels where the depth buffer is closer than the particles I’m drawing. Right now I’m using a manually created and rendered-to depth buffer, so it’s actually a render target. You can’t in Directx9 have a z buffer that is a render-target, so I might experiment later with toggling the z enable on and off and using a standard directx zbuffer. I’m guessing that internally the card drivers can simultaneously render to a dedicated Z buffer AND the current RT, whereas if you use a manually created RT it’s a separate call. It’s no big deal because I build up a ‘deferred’ list of depth buffer render objects in the engine anyway, but it would let me reduce my video memory usage.

To recap, I’m doing all this because I want the smoke effects to be rendered last, so I can do some clever-ass light compositing that excludes them, such as laser beams lighting up the ships they pass over.

Non-Programmer version: “Blah blah geeky geeky…Explosions!” :D