On programming decent 2D Game Explosions December 6, 2014 cliffski 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: And this: (smaller ones) 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… 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.