Video: Making Stuff Go Boom + More News! - P.U.R.E.

Building the new special effects, which I'll be the first to say that the video doesn't do full justice to, involved taking a long hard look at our particle systems, and finding better ways to optimize our use of particle count and how each bitmap used influences the outcome.

I'm not going to get into all the dreary technical details, but basically we're using alpha blending techniques to cut down on z-fighting. The main changes, though, weren't on the script-tweaking end. They were on the bitmaps.

Bitmaps for your particle effects can have a profound effect on the beauty and versatility of your particle systems. Typically, newbies to the concepts behind particle systems make one (or both) of two major mistakes:

1. They throw too many particles around at once. With a RTS, this is a crucial thing to avoid. RTS games are inherently CPU-hungry, so we need to save as many clock cycles as possible for more important things like game logic. We aren't building a FPS here, we need these suckers to be pretty at a distance, and gentle on people's hardware.

2. They use giant, very pretty bitmaps that don't scale well and are very wasteful.

Here's a news scoop. Every one of the special effects you're seeing is limited to under 300 total particles in existence at once (with a couple of exceptions where random chance can push that briefly higher) and none of the particles are using textures larger than 64 pixels on a side.

It works wonders, if you take advantage of the blurring that typically occurs when you are viewing a texture at a larger size than its actual resolution, instead of fighting it. For explosions, where to get a good effect, you typically need to throw at least a couple of dozen particles around to get a really polished and fake-volumetric look, it's especially important. For a little more detail, let's look at one up close:

Now, you're probably thinking, "gosh, that looks horrible", right?

Well, yes- when you get this close to it, and it's not moving. However, that's part of the secret. Particle systems are, generally, moving pretty fast. And usually observers aren't this close to them.

At worst, you're developing a FPS, and you want to have screens of this stuff looking perfect. OK, then go ahead, use a big bitmap, and throw a thousand particles or more around- for the closest LOD version. But use LODs on the explosions, if you can write that logic, and you'll save lots of processing power.

But, as I said, that's worst-case. In a FPS, those events are relatively rare, compared to a game like P.U.R.E., where once battles get going, you have several systems going at once every frame.

I develop this game on a fairly ancient computer, by gamer standards. It's an Athlon XP with a GeForce 7800GS in it- one of the last AGP cards, and not a speed-demon by today's standards. So, I see right away if I'm pushing into performance boundaries where a lot of people's computers won't go, because I'm not on some $5K dev machine donated from a major computer manufacturer. I think that in many ways, it's an advantage knowing where real-world performance will be all the time, though, so that instead of delivering a Crysis- a game so ahead of hardware that most people owned when it launched that it undoubtably hurt its real sales (as opposed to bundle giveaways with new video cards, where the game's developers typically make almost nothing)- I'm delivering something that anybody who's upgraded or bought a new machine in the last 3-4 years can expect to play immediately, and which will run smoothly.

So, long story short- the great change in the particle effects was mainly optization of the available resources. I cut down on z-fighting by more carefully handling alpha levels during blending operations, and I improved performance greatly by using small textures with a lot of noise that translate into lots of "dirt" flying around and sparkles when they intersect with brighter areas of the explosions, due to the alpha blending being used. The overall effect, in motion and at typical distances, looks far more detailed, but is actually using fewer particles and they're smaller in texture size. This is the first overall revamp of the special effects throughout the game in almost a year, so I'm not surprised that I'd finally learned some good tricks. I got the noise ideas from things I learned when teaching myself to pixel-paint for the low-poly features in World Builder, and it worked great here. I can't wait until this version's done, I think people will be very happy with it's overall feeling and quality (and, hopefully, lack of bugs!).

While I'm here, chattering away, I'd like to share my experiment last night, that looks like it will make it into the next Release Candidate: procedural wreckage systems. I'm a huge fan of all things procedural (i.e., simple, rules-driven designs that create complexity from a series of small rules), and this stuff I'm doing with wreckage, albeit incomplete, is probably going to be a major new feature.

Here's how it works (the very short version): I have objects that are spawned when certain actors are removed from the gameworld (i.e., buildings go BOOM). These objects, in turn, execute fairly random animation instructions, that give them a fairly unique look. It's not utterly perfect, but with minor tweaks to the underlying content, a huge amount of apparent variety can be created with a relatively low amount of developer-time. See the shots, below, for how things look in the game now, when you destroy buildings:

BEFORE

AFTER

Now, this is all very early WIP, of course, and I haven't had time to refine the content and the procedures a lot, but I think it's very exciting. Why? Because most RTS games are tied to static concepts of wreckage, and spend large amounts of development time building wrecks for their buildings. This eats up art-team time, and while sometimes it's very pretty, a lot of the time, it's being done because everything else has a wreck. So... why not just develop sufficiently-pretty procedural tools, and skip the specifics, whilst saving time?

Players will get bored with your Giant Castle of Doom that burns on the east wing every time after they've seen it a couple of times through. Making it both procedural and also somewhat specific to the art asset isn't a major increase in time- most of the time was eaten getting that art asset made- adding additional point objects or simple animations to where the particle effects will be is really pretty easy. So my vote is... do procedural stuff when you can get away with it, and if you go for a specific look, don't forget to add some real randomness to it, so that it's not quite the same every time. It sounds simple when I put it like that, but a lot of games don't do it, and I think they're missing out on ways to save time and increase their final feeling of real-world randomness. Sure, you can do all of this with complex physics, too, but that's CPU heavy. I just fake it with some smoke and misdirection, and voila- giant building goes BOOM, now we have a pile of concrete, chunks, girders and what-have-you. I'm not done yet, but I'm already sure that it's going to be cool and powerful, like a lot of the other procedural stuff in World Builder.