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

Month: March 2009

Multiple beams and turrets!

At last I’ve got around to adding laser turrets to the ships, so the beams don’t seem to blast out of just anywhere any more. I’ve also added support for multiple beam origins per weapon, and for them to be different to where the module is placed on the ship design blueprint. This leaves the blueprint looking functional, whilst allowing me to spam a few laser turrets on the bigger ships. It also means you can have a battery of lasers that all zap at once. Maybe eventually I’ll introduce minor delays or other cleverness to make them seem more independent.

There isn’t really a connection between the weapon type and the number of turrets you get with it, but it has no gameplay effect, and is purely visual. So some ships have a slot that links to multiple turrets, and placing a beam laser there will ‘spawn’ multiple turrets, whereas the same weapon on a different ship gets just one.

I don’t think it matters, there is zero connection between the two phenomena in Eve online, and it doesn’t seem to bug people. The main thing is, it looks cool, and I hope, somewhat gratuitous:

Bad Customer Service. Why is it still here?

I’ve recently ahd the displeasure of dealing with both sony and dell for customer service. Dell are supposed to e sending me a laptop, but it’s not here. Naturally, like all megacorps, they cant be bothered to actually *care* if you get the product, so they outsource this vital part of their business to some third party who ignore emails and have a broken website with an order tracking form that returns blank pages in all 4 browsers I tried. I outsource part of my business (credit card payments) to BMTMicro, and I KNOW they are damned good, because I tried RegNow, RegSoft, FastSpring, Plimus and BMT.

The bit that bugs me is that emailing dell themselves means that you get a reply in their business hours, which is mon-fri 9-5pm.

lets look at that again:

Mon-Fri 9am-5pm

What is this? 1970?

Dell are a HUGE and GLOBAL corporation. They can afford to employ a skeleton staff over weekends, or even (maybe I’m out on a limb here) to work from 8-5 or 10-6 in overlapping shifts?

If you emailed me this morning for tech support, or customer service, you got a reply today. Today is a Sunday, and Mothers day. I will answer your email the moment I read it. I am a one-man company. I sincerely hope that in this recession, discerning customers learn to punish the companies that treat them badly, and reward those who treat them well. I know I will :D

A day optimising the debris

I love the debris effects when ships get hit or explode, but they are expensive because it creates so many objects, so today I’ll be optimising so I can expand the extent of them. Some of the debris is transitory (fades out) and roughly 1/4 of it stays on-screen all the time. It all spins, but it stops moving over time.

Currently the call to draw the debris makes up 3.49% of the time spent drawing the battle screen. That might not seem like a lot, but if I want to triple the amount I can draw, and support bigger maps, it could get out of control.

It’s 9.15Am and I’m starting to code a faster system. Currently, every single speck of debris is stuck in a big global list and I go through and draw each one, although I reject them very fast if they are offscreen. This is very slow though. At least 20% of the draw time is spent just iterating through the list. My proposed solution is to stick each cloud of debris into groups, and do the iteration of groups (rejecting obviously offscreen groups) and only go through individual specks if the group is visible. I think that should speed stuff up a lot.

9.30 Am. First test shows it’s dropped to 3.74%. Hardly a mind blowing improvement.

9.33 Am: Ooops, that’s the wrong exe being profiled. I need to set up a new project configuration (release symbol). Damn. That means total rebuild. Time for tea.

9.55 Am Somehow I can’t get this poxy release build + debug symbol build to run. grrrr.

11.00 Am Still getting my builds fixed. I have a debug build which runs with optimisations on, and that seems to at least work. Also I now cache the debris texture pointer so I’m not doing a string search every frame to find it.

11.30 Am. New system seems tons SLOWER. I need to flip back and forth so I can verify this is really true. It seems to be because of my use of STL lists, when each cloud of debris has very few members. I need to ensure my code isn’t using debug STL before going any further. It’s the same even with release, so I’m ditching the new system and will optimise the old one.

11.45 Am Creating and destroying debris objects is very slow. I’m going to have a fixed array rather than a global list, and use a series of flags instead. This does seem to be a bit faster, and makes much simpler code. However, the fixed array size and the method for finding an inactive debris item is inefficient and doesn’t scale at all.

12.15 PM Simple but major speedup. I was always searching the whole array, whereas clearly the solution si to always start the array search from the item one above the last one which was available, and wrap around. That sped up debris initialising by a factor of five. Time for Lunch!

1.30 PM I’m now precalculating some of the data thats used identically by each bit of debris and passing it to the update function. It’s maybe 20% faster. I just spotted I’m checking for alpha < 0 even for debris whose alpha does not fade. Fixed!. Ideally I need to update almost nothing for debris that’s offscreen, and yet have it still behave sensibly when it then appears onscreen later.

1.51 PM New system where I mark out debris that has practically stopped moving, and omit any further position updates for them has reduced the update time by another 20%

3.10 PM New graphical debug display shows me which debris array entries are persistent, in use and unused. Took 2 minutes, but its very helpful. May attempt a system to ‘defrag’ the array now.

4.10 PM Defragging system works great. Time to double the amount of debris everywhere and see how it all holds up.

5.45 PM Everything looking ok. Probably need to add some nice smoke effects at some stage. Time to work on gameplay code.

nail-biting Exchange rate woes

I generally get paid in dollars. Even if you buy my games in Euros, it gets converted to dollars before I get it. That’s just the reality of internet commerce these days.

So when the dollar is strong against the pound, It’s good for me, because I get more pounds, and thus I can afford to not buy economy bread to live off.

I’m currently waiting for a big fat payment from a publisher for my games, and the exchange rate is gyrating wildly. The US government just blew a trillion dollars on bailing out banks etc, and that made the dollar nosedive. Why can’t these insensitive fools wait until I’ve collected my royalties? Grrrrrrrr.

I have tons of cool stuff going into GSB, but I’m hoping not to bore everyone with screen shots too early. Today it was time to do the ship name selection GUI and tidy up some of the explosion code. There is so much to do in this game to get everything looking acceptable at both normal and 4x zoom.

Alien races

I’m starting to get artwork for the second of four ‘fleets’ for the game. What this means is that it’s time to organize in code and data which ship belongs to which species.

Because this is a game about gratuitous space battles, I could go two ways:

1) I could devise very tongue in cheek backstories for each race, I was thinking of maybe having a race of brutal aliens who are psychologically driven to violent warfare due to the number of apostrophes in their names etc.

2) I could drop any pretence at giving a damn about backstory and call them generic names like “The Alliance” “The Rebels” “The Federation” “The Empire”. Etc.

I’m also toying with the idea of a random space race name generator which names your four races on first install, so that you have different names to them from everyone else.

Ho hum.