Category: programming

I know that editors and level tools are part-and-parcel of most game development processes. Most games companies have at least one full-time tools programmer, who will work 8 hours a day for a year designing, coding and supporting the tools made to build the game. However, when you are a one-man-band, dedicating that amount of time to tools just isn’t viable.

There are several solutions. You can try and hit the happy medium where you spend enough time to get usable tools, but don’t let it eat too much into your schedule. You can produce really good quality tools that make game production a breeze, then realise you have not got close to finishing a game and you have to go get a day job again… Or you can just hack everything in manually using notepad and excel and worry about it later.

I’ve traditionally chosen the last option. I hate MFC, which is the ‘language’ that tools used to be built in, and I’ve never learned java or C#, which is what people often use now. That means that when I coded the few tools I use (like my particle-engine tool), I hand code them in C++ just like the games GUI. This takes ages.

Until now, I’ve been manually editing text files for the spaceship data. I have a master spreadsheet with lots of the data in, to make balancing easier, but there is a lot of manual staring at paintshop pro and memorizing pixel positions to type into notepad. Clearly this is mental.

So this weekend I made my very first steps towards a proper ‘spaceship-hull-editor’ for the game. This is still a makeshift hacked tool which won’t ship in the game, it’s just a quick tool to make it easier for me to tweak some of the graphics data, such as placing particle emitters for burning ship hulks. It’s a small step in the right direction I guess.

In non-tools news, I’ve been fixing a lot of very minor graphics glitches, the odd disappearing piece of debris or mis-aligned laser blast, or slightly crappy looking tractor beam graphic. The game is looking quite nice. Next week will be geared towards some online-integration, and some general gameplay code.

It’s the weekend, so rather than working on gamey stuff I’m making the battles look better :D. I’ve been improving the way the big ships explode so the drifting hulks fade in better, and the subsidiary explosions now blast in various directions. Turrets now smoothly track their targets, and there are various other small tweaks like highlight flares when bullet weapons fire.
My last niggly annoyance of the day is bullets, by which I mean laser pulses.
I draw all the bullets in one go, to make it extra fast, which is fine, but to do this I have to draw them AFTER I’ve drawn all the ships.
The thing is, the bullets are quite big, and when they ’emerge’ from a gun turret, they obscure it for the first frame. Ideally, I’d draw the bullet above the ship but below the turret so it would emerge naturally.
I think I’ll code a real horrid hack, which is to mark bullets as ‘n00bs’ for the first few pixels of their existence, and draw the n00bs separate from the main bullets.
That way I keep generally drawing them fast, but I also don’t get any anomalies when you hit pause and catch that 1 in sixty-off chance of seeing the frame where it looks wrong…

This is why game code looks like spaghetti. All those hacks are there for a reason I tell you!

laser beams are easy right? just a sprite yes? You work out where it goes on the screen, at what angle and what size (due to zoom) and you just blap it. Job done.

Nope.

Not if you want them to look good. There are lots of concerns. Firstly, you probably want the turret that shoots the beam to have a seperate ‘blast’ graphic rather than just a straight beam squeezing out like toothpaste. So that’s two sprites. Then you probably want them to fade out slightly at the end so they aren’t too abrupt. Thats 3 sprites (and for efficiency you need to check they are all onscreen, often only the beam will be.) You also need a wobbly seeking effect for when the beam fires but misses.

Then you probably want your beam to fade in and out over a certain portion of the (variable) beam duration. Even if its a tenth of a second fade, it still makes things look better. Then you probably don’t want the beam to be static, a sort of ‘pulsing’ effect over time makes them look better. I use (as always) a sine wave calculated over time to vary the beam intensity. That means changing the colors of all three sprites.

Then…. you will find that the beam is pretty cool, but it’s very static, and doesn’t seem to indicate direction. You can do this in one pass or two, but you probably want a seperate layer drawn on top with some ‘inteference’ that scrolls along the path of the beam. That has to be in the right direction obviously, and it needs to smoothly wrap around.

Then…. if a single weapon has several beam ‘sources’ you need them to have different start values for the inteference, otherwise people spot the patterns.

I’ve got all this in, and working and looking fab, there is just one last thing: The inteference starts abruptly just where the ‘blast’ sprite ends and the beam sprite starts. If you zoom in, it looks really obvious. So what I need is to split the inteference sprite into a ‘beam’ and a ‘start’ section, and do a sort of reverse beam-tip thing for the start of the inteference. I also need to ensure its synched with the scrolling of the core beam inteference so it looks smooth.

Ideally I also need some level-of-detail stuff so I ignore the fiddly bits when really zoomed out on small beams, and need to hook it into a general graphics options setting for older machines.

I’ll get that finished tomorrow I reckon :D