Ali/BumbleBee
Jump to navigation
Jump to search
- Ali Sub-pages:
- Ali - Version History - BumbleBee
An experimental "fuzzy matching" GuessFactor Targeting gun based on CassiusClay/Bee.
Targeting Challenge (original)/Results/Fast Learning (TC35) Performance
I'll try to track BumbleBee's TC35 performance here. Together with the current top competition for reference.
Name | Author | DT | Asp | TAOW | Spar | Cig | Tron | Fhqw | HTTC | Yngw | Funk | Total | Comment |
CassiusClay 1.9.6.10 | PEZ | 81.49 | 93.41 | 99.76 | 97.96 | 83.97 | 85.20 | 95.21 | 85.83 | 97.57 | 89.71 | 91.01 | 15 seasons |
Shadow 3.06 | ABC | 78.85 | 90.24 | 99.63 | 98.45 | 83.23 | 87.43 | 93.95 | 89.67 | 97.86 | 88.99 | 90.83 | 15 seasons |
Pugilist 1.9.9.7 | PEZ | 81.05 | 91.69 | 99.85 | 98.14 | 82.11 | 84.79 | 93.54 | 85.74 | 97.45 | 88.97 | 90.33 | 16 seasons |
Ali 0.2.5.6 | PEZ | 80.74 | 92.06 | 99.77 | 96.72 | 78.96 | 83.03 | 95.95 | 85.41 | 97.86 | 89.11 | 89.96 | 33 seasons |
Raiko 0.43 | Jamougha | 80.02 | 89.93 | 99.63 | 97.65 | 81.63 | 84.23 | 95.92 | 85.19 | 97.20 | 88.06 | 89.95 | 16 seasons |
Phoenix 0.2 dev | David Alves | 74.20 | 89.98 | 99.88 | 96.18 | 82.15 | 84.52 | 95.28 | 87.49 | 96.84 | 89.81 | 89.63 | 50 seasons |
Ali 0.2.5 | PEZ | 78.17 | 92.09 | 99.75 | 96.42 | 79.35 | 82.26 | 95.79 | 86.48 | 96.67 | 88.66 | 89.56 | 15 seasons |
DarkHallow | Jim | 76.71 | 90.34 | 99.30 | 97.42 | 80.72 | 85.74 | 95.14 | 85.35 | 96.90 | 87.59 | 89.52 | 15 Seasons |
Implementation issues
Instead of indexed segmentation BB uses normalized scalar measures. This is the only difference in the actual Gun class. Then there is some changes in the Wave subclass, BumbleWave
, too. The new stuff looks like so (as always, my code is covered by the RWPCL):
class BumbleWave extends Wave { ... static final double MATCH_THRESHOLD = 11; ... static List log = new ArrayList(); LogEntry logEntry = new LogEntry(); ... void registerVisits() { logEntry.visitIndex = Math.max(1, visitingIndex()); log.add(logEntry); } int mostVisited() { int mostVisitedIndex = MIDDLE_FACTOR; int[] matched = new int[FACTORS]; for (int i = 0, n = log.size(); i < n; i++) { LogEntry e = (LogEntry)log.get(i); double distance = logEntry.distance(e); if (distance < MATCH_THRESHOLD) { e.usage = PUtils.rollingAvg(e.usage, 100, 200); matched[e.visitIndex]++; } else { e.usage = PUtils.rollingAvg(e.usage, 0, 200); } } int most = 0; for (int i = 0; i < FACTORS; i++) { if (matched[i] > most) { mostVisitedIndex = i; most = matched[i]; } } return mostVisitedIndex; } static void cleanLog() { if (log.size() > 10000) { System.out.println(((LogEntry)log.get(0)).usage + " - " + ((LogEntry)log.get(4999)).usage); Collections.sort(log, new Comparator() { public int compare(Object a, Object b) { return (int)(((LogEntry)b).usage - ((LogEntry)a).usage); } }); log.subList(4999, log.size() - 1).clear(); System.out.println(((LogEntry)log.get(0)).usage + " - " + ((LogEntry)log.get(4999)).usage); } } } class LogEntry { double bulletPower; double fireDistance; double velocity; double lastVelocity; double velocityChangedTimer; double wallDistance; int visitIndex; double usage; double distance(LogEntry e) { double distance = Point2D.distanceSq(this.fireDistance, this.velocity, e.fireDistance, e.velocity); distance += Point2D.distanceSq(this.lastVelocity, this.velocityChangedTimer, e.lastVelocity, e.velocityChangedTimer); distance += Math.pow(this.wallDistance - e.wallDistance, 2); return Math.sqrt(distance); } }
Where Bee uses several stat buffers for efficience in both short and long term, this gun uses only the log. I guess I could increase and decrease the fuzziness in the match there to get some of that Bee quality back. I just don't know how to do that in a controlled manner.