Getting explosions right is HARD. Explosions are (obviously) a big part of Gratuitous Space Battles 2, and I want the GBS2 ones to be better than GBS1 by a noticeable margin. They already are, but I’m aiming for greater heights. Currently the explosions look like this:

exp1

And this: (smaller ones)

exp2

Which is ‘ok’, but I’d like them to be better, which means spending a lot of time looking at video of space battles (oh the things I have to suffer), freeze framing, stroking my chin and looking at code. There are a number of things people assume about this task which I’ve found not to be true.

Assumption #1: You can do it all on the graphics card. Not so, because different people have different cards, whose capabilities may vary dramatically. I want GSB2 to be playable on a standard laptop, not demand a DX11 driver and card. Plus a lot of these techniques assume Directx11, and you then need a DX9 backup for people who still have windows XP anyway so….

Assumption #2: it’s simply about the number of particles. Not so. I have a fairly efficient particle system that can handle lots, but I have found more does not always equal better. In short, it doesn’t seem to be how many particles you have, but how they interact, what textures they use, and how they move. Render modes (additive vs normal) also factors in a lot.

Generally, my approach has been to have a bunch of particle emitters all clustered together into one explosion. I have some big black clouds that build slowly, some firey small particles that fade out quickly (additive ones), some flame-texture particles that are additive, and some not additive, and I render them in a deliberate order and it looks like the stuff you see above, which is fine, up to a point.

The thing I haven’t managed to really convey is the ‘billowing’ effect of an explosion. Here are some of my reference images…

ex3exp4

This sort of thing is very hard to get right ‘in-motion’ because it involves some 3D movement of frankly millions of particles, so obviously the first question is how on earth to ‘cheat at it’ and get it looking vaguely right. In Gratuitous Stank Battles I tried a complex system where particles had #heat’ assigned to them, and cross-faded between white hot to black smoke (and different textures) over time. it looked ok, but probably not enough difference to warrant a bucket of extra code that was associated with it.

I am starting to think that decent explosions are 90% physics, 10% graphics. What I need is some more complex control over the movement of individual particles, rather than just more of them. With the explosion at the bottom, I’m thinking that there are a bunch of different ‘focal points’ of the explosion, different ‘billow-centers’, if you will. There has obviously been a central ‘bang’ and this has ‘spawned’ a bunch of airborne ‘flame emitters’ which continue to create new burst of flames which are created, balloon up, and then down and dissipate.

Currently I have zero support for such a system. An explosion is a single event, which may have a bunch of timed emitters with it, but it has a single focal point. Secondly, a particle has a single growth variable, which means it either is spawned and gets bigger over time, or it gets smaller over time. What I may need is the capacity to associate a timed sinewave with the size of a particle.

So my latest explosion todo list (fun stuff I do when I’m not busy) is something like this…

Add support to particle configs for a ‘sinewave-based’ growth variable, with starting size, max size and duration.

Create a new class of object called a GUI_SubExplosion, which can be spawned by an explosion and drift off from the central point slowly over time. Have that sub-explosion itself contain a list of particle emitters that it manages.

Should be worth a try anyway… In the meantime here is the latest big pharma blog video. and a nice article on showmethegames about banished.

12 Responses to “On programming decent 2D Game Explosions”

  1. baz says:

    WOW! – looks amazing. I’d say your hard work payed off :)

    • baz says:

      (I mean, even the screenshot at the top looks pretty amazing to me. But like you say, motion is a big element to it).

  2. It is indeed terribly difficult to obtain something convincing and I stopped counting the number of times I made tweaks if not complete revision of explosions for Human Extinction Simulator.

    Right now it looks like this: https://twitter.com/Over00/status/536236279651139585 (the gif is missing some frames but it gives a good idea)

    It sure looks better than my first iteration but even then I wish I’d figure a way to have the black clouds more “integrated” in the explosion itself instead of appearing like an additional layer that it not interacting with the sparks. Something closer like the last picture in your post. Still scratching my head on how to do this though …

  3. terren says:

    I wonder what effect the lack of air pressure would have on an explosion, makes me wish I had the resources to get one of the space agencies on the job.

    Also, can I get that first shot in desktop size?

  4. For billowing smoke you’re looking at something like this http://http.developer.nvidia.com/GPUGems3/gpugems3_ch30.html but it sure would be nice if there was a much simpler method.

  5. sil says:

    I wasn’t going to nitpick your spelling of ‘fiery’ but I thought you might want to correct Gratuitous “Stank” Battles.

  6. Riccrdo says:

    Hi,

    the screenshots already look awesome! Though I understand that it can be very hard to make that stuff look good in motion.

    I’ve worked with particles in 3D games (Unity in particular), but not so much in 2D. I kindof expected 2D games to just use pre-rendered spritesheets as much as possible. (Although it would limit potential variation.)

    Is that true for smaller effects or do you use realtime particles for everything?

  7. ac says:

    (something perhaps for update if this kind of thing isn’t in)

    I’d like all sort of “massive” creaking and cracking noises (lets pretend its the kind of space where sounds are heard) with hulls breaking apart, imploding and so forth could be interesting. Of course if there’s a ton of ships on the screen, this could cause a bit of cacophony, so limiting this somehow to only the more dramatic moments with the biggest ship right now on the screen might do the trick. You could eg. detect somehow if the ship was likely to be doomed and then few “anticipative” creaking sound (probably dozen needed per large hull type with non-repeat shuffle) leading to a slow cracking sound.

  8. ac says:

    (on why would there be implosions in space – well perhaps a ship could have some special type of engine that on destruction, perhaps not every time, caused implosion – just to make things a bit more varied)

  9. kdogg says:

    How much texture memory can you afford? Flipbooks (sprite sheets) of fluid simulations is how most fx artists get that complex motion.

    And I know UV distortion is typically quite expensive (modifying UVs with another texture), but that’s another route to get some roiling motion (without resorting to flipbooks).

  10. Ian says:

    Cliffski, I wish you would reconsider the ‘shock-wave’ effect from explosions that was a late addition to GSB-1. From preview videos I’ve seen of GSB-2 it looks like it is still there. I know I’m being a bit of a physics anorak but a rippling expanding shockwave in a vacuum just looks wrong.

    If the game were called ‘Gratuitous Submarine Battles’ then it would be brilliant, but in space it just makes me wince every time.

  11. If you get stuck for blog ideas, a post on the code architecture of the game would be an awesome read. How the different areas of code are laid out and how they communicate with each other. It seems like the game has a lot going on behind the scenes and it would be interesting to see how you wrangled everything together.