Bots and Simulations > Tips and Tricks

Shot Projection/Position Prediction..

(1/2) > >>

rsucoop:
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.


--- Code: ---(((Sin (theta)) / (myx - yourx)) * velocity + (Sin (aimshot) / (myx - yourx) ) * 40) * time to shot hit
--- End code ---

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.


--- Code: --- F = M * A
--- End code ---

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.


--- Code: --- F = M * A = M * (vel3 - vel2 - vel1) ^ t
--- End code ---

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.

Moonfisher:
I don't think Sin is suported either
I couldn't find one when I was trying to figure out my angle from an oponents point of view... ended up just using the angle operator to find his angle and add 682...
It still didn't help with my idea of having a controlled alge shoot at enemies... it's easy to find the enemy's angle from my own bot, but I can't get the angle from the alge without using sin or tan and I don't see them listed as operators and I don't know how to to do that manualy if it's even possible...
But that was for my first bot (ebola) and I'm working on different ideas now anyway

I think guardian uses shot prediction... but it also causes heavy lag with just a few of them. (I guess you can't steal it without it being painfully obvious )

Numsgil:
sin and cos just never got added.  No real reason why, I guess it just never was a priority.

rsucoop:
well, they are ratios with many decimal places, and decimals really were never supported. So then what about the Square Root function? How well does it work? Let me check my geo notes.... Good ol spark notes.

Ok. Using two or more eyes to accurately look at the target, we can form a number to be its width. The number really requires Sin and Cosine to work, but in our case we can just use the input from eyes to determine this. The bot should be dead center if your bot constantly tracks its every movements. You can assume that the number is not all, but each focuseye would have to cycle to accurately show whats in the area. We know the angle of them from us based on our aim, and the amount our eye has turned. The purpose of Sin Theta was to find a length to use, or a vector of velocity. One way to avoid the bot from getting away, would be to shoot two shots, one towards the left by some measurable value, and one in the direction it is already moving plus another measurable value. If that fails reproduce a leach and through it with a tie to the victim and have it feed and erturn nrg through the tie to the parent.. Either one is difficult, aiming or leaching, but are very effective.

What if we added Sin and Cos? The functions exsist in nature.

abyaly:
As far as trig functions go, you only get the angle operator.
"A B angle" = arctan ( [B - myY] / [A - myX] )
in DB angle units.
Although if you really want sine and cosine, you can use polynomial approximations. I'm pretty sure that's what trafalgar did in Guardian.


The velocity vectors are already given to you. They don't need to be calculated.



--- Quote ---Either one is difficult, aiming or leaching, but are very effective.
--- End quote ---
Prove it

Navigation

[0] Message Index

[#] Next page