Unfortunately, as I was looking at runs, I realized I hadn't laid out emulator rules clearly enough, and so added this note to all category rules. This is standard practice for acceptable emulator runs across the site (to my knowledge). If we ever can confirm that save states don't preserve state in any exploitable way, I'd be glad to change the policy.

"For all categories where emulator is accepted, using save states, especially to initiate ILs or fastest victory, but even to initiate full game runs, is not allowed. We don't know enough about the game RNG to say that save states aren't allowing people to carry initial RNG over and grind a specific AI position in the RNG, and that's something you simply can't reproduce on hardware. If understood to my satisfaction, this policy could change. The game has the ability to quit out of fights and rematch which should be sufficient."

I added a discord link for people who want to gather and discuss the game amongst each other, now that we have, uh, some runners!

Welcome to the boards to a group of tight homies who submitted for Fastest Victory %. As some of their submissions indicated, at this scale ms actually matter, and so I enabled milliseconds for timing. To be clear, in the two full game categories, you're using IGT, so ms aren't measured or considered, however, in ILs and Fastest Victory%, RTA ms is the expected timing, so I'd definitely recommend everyone re-time their submissions in the future to get the most accurate timing. I might go back and fix up the two that weren't re-timed to have a more accurate time.

Again, welcome and thank you having fun with the game!

Heya everybody! Going to note some adminship changes and some of what we've done in an immediate sense.

First, Megami has retired, and elevated Me and Zophar to super admins, as two of the active runners of the game. Our first actions were to define the rules for the game and category which, simplified, are 'from gaining control to final hit' for timing. This meant having to retime a few of the older runs, but all for the better in terms of their times! We aren't going to be requiring hard frame timing unless we need to resolve a tie, although by all means frame-time your runs. (Our current setup is detwitch (the website) into avidemux (the software).)

A few weeks back I also added a resource on the things that I'm aware of being true in the game. If people know things that I have misrepresented, or didn't capture, please come and let me know, I can be found on discord or on what is our current discord (unless this place gets more active), which is Zophar's discord and linked in the main page.

That's it for the notes, back to enjoying the joys of Jim Hydlide.

So community member Vaan has come up with a neat little thing, but it's a little weird category wise, so I'm looking to gauge the temperature of the community on it.

If you press the two directions of a diagonal movement on two different input devices as understood by Crystal Project (one keyboard, one controller, typically), you move faster than if you press those same two directions at once on one device.

Thanks to mapping software, you can put both keyboard and controller inputs (as understood by Crystal Project) on one controller (it's possible other mapping software could let you put them on one keyboard as well, but Steam's native mapping software appears to be controller-only). One simple example of this would be to map controller up to the W or Up key, controller down to the S or Down key, controller left to controller left, and controller right to controller right, as shown here: https://discord.com/channels/962072796454866944/962072796454866947/983351622623191060

Movement still seems bounded by the same maximum speed in cardinal directions: this only allows you to get the same speed in both cardinal directions along the diagonal. For example, attempts to make cardinal direction long jumps (such as the legendary tar to castle w/an owl) are no more successful here because it doesn't break speed along cardinal directions.

The question, then is where these two tech uses should live in terms of categories/variables: Is this a one player two controllers thing inherently? If it isn't, is it unrestricted (our current maximal options category), all categories, a new category, or a variable on a category? And should we require one use the two devices (which would imply hand camera verification) or allow controller mapping for 1-1 inputs? What restrictions/enforcement/verifications on controller mapping would be necessary, if any other than just '1-1 in-game buttons'?