The system works by taking into account maximum distances achievable in all directions in a certain amount of time given its current velocity (EscapeEnvelope / EscapeArea) and rotates that in accordance to the targets current heading. The field is then segmented two dimensionally, which starts at a very low level of segmentation and which proceeds to become finer as more data is collected (DynamicSegmentation?). By segmenting this data by velocity and heading if the target appears to be not traveling perpendicularly, a result quite similar to PatternMatching is then achieved.
Firing takes place by selecting the angle which will pass through the highest probablility areas.
While this proves to be just as effective as regular GuessFactorTargeting against RandomMovement, has a much better hit rate against basic patterns, and is easy to modify to attack high or low guess factors.
This is a combination of me being tired of getting only average hitrates against most patterned bots, and the conclusion that the wave surfer vs guess factor challenge is just going to end up in a method of constant second guessing of yourself (he will think I will use guess factoring, so he will move to the low factors, but then he will think im thinking that, and so he will move to the high factors, but he will think im thinking hes thinking that so he will move to low, etc...). -- Jokester
Ah, you just reminded me what my hangup was on this before - if I don't calculate things based on the current heading of the enemy rather than on the angle to me, I didn't see a consistent way to project it back for targeting if the enemy was facing a different direction relative to me.
However, if that proves to not really matter, or there is a good way to map back to the differently proportioned escape envelope, then I think the whole algorithm is MiniBot-able by using AffineTransform? cleverly (maybe, unless that way to map it back makes it unhelpful). -- Kawigi
Well I really need to try using this AffineTransform? class. I am currently mapping the escape area as a rectangle (it works fairly well because the unreachable areas just never get incremented) and then basically rotating the entire battlefield so that the enemy has a heading of 0, only changing my relative point. I then calculate the best angle based on that, and reverse the process to get the exact angle I need to fire at. If I can change this around and be able to rotate a polygon around a position I will be able to drastically reduce code size and use my algorithms for the definitive shape. -- Jokester
Ok, so I basically have GF split into 3 sections:
In my opinion, 2 is the heart and soul of a good GF gun, and so that is what I am working on. At the moment, I have a Factor class which is basically my wave, but which contains all information I might want to segment on. A major plus of my 2D system is that it removes the need to segment on heading, velocity, etc, since that is directly applied on my information (although I am still keeping track of them in my Factor class just in case). I am incredibly fond of the WikiTargeting idea, and am currently trying to implement it, but I need to come up with a good way to decide which segment is best. The three ideas that I have been working with are the most even split (closest to 50/50), the best entropy split, or there is the obscure point split that is mentioned on the WikiTargeting page (choosing the one with the highest sum peaks??? 865 vs 687?). my current segmentations are:
All this work with segmentation has made me think about an exploitation of highly segmented guns. To try to flatten your profile not just by GF but by segmentation, so the main aim is that they dont have enough data in their segments. It will probably turn out to be wildly inefficient and not give much return (mostly because to have best effect you need to know the segmentation of the opponent), but it could be interesting to watch the bot go around through all possible velocities, acceleration states, headings, etc. -- Jokester
Well I am still toying with the efficiency problem, but I have a few ideas. The processor power required is exponentially related to the number of segments there are to deal with, and the way you decide which implementation to use. I am currently working on two versions together, an ideal version of WikiTargeting if it had all the processing in the world, and a very basic version which splits data as equally as possible and doesnt go back to check the accuracy of early segments. One thing that I will need to test is how nessecary segmentation is in the face of GuessFactor2D, because it is mapping guess factors based on all of those variables. Ive currently been splitting my time between about 12 different projects, so over the next week or so I am going to spend my robocoding time just on this targeting to try to get it finalized. --Jokester
Looking back at my own WikiTargeting ramblings, the 'ideal world' version (as you call it) *is* available if you are willing to use prepopulation. You can write an offline program that converts raw data into a bunch of dynamically segmented SuperNodes. This is in fact the initial WikiTargeting way. The existence of SuperNodes has allready been proven, so this should work. Although there are those in this community that do not approve of prepopulated guns.
I think your second version may not work so good, unless you have come up with an ingenious solution. I have thought about such an implementation too and using that scheme you will either segment too slowly, or you do not have enough waves per node. --Vic