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

Category: gratuitous space battles

Turrets

I’ve finally got code written that supports the same ship module having different sprites on different spaceships. What this means is that the same weapon (fast pulse laser) can look different on a rebel ship to a federation ship, so hopefully they don’t ever look too out of place.

This works fine, but right now I’m assuming I’m using the same hi-res 3d image for the weapon on the ship design screen, regardless of which ‘race’ the ship hull is from. I have several ways to fix this, none of which are ideal…

I could have different 3d renders for each turret on the ship design screen, depending on the race of the ship hull. This is a lot of work, and also might be confusing. Shouldn’t the player be able to recognise a pulse laser icon regardless what race he plays?

I could have a generic 3d image for the design screen, but represent it differently on each ship, which is easier, but it means breaking the visual connection between the 3d render and the 2d sprite which might be confusing.

I could scrap the idea of the turrets representing individual variations, and just have 3 or 4 turrets for the battle screen, and tons of different 3d ones for the design screen.

I really like the idea that placing a turret in the design screen reflects exactly what the ship will look like in battle. However, it doesn’t really matter in gameplay terms, and ease of use on the design screen is the most important thing. Maybe I keep all the data the same, but have different sprites and 3d renders depending on the selected ship hull. In any case, there is tons of 3d modelling, rendering and data entry to do…

Escorts and formations

I got the code in today for ships to escort others, and for formations. There is a very clunky ugly GUI for setting it up, which needs fixing at some point.

Basically, in the deployment stage before a battle, you can add orders to each ship which will instruct them to escort or fly in formation to a specified other ship. If that ship is destroyed, the orders get ignored. Escorting is the same as saying “Do what you want (according to other orders) but dont get more than x meters from this ship.” Formation is the same as saying  “Always remain at this exact offset in X and Y terms from the specified ship”. The formations are in world space, not relative to the parent ship, and this seems to work best.

It seems to work (although I havent’ tried fighter formations yet), and I can see already it will lead to much more strategy in the game. You can set up ships to be flanked by other ships with anti-fighter lasers, thus providing a screening layer for a cruiser which might have invested in big guns and not have room for anti-fighter modules.

Plus a group of cruisers or frigates flying in formation looks pretty cool, especially after I fixed a silly bug which meant 75% of the laser bolts were not getting drawn. It’s real mayhem now :D

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:

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.