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

A not so trivial change

When you think about adding a feature to an existing game, it often sounds much simpler than it will be. Here is an example from today.
After a lot of consideration, I decided to add new ‘carrier support’ modules to cruisers. These would act as mobile repair yards for fighters. If you gave fighetrs the ‘cautious’ order, when suitably damaged, they will seek out the closest cruiser with a carrier module, head there, dock, get repaired, and return to battle.

Now there is a lot of code associated with the AI for doing that, and the UI for displaying it etc, but that’s all the code you factor-in and expect to write, so that isn’t the problem. The extra work, comes from all the stuff you hadn’t considered.

I needed code to prevent docked ships shooting, being tractored, being affected by shock waves, or targeted by enemy ships. That’s all pretty reasonable. Then I needed code so that on docking, the fighters would choose the most sensible module for multi-bay carriers where one was damaged, or had a big queue of fighters, plus handle exploding carriers and damaged carrier modules.

But then I started looking at the visuals. The fighters were just flying on top of the cruisers, then vanishing whilst docked. Clearly this sucked, and it would look cooler if the fighters flew ‘under’ the cruisers and re-appeared there. This would look like they docked in hangers under the ship.

BUT! in GSB ALL the fighters fly over the top of cruisers. It’s a rendering optimisation, which nobody notices. So I had to code a newer system where fighters *could* fly under as well as over the cruisers. This just means putting them into two groups randomly, looks cool, and is still pretty fast. And this is where it gets interesting.

With this cunning new system, as a fighter approaches a cruiser I can just ‘force’ it to toggle to an ‘underneath’ group, and thus it will look cool. However, it may not already be an underneath one, and it *may* be on top of a cruiser at the point at which I realise I need to do that. So there is a danger it may suddenly ‘ping’ underneath a ship horribly as I’m watching.

I can set a flag that means the change is pending, and only do it when its offscreen, but that might not always be possible. At some point I need to either just risk it, or do a lot of intersection tests to ensure its ‘safe’ to jump underneath. Ideally I flag this as something to do in a frame where there is some CPU headroom (existing code in the game checks this, and does other similar tasks in those gaps)

And there is one final hiccup. Over time, as every fighter gets repaired, they will eventually all end up ‘underneath’ cruisers. Which will not look right. I need to tag fighters as ‘needing to toggle above’ when they are next offscreen, just like I did the other way around.

This is all the code people forget about, and is why game programmers suck so badly at putting together schedules :D

5 thoughts on A not so trivial change

  1. The same thing happens to me with website projects. It starts off with me thinking “Oh yeah, that should take this, this, and a couple of those”. Then the special cases, exceptions, and general dust starts getting in the gears.

  2. Alternatively you could keep all of the fighters on top of the cruisers, and add a docking animation where the fighter hovers over the docking port then sinks into it to disappear from view.

  3. RE: the all fighters end up on the bottom thing, just keep a count of the fighters above and below, then have the emerging fighter join whichever is the lower number once he’s “outside” the cruiser’s model. You might get a pop when a fighter launches out of a cruiser directly underneath another ship, but that should be rare enough to not worry about.

    As for going to the down plane while docking … no good ideas. Intersection tests would suck. You could use a similar system and have him fly to dock then pop under just before the cruiser model. Again, problems, but possibly not noticeable ones and it doesn’t need _too_ many intersection tests you aren’t already doing.

  4. I sorted it all. There are 50% of fighters that are already underneath anyway, so thats half the problem. those not underneath need to flip under, then flip back later, but 90% of the time that’s off-screen so it’s trivial, and the other 10% of the time it turns out doing some fast intersection tests is trivial too.
    The only pain is that if you have an imperial fighter with a long flame trail, and it docks at an imperial ship that has lots of transparent points, you can detect that the particle trail clicks off instantly.
    Thats a very very minor quibble though…

Comments are currently closed.