The simplest method would be using the velocity vectors as a distance factor over time, however many problems arrise in the bots that use these (enemies use circular paths / affect of gravity on the position of a bot / friction / changes in velocity (acceleration) and so on. So we begin from scratch.
A shot travels with a set speed one direction, and recieves a constant force in the direction that the gravity has been set. So to hit a target under the influence of gravity, and only gravity, you would not have to correct for anything (I.e. make the bot stop and shoot at it a lot). But say the bot has some defensive mechanism to travel left or right (relative to your bot) with gravity, any prediction (using averages - easier) would have to sum up the velocities over time, meaning a lot of memeory dedictted to the position of one bot, and would be very impracticle for long term predictions, but for a combat situation, time is relatively small. Provided the velocities do not change because the bot finds something else to do, a differnce in velocities would not be very accurate, so we will use theta (I.e. angle relative to yours). The immediate known angle would be 90 degrees, as their would also be a right triangle between your bot and the enemy bot, unless their x or y values are =. So if the bot apears to be headed for = x or y positions, a simple side (relative) shot would make up for that movement.
(((Sin (theta)) / (myx - yourx)) * velocity + (Sin (aimshot) / (myx - yourx) ) * 40) * time to shot hit
The following returns the distance (hypotenus) to the enemy bot over the time required to hit the bot. But no where does it account for the affect of gravity, but there is no need. So I've probably confused you, but the reason I bring up gravity is because it the same thing as circular momentum (which is how many bots maneuver anyways). It would be impractical to assume that a bot traveling in one direction will not suddenly change slightly for one reason or another, regardless of Gravity, it has to do with turns and vectors. The initial jump to maxvel in one direction, creates an inertia that continues acting on the bot even after it switches direction or velocity, and that inertia is not overcome until after enough force in the opposit direction has been applied. This means that a bot that does a 180 will drift somewhat backwards, making the shot a little more difficult. But say its a 90 degree turn, now the bot has some side drift, and the new velocity vector has a minimum affect on the previous inertia vector.
F = M * A
The above formula could be used to claculate a future inertia of a bot to the next second, as long as the acceleration does not change (or accelerate). In order to calculate this, one would need to record the velocities of the bot and the direction of the bots' active vector over at least 3 seconds.
F = M * A = M * (vel3 - vel2 - vel1) ^ t
And yes, acceleration is to the power of time, derived using Sigma. Now we have an idea of the basic mechanics of the enemy bot's manuever functions, but no real way of telling how the bot will act. Algorythmic/Memory Mining Genes requrie a lot of variables to stored over the entire battle between a single bot, pushing for more short-termed style bots, but it's not very affective in the long run. As most of these variables most likely need to be used for some various important fact, (I.e. tie info). So then using some array established in the genes that record the enemy bot info for however many seconds desired, we can gain an idea for the path that the enemy has drawn. Most likely its circular or of some logorythmic function (not important). If its circular, their will be a common point of reference known as the center. Then there are radii and few other nice geometric functions to help us predict the next shot to make. So, the only method that would be practical to predicting if it is circular, requires three cycles of memory dedication at the least, 2 points of refence forms only a line, and will not be conclusive enough for any logic fuction. So we use our noggins and calcualte where this point lies (the center of their circular pattern, works for ovals and odd shapped things with circular bends I.e. uses some power of change). From that knowledge we can assume one of two things a), the bot is just going in a circle to find something or sees nothing or , the bot is about to do something unpredicted. If B is the case, we're SOOL, but if A is the case, then we have an easy target. We already know how fast it is traveling relative to ourselves, so we just take the conics formulas for a circle and plug and chug (conics are anything involving circles and other shapes found inside cones). Conics are your best bet always, there is no movement in nature which is not conical in form (regardless of friction), as the inertia caused by a movement is always there, so there are many forces acting against the goal vector of a bot.
Comparators of the differences of the points of position collected would show which conics formula to use. To make this more difficult, is the limitations of the eye and memory tool. It would be nice to record at the begining of a cycle a bots position, and then again at the end, this gives n cycle then n.5 cycle references and would be helpful with predicting accelerations of the enemy. But if you're too lazy for that and don't care about 98% efficiency, then just use Pythagorous and various points of reference. I mean things like last known position to most recent, or vel*angle + positions. Either system works, but Pythagoros does not include accelerations as accelerations are not linear, but exponential.
I have not included any ideas for genes because I want my Slim Evo to be able to out smart the bot community, but feel free to post any ideas and I will be glad to critque them. Also, I have not included any sources or theoroms, but that's because I can't find my theorom's list (plus everyone has different naems for each theorom). A more radical approach may be to use the Side Splitter Theorom, which uses a central point within a triangle, and a cricle can of coarse fit inside this triangle. The use of Geometry in DB would be way better than any algebra; but still the best would be calculous, but I don't have time for that, and I don't think imaginary numbers are supported in any version of DB.
