Closed NickCondron closed 1 year ago
The action counts have reached or surpassed feature-parity with slippi-js action counts. Only exception is that slippi-js has logic to differentiate tech rolls based on player position. I skipped that part because it's only valid for 2-player games. 2-player specific stats can probably go somewhere else.
I enforce a v0.2.0 version medium because accurate action counts are impossible without state_age
. Currently the code panics if an earlier replay is provided. I don't know the best way to handle that case given the version is not encoded in the type system. v2.0.0 adds l-cancel info, but that is left as optional.
Some tests were 'borrowed' from slippi-js, but I don't feel bad because I wrote a few of them. Could probably use more tests for wavedash/dashdance
Chose to make each action count u16
instead of u8
. I think there might be some cases where an action could exceed 255 occurrences, especially in non-competitive formats.
Closing because I plan on rewriting this once I figure out a better interface for it. I'm happy with the nuts and bolts of the implementation, but currently the types are clunky. I like your suggestion of making stats be its own crate.
~This is a draft because~ I'd like your input on how best to setup an interface for computing game stats like slippi-js does. Initial stats we will compute will be action counts because I implemented it in slippi-js, and I know how it works.
~Currently my main issue is that the
Frame<N>
type is clumsy. Seems like we either bite the bullet and implement a conversion to some sort ofVec
or we implement a macro that makes working withFrame<N>
more reasonable. However, I've never used const generics before; maybe there's a better way.~ EDIT: I figured out this partI want the interface to be idiomatic and not just copy what slippi-js does. I need help with the design. Implementing the calculations is more straightforward.