Difference between revisions of "Ali/BumbleBee"
< Ali
Jump to navigation
Jump to search
(migrating from old wiki) |
(Use syntaxhighlight) |
||
Line 150: | Line 150: | ||
==== Implementation issues ==== | ==== 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, <code>BumbleWave</code>, too. The new stuff looks like so (as always, my code is covered by the [[RWPCL]]): | 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, <code>BumbleWave</code>, too. The new stuff looks like so (as always, my code is covered by the [[RWPCL]]): | ||
− | < | + | <syntaxhighlight> |
class BumbleWave extends Wave { | class BumbleWave extends Wave { | ||
... | ... | ||
Line 219: | Line 219: | ||
} | } | ||
} | } | ||
− | </ | + | </syntaxhighlight> |
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. | 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. |
Latest revision as of 07:03, 1 July 2010
- 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.