Author Topic: Movement bug  (Read 3549 times)

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Movement bug
« Reply #15 on: June 27, 2009, 06:18:23 pm »
Awesome!

Well, it's really rather hard to explain what the issue is, since I think it was actually an accumulation of things.  The short answer is that it was basically sometimes clearing the destination when various conditions were not met, and that was causing them to not continue along their path even though the path was still there (in recent versions).  In prior versions, it was also clearing the path, so it was a double issue there.

To be a little more specific, basically the various subsystems for how to approach a target that the player assigned, how to act in attack-move or free-roaming defender modes, or how to act on waypoints or how to move between planets, were all very separate activities.  They had their own check states (so, for instance, if the ship chases a ship and then came into 90% range, it stops moving instead of going further in), and so forth.  In order to fix this, I basically had to merge all of those disparate systems together, which as you can imagine was a bear and a half.  When I had originally designed out the systems, I had not planned on that, so I had to do a lot of rewriting of them all in order to make them play nicely together.

In the various 1.008 prereleases I had pretty much fixed this issue, but then it also broke other things like ships stopping when they hit 90% range for a target, things like that.  There were so many possible use cases, it was a real challenge to figure out how to handle them all.  And some other scenarios actually figured into this, too, such as how ships act when coming out of wormholes, or how they act right after collision detecting, or how they work when they are going to go repair another ship, etc.  So it basically took me going through around 10k lines of code and reminding myself what everything did, how it interacted (and why), and then redoing it so that the assumptions are upgraded to the modern set.

I've had to do this sort of thing with large database ERP systems in the past, when a fundamental assumption changes in a major way, so I knew I'd get it but it was also just one of those things that takes time and introduces a lot of bugs.  I'd say this one (movement bug, plus the other related stuff with fixing how it handles attack-move mode and waypoints, and the wormhole-waypoints interactions) probably took around 15 hours of sleuthing and testing this week, which is very much unusually high for me.  But now, on the other end of all that, it's been modernized to the new assumptions and I have a much more recent memory of how all the smallish parts of that function.

Coding subsystems that are isolated is great, and it means you have a lot of freedom and simplicity in their design, but as soon as they have to be merged with another subsystem that can be a challenge.  This was basically merging 7 or 8 subsystems, which causes the problem to be exponentially harder.  Fortunately, most of the assumptions in the underlying game mechanics are very good and up to date, and this is not something that really comes up very often!
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!