Not sure what's going on here, but it seems to be returning an array/list of length 0.

The other 2 ships just maintain their original positions.

Should return the entity that is in the vicinity, or None. Code outside of the method can handle determining an intercept angle or whatever. It's far too specific to have the method handling that; destroys the point of having things modular.

If there is a planet within offensive range when going offensive, check to see if the majority of its docking spots are taken up by enemy ships. If so, ram the planet (maybe check to see if enough reinforcements are on the way to destroy the planet, first).

Undocked ships are spending too much time alternating between chosen targets. Not as many planets are getting reinforced as a result, and more collisions are resulting, lowering effectivenss. Another issue with the algorithm at this point is that heavily reinforced planets will mine until the planet explodes, destroying all docked ships and causing damage to any ships in the vicinity. A good improvement would be to have docked ships determine how much mining capability is left; if the planet is going to detonate soon, ships can undock and put the planet on an avoid list. This can be done leaving the planet as 'bait' to the opponent, who will suffer damages when they dock, mine, and cause the planet to detonate.

aaand this is totally hampering effectiveness.

I'm taking a better look through the import libraries, and it appears that I've tried (often times unsuccessfully, due to the rush to get a bot done before the submission window closes) reinventing the wheel on multiple occasions here. So before anything else, it's time to simplify the code by removing all of that and replacing it with what's already polished.

I'm not sure, at all, that I'll be able to finish this by the time submissions are closed with the Halite II challenge; however, I think that the cost:benefit analysis weighs in favor of giving it a shot. I don't think that issue #12's suggested improvements are going to help enough to warrant further work this close to the deadline.

We're going to save the state of each enemy ship for 1 turn, and use it to calculate their vector. If it intercepts closely enough with a different player's ship, or an unowned or different player's planet, that will be assumed to be the enemy ship's objective. This should assist in determining what to do next for any ship in the vicinity of that particular enemy.

Not that this is a problem right now, since reinforcement is handled automatically by target_planet() right now. There probably won't be a chance to work on this at all...

So, after 'improving' my bot with the 2nd and 3rd commits, they're all ramming into each other right off the bat. This is not a good way to win.

Monolith is getting unbearable.

Need to try to figure out why (there may be multiple areas) ships are ending up oftentimes waffling back and forth between one course of action and another. One way to do this may be to have a persistent command that will last for a duration of turns. The other way is, of course, to try to modify the decision making criteria differently.

Alpha algorithm:

• check for a ship within firing range
  • determine whether or not ships are on a collision course
    • if so, adjust course by 180 degrees and match speed
    • if not, match velocity to stay in range
• locate the closest enemy out of range
  • set an intercept course at full speed

Check the speed of each enemy; pick the enemy with the highest average speed and set our speed to 10% greater or the maximum, whichever is less.

We need to adjust our own speed depending on the speed of our opponents. We should start out at full speed to gain an initial advantage, then adjust speed to 10% above that of the fastest opponent, unless the opponent is traveling at full speed.

We're not going to bother with checking to see if each other player has ships traveling at various speeds.

1. If my current ship's health is lower than that of the enemy it is engaging, ram it.
2. Do the same if such isn't the case, but my ship is outnumbered in the vicinity.

We've already successfully targeted planets, in order of closeness, that aren't yet owned. I think a good next step would be to add to that a determination of whether or not the other players' ships are closer, and more likely, to get to the next target than our own. If so, it would be a good idea to reinforce any existing planets that can take more ships, first.

After this point, if there are no more planets that require reinforcement, it's time to start going after enemy ships.

Code is getting difficult to maintain due to the monolith size. Time to split it up.

There's starting to be a bunch of data in there; the process/gather methods could be thrown into this object as well, for maintainability purposes. Once again, I don't think there'll be time to handle this, but maybe...