Game Design, Programming and running a one-man games business…

Making things explode (day two)

All I’ve worked on today is explosions, and not the sounds, just the graphics. The first part of the day was one of those moments that if 15 year old kids saw, they would think “Dang, I really need to do this for a living”. Basically I sat and drank tea whilst watching star wars : revenge of the sith space battles in slow motion. I’m sure a lot of people think all games development is like that.

In practice, it actually is real work, because I’m trying to achieve the impossible, which is to replicate ILM-rendered explosions that take hundreds of PC’s days, to run on a cheap laptop at 60fps. It’s clearly going to look crap by comparison, but I’m doing my best.

My initial thoughts with the game had been to use animated sprites. Basically, I had a particle engine that would throw together tons of particle effects, merge them, and save them out as a flipbook style group of images that get played back like a video clip. The plus side of this is that its really low CPU and GPU, because its just a few simple sprites. The downside is that it looks like crap. The problem is that a 64px by 64 px explosion (small!) that has 16 frames will be 256×256. to have 64 frames its 512×512. 64 frames is about 1 second, so that gives you a one second, always the same animation that is contained within 64 pixels.

If you need 4 varieties of that, thats a lot of texture for an indie downloadable game, and if you go to 128px explosions we reach 1024 square textures, and it all gets very inefficient.

The other solution is to optimise the crap out of your particle engine, and actually do the explosions in real time. That’s what I’m doing now, and it looks tons better, plus a bit of random fuzziness makes it different every time. And I can have bits of debris fly off over 128 pixels, which looks tons better. The problem is it involves drawing a lot of pixels, and a lot of verts, and doing tons of calculations for velocities, fading, shrinking etc. You need to avoid memory allocations, group together emmiters to minimize draw calls, blah blah. This is why it takes ages to get right. My current ‘big’ explosion has seperate emmiters layered to draw smoke, black smoke, big rubble, dust, flames, glowing bits, plumes of smoke and plume flares. They all combine in a single point to generate the final explosion.

Tomorow I’ll try and post a few screenshots, although it all looks much better when moving. I’m just waffling here so you appreciate it when you play the demo one day :D

Explosions

I’m trying to get better explosions today. So far I’ve achieved sod all. The topis the sample explosion from Star Wars:Revenge of the Sith. On the bottom is my current attempt.

It’ll get better…

GUI Coding is slow and dull…

I still hand code my GUI stuff. TBH, although I know people talk about using GUI libraries, I can’t see how it can save them that much time. I have a library of stuff like button, and window classes. This isn’t the issue. The issue is coding all the stuff that says “this window has a button here, and when you click it, that scrolls through this list there”

GUI stuff takes ages. it’s also really boring to code, and there is a huge long list of features which are automatically assumed by gamers which you must have. All buttons need mouseover states and tooltips, and you need the idea of modal windows, draggable windows, windows that go to to the top when clicked, etc.

Add to all that, the nightmare of making a GUI that runs nicely in different resolutions. I know that stardock have some clever system for doing this, but they employ dozens of people and run their own GUI software business, so they can spend a lot more time on it than me.

This is why I’m not blogging about exciting enw stuff in ‘the game that has no name yet but will have a code-name soon’. I’m doing GUI stuff for one of the three big ‘management’ parts of the game, and it’s nothing exciting to talk about. Not compared to the lasers and explosions anyway.

Finally moving to Directx9

Up until my new game (still un-named) I’ve been using version 7 of directx in my engine. How old is directx7 well lets see…

When Directx7 came out…

The Dow Jones was around 10,305 (it's 8,903 today!)
Harold Shipman had just been found guilty of murder.
George W Bush had just won the primaries, along with Al Gore.
Vladimir Putin was about to be elected head of Russia.

so it’s….

March 8th 2000.

So I think we can all agree it’s the time I GOT WITH THE TIMES, and at least caught up as far as DX9. It’s going quite well, I have lots of groovy stuff on screen, with decent frame rates despite zero real optimisations. So that’s cool (still need to get my text engine ported accross).


Why do it?

I wanted to do a game with lots of flashy graphics in, and have decent driver support. DX7 is unsupported now, and the nvidia profiling tools only work with directx9. A lot of cards are now just emulating dx7 using dx9 calls anyway, so it’s silly not to talk to the card in a language it understands.

Why not DX10?

That isn’t as widespread on peoples machines. Although my next game will not be that casual, I don’t want to assume people have DX10, as I certainly won’t be including it in my games installer. It offers no real advantage for 2D gaming over DX9, AFAIK.

BANG!

Today I’ve spent the whole morning working on getting my old particle engine editor doodad from Rock Legend (used to do the pyro effects) in a fit state to use for my next game (should that continue to be my next game).

I’m often amazed at how crap my tools are in comparison to everyone else (maybe that’s why i get the games done though?). Anyway, this is the most feature-rich tool I’ve ever had for one of my games (and It’s not finished yet).