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

Category: programming

Multi-texturing

Part of today was spent on the fleet design screen adding pilots as a requirement. This is something I’ve got from the old travller game. Basically some missions will have a limited number of trained pilots for your ships, thus limiting the number of small fighters that are viable for your fleet.

I also finalised which space backgrounds would go with each mission. Then it was on to some graphical stuff…

I’ve added a new weapon, which is an ECM blaster that knocks out the targeting systems of a ship for a few seconds. Ideally you would have a ship that acted as ECM cruiser to knock out the weapons of the enemy cruisers before you sent in your fighters and bombers to blast them to bits :D. As a result, I need a graphical effect on the target ship to show its been zapped.

The existing shield effect isn’t the same sort of thing, because it’s a seperate sprite drawn on top which surrounds the ship in a sphere. I needed something that ‘hugged’ the outline of the target ship. In a 3D game, you would maybe have an animated texture which you applied to the ships mesh, but these ships are sprites so that won’t work. The solution has been to layer two textures together and render them in one pass. Basically, I have a generic ‘lightning effect’ texture which is drawn on top of the ship, but I tell directx to use the alpha channel from the ships sprite as the alpha, and the color data from the lightning to draw the effect.

That bit was a pain to get right, but once done, I then needed to animate it. That is being done by having two lots of texture coordinates for the effect sprite. I leave the first set (for the ship, used as the alpha mask) at their defaults, and the effect color layer uses the second set. That lets me ‘ripple’, scroll or shake the effect texture, and still have it ‘wrap’ closely around the outline of the ship. It works, but I need to program a decent movement effect, and do a proper effect texture. Then I’ll post screens :D.

Pay attention to trigonometry

Do you want to program computer games?

Do you understand trigonometry?

If not, you need to. I (rather famously) do 2D rather than 3D games. But that doesn’t mean I don’t use maths. I use a lot of maths, every day. The one area I use all the time, is trigonometry. A sine wave is a beuatiful thing. A curve that simple (in maths terms) is just incredibly elegant and finds its way into everything. It’s amazing how often you need to express something in a game in terms of a nice smooth curve. Knowing the (very simple) maths behind a sine wave, and similar functions is just vital if you want to code games.

Geometry and trig is taught really badly at school. Do you know the ‘real world’ examples used to illustrate the usefulness of this stuff at my school? I remember it to this day, “imagine you work in a factory where you need to calculate the volume of a can of baked beans”. How about this: “imagine you have the most tedious job in human history”.

Now imagine how games coders use it.

“Imagine you are making a smooth oscillation of a spaceship laser beam as it sweeps across space attempting to lock onto an enemy fighter”

“Imagine a spaceship has exploded and you need a smooth way to fade in and out the brightness of a shockwave which occurs as the ship blasts into pieces.”

If you are still at school, pay attention during maths. Trig used to be pretty useless (although I even used it as a boatbuilder) for most jobs. For the really cool jobs involving things exploding, it can be bloody useful.

Don’t underestimate how well you need to know this stuff. I got an A in my maths O level a year early, I got an A in stats a year later. I was top of the whole year in maths. I got 100% on my maths O level mock. And in programming terms, I SUCK at maths. I used to ask other coders for help with maths stuff. Being the absolute best at maths might not get you the girls when you are sixteen, but it really matters big time later on. Study the maths.

Better Shields

I spent part of yesterday and today working on the shield effects for Gratuitous Space Battles. The old effect was shit, but it was only placeholder. It was just a simple alpha blended sprite that draws over the ship, fading in and out as the ships hit like this:

There was a lot wrong with it. firstly lasers seemed to shine through it, secondly there was no feeling that the ship got hit from a certain angle, and there was generally not much pizzaz. The newer version is better but still needs work:

Now I have the incoming laser fire stopped at the right place, plus the shield itself has 2 layers, a feint all over effect, and an angled blast front image which faces the point of impact. I think it looks lots better. What I don’t have yet is any sparks or particles rippling out from the impact point. A simple particle shower is easy, but ideally the particles would ripple around the shield in a realistic spherical sense. I’m not sure how easily doable that si without doing it all in 3D, which is overkill.

Right now I’m working on spaceship breakups on explosions so I’m taking a break from the shields stuff.

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