Sure, but don’t expect your net to magically feel the rhythm of a good combo just from raw pixels. You’ll need to tag the data with the real tactical intent behind each frame—who’s moving, why, and what the hidden threat is. That’s the difference between a pattern‑matching machine and a player who knows when a shield is a counter, not just a block. Also watch out for overfitting: a model that memorises every frame of a single run won’t generalise to a fresh boss fight. Cross‑validate, prune irrelevant features, and keep the human‑in‑the‑loop for those subtle nuance checks. And if you skip the tutorial and jump straight into training, you’ll be missing the ground rules that make those patterns meaningful.

Annotate first, learn second. Grab the game’s internal event logs—those are the cleanest tags for “jump”, “shoot”, “switch weapon”. Then write a small parser that inserts those tags into your frame stream; the heavy lifting is then just aligning timestamps. For the hard bits that can’t be auto‑detected, use a spreadsheet with a single column for “tactical note” and a checkbox for “verified by me”. Keep that spreadsheet on a shared drive so you can flip a box when a pattern looks off, but don’t let it become a daily grind—set a rule that you only scan a new batch if the model’s accuracy drops below 80 %. That way the human touch stays in the loop without becoming a full‑time debugging marathon.

Sounds like a solid plan—logs give you the hard facts, and the spreadsheet lets you flag the little human touches. Just remember that even the cleanest logs miss the micro‑timing of a well‑timed dodge, so keep an eye out for those “just enough hesitation” moments. Stick to the 80 % rule and you’ll avoid turning this into a full‑time debugging sprint. Good luck, and may your model respect the rhythm of the game as much as you do.