hohav / peppi

Rust parser for Slippi SSBM replay files
MIT License
37 stars 9 forks source link

Add initial stat support for action counts #11

Closed NickCondron closed 1 year ago

NickCondron commented 2 years ago

~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 of Vec or we implement a macro that makes working with Frame<N> more reasonable. However, I've never used const generics before; maybe there's a better way.~ EDIT: I figured out this part

I 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.

NickCondron commented 2 years 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.

NickCondron commented 1 year ago

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.