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

Damage Textures

I’ve spent all day working on damage textures, and they work, even if my amateurish texturing makes them suck a bit. I’ll get proper artists once I’m sure how the game will look and play.

Rather than doing anything cleverly procedural, I’m defining set damage sprites for each ship that layer on top of the ship once it’s been hit at that point (see below).

There is a combination with some of them of being a static texture, and having a particle emitter on them which makes it look better when the ship is moving (hopefully running away at this point).

There’s tons more code to write and tests to do before I become convinced that this works and looks ok. I’m not happy with it yet, but it looks better than the ship remaining spotless until it suddenly goes bang and dissapears. It’s also very expensive in CPU/GPU terms so the framerate nosedived a bit. It’s still way over 120 FPS in debug, so I’m not worried, plus I havne’t made any obvious speedups yet. Don’t forget I have a decent PC, so I’m aiming to ship a game running comfortably over 100FPS on mine, so that it handles 60FPS for lower end machines.

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.