Rednaxela/SingularityGun

Well, I was thinking about targeting some and I had some thoughts that led me to start working on a new gun. Firstly, most log-based guns like 'traditional'-DC, TronsGun, and traditional-PM have different ways of finding/rating similar situations in a log. The two main styles are:

• DC-style (including TronsGun)
• PM-style

And each style tends to excel in different areas, but really, why not combine them? In my new gun, I attempt to make a hybrid using the following method:

1. Use a normal KDTree to find candidates for similar situations, like a normal DC gun.

2. For each situation, step back through the logs to see the closeness of the match over a number of ticks

3. Use the following weighting algorithm:

w = 1/(1+a) + 1/((1+a)*(1+b)) + 1/((1+a)*(1+b)*(1+c)) + ...

Where "a" is the distance between the current situation, "b" is the distance between situations in the tick prior, and so forth.

This means that it will look for strong matches to the situation this tick like a DC-style gun does, but is also aware of temporal patterns like a PM-style gun. In order to adjust it's sensitivity temporal matches, you can use a multiplier on the distance values (a higher multiplier will mean it will care about old situation matches less).

So this looks sounds like a pretty nice hybrid situation matching to me, so what is needed next? Some kind of prediction based on the situations of course. So what styles are normally in use? Well, I'd say:

• "Play-it-forward" (traditional-PM and TronsGun)
• GuessFactors ('traditional'-DC)

Each of which excels against different movement classes. So why not have both? So I'm combining the following prediction methods using CrowdTargeting:

• Absolute "Play-it-forward" (The most common kind)
• Wave-Relative "Play-it-forward" (A special type, that's relative to the wave origins you'd expect a typical surfer to move relative to)
• GuessFactor prediction

A combination that I think would quite effectively deal with most things out there really. So far I have the data-logging/storage code done, and am working on the code to find the DC/PM hybrid matches, and then predict based on them.

As for the name... Well... I think this gun kind of is a 'singularity' of DC, PM, "Play-it-forward", and GuessFactor techniques. =)

---

Any comments/questions? =) -- Rednaxela

I like it, I have some similar ideas of extending/modifying my DC gun. And it's something I could try without much coding. Most of my latest attempts at improving my gun have been in the "multiple choice" part, your "PM on the DC log" sounds like a good thing to try next. :) -- ABC

A while ago I thought of something along similar lines, but never got around to implementing it. It was a pattern matcher that matched the last x velocitys using DC instead of absolute matches. Just like regular DC, except the attributes are velocity, velocity 1 tick ago, velocity 2 ticks ago, velocity 3 ticks ago etc, maybe coupled with delta-heading or lateral velocity coupled with advancing/retreating velocity instead. The attributes would be weighted so the most recent data counted the most. I asked Simonton to do a test of the KDTree using 30 attributes, and it turned out to be really slow (slower than without a tree). But this might be a cool way to get around that problem =) I could mod my gun for this in next to no time, but I think I'll give it a day to stew first. And I want to get my "Play-it-forward" gun working up to the standards of the GF gun, now that I got the biggest bug out. -- Skilgannon

Interesting thoughts there. Indeed, many normal DC guns could be modded fairly easily to hybridize the situation matching so long as their logs are in a format that works for it (my old DC gun wasn't suitable because it stored things purely in the KDTree as opposed to a log that could be iterated). Right now I manged to get the situation searching code and the GF-prediction working and am testing a first revision of this gun, with the hybrid DC/PM situation matching but no "Play-it-forward" yet. I'm running TCRM on it and what seems particularly interesting is so far it's FloodMini score is unusually strong despite using pure tickwaves and no gunheat segment, which may indicate that FloodMini has some kind of particular weakness that isn't visible until you take the "time" dimension into account. When I have enough seasons I'll run a version of the exact same gun but with the 'pattern-depth' turned down to 0 in order to see how useful the hybridization of situation matching actually is. So far it's scoring higher than anything in RougeDC/TargetingLab that doesn't use "wait-until-aimed" (and SingularityGun doesn't either right now and would likely improve scores a fair bit to use) so things are looking promising. -- Rednaxela

I think I've given up on the Play-It-Forward. There are absolutely no bugs as far as I can tell. After seeing any situation it can hit Spinbot/Walls? pretty much 100%. But it still loses a LOT of performance against the real random movers, like Raiko. So I tested it vs. my GF gun against Spinbot over 100 rounds, and the difference was about 50 bullet damage. Almost nothing. So I think I'm staying with GF for now =). I've hacked in some of these 'singularity' ideas, and I'd be interested on how it does with the 'time weighting', seeing it already has 4 time-dependant attributes that it is clustering on (distance last 10, time since decel, time since dir change, current GF). It already has a 'high' FloodMini score, as you noted for your gun, which I put down to all these time-based attributes. I think it helps pick up what is otherwise picked up with a gunheat dimension, because the gun is fired at regular intervals. I'm starting a TCRM now, update tomorrow morning. -- Skilgannon

First attempt results aren't that good - in fact it only helped against FloodMini, Fortune and RaikoMicro. It brought the overall score down to 90.08. I'm now trying some other tweaks, including a 'multiplicative' DC distancer. -- Skilgannon

I've tried hacking this method into my gun. I used it only to choose the angle to shoot at from a cluster (N=100) instead of my current method(s). Tested a few times against some TC2K7 random movers, the results were always worse than without it. Maybe I'll try it in the clustering code, but that'll take a bit more time. -- ABC