DC and VCS

Jump to navigation Jump to search

It's worth noting that in movement, you have far less data, so CPU speed is less of an issue. Until you get into flatteners, and even then maybe virtual wave flatteners (which are rare), DC surfing could probably do fine without even using kd-trees. Precise prediction far outweighs information management, I think.

And yes, having a dimension that is pure linear time is certainly one of the simpler approaches to KNN data decay... ;)

Voidious17:50, 29 May 2012

What I was actually doing in my gun was having a non-linear time dimension, and it worked out a lot better than straight linear. I think I ended up with 1.2*T^(0.4) or so, instead of 0.005*T. Those weights were genetically evolved with my WaveSim-ish setup.

It makes sense that at the beginning you want your data to decay faster than towards the end...

Skilgannon18:33, 29 May 2012
 

I've generally considered the time dimension a pretty blunt/naive approach (I think I used it in Lukious), but I've been mulling it for the last hour and now I'm thinking it's actually pretty reasonable. I might even tinker with it some in Diamond (especially now that I have your secret formula, muahahaha!).

I know I've posted it elsewhere, but the main system I use in decaying Diamond's surf stats is like this:

  • No time dimension, but each data point is timestamped.
  • After choosing k neighbors, sort them inverse chronologically and weight them by rank. (Eg, 16/8/4/2/1.)
  • Optionally (like in flattener), I also cap the size of the log and remove the oldest points.

Tuning k is like adjusting the granularity of a VCS buffer: k=1 is like a super highly segmented buffer (most similar situation wins, regardless of age), while a larger k is like a less segmented buffer with rolling average.

While I've tried this in my Anti-Surfer gun, too, the most effective decay I've found there is just capping the size of the log and discarding old points.

Voidious18:59, 29 May 2012