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

Fixing a few obscure, but nasty bugs

I’ve found a few big bugs that people don’t seem to have spotted, or at least, not in the numbers you would assume would have spotted them.
First is a bug relating to how bonuses are applied to modules. In code terms it was a fairly standard ‘doh’ mistake where you override virtual functions but forget to call the base function in the derived one. (obviously sometimes that’s legit, but here it was a mistake).
The upshot of this is that for some modules which had certain bonuses, such as shield modules, the base hull bonus got skipped. It was calculated ok on the design screen, but not in the battle. As a result, there are a lot of ships that are partially missing their hull bonuses, until now…

The second bug is less of a bug and more of an unintended consequence. Because of the way target priorities were calculated, they were biased in favour of targets that were just outside minimum range. because optimum range is nearer to maximum than minimum for most weapons, this meant a few sub-optimum targeting decisions were being made.

The good news is I’ve rewritten that entire section of code that makes target selection decisions. The bad news is I need to do some serious testing to ensure this is an improvement, and doesn’t break everything. I suspect that for the first time, I may need a few volunteers from the beta players to install a ‘trial 1.16 beta patch to see if it’s safe to roll out to everyone else. If I do that on Monday, I can aim to release the full 1.16 update a few days later, and then we are getting very close to starting work on a demo and an actual releasable final game.
Yay!


5 thoughts on Fixing a few obscure, but nasty bugs

  1. You could use the Template Method pattern. Never override, implement the gaps.

    i.e.

    void Entity::UpdateEntity()
    {
    preUpdateEntity();
    // stuff
    postUpdateEntity();
    }

    Pre- and post- are both pure virtuals. Implement them in the base class (possibly empty bodies). That way the base class controls flow, which is probably typically what you want.

  2. Well the problem is just writing cod without thinking about whether or not I need the base class implementation here. Or more accurately, its changing the base class implementation and then not realising that I have overrriden that function elsewhere and that I need to go change them.
    Whether it defaults to running or not running, the coder still needs to remember to check that its the right way round :D

Comments are currently closed.