Auntie Tass

[Dacicus]

A question came up on the TASVideos Discord some months ago:

if you were developing an "anti-TAS" game (a game that's purposefully made to be nearly impossible to optimize) for a system that runs in Bizhawk, what measures would you take?

This game implements my response:

Make some key game mechanic depend on OAM decay in the NES.

It turns out that that idea will not work on all versions of the NES, so this game measures PPU open bus decay as a back-up plan when it cannot read from OAM. Many thanks to CutterCross, Fiskbit, lidnariq, RatcheT2498, and Zeta on the NESdev Discord for assistance with understanding these concepts.

Note: The goal of this project was to make something "anti-TAS" in the sense that emulator-recorded movies will not console verify consistently on authentic NTSC hardware. There are other ways to TAS that might work. Also, I have not tested this on real hardware, so who knows what could happen.

[tepples]

It depends on the format of the emulator-recorded movie. Many emulators lack granularity tighter than a frame for recording timing of button presses and releases. (Such emulators also have trouble running Spot and Quattro Sports.) Five years ago, I made a demo called Telling LYs that cannot be completed in such an emulator.

More generally, you're looking for hardware behavior that approximates a true random number generator (true RNG), the kind of information that a game could use to seed a pseudorandom number generator (PRNG). On a tip from kevtris, I made Pretendo way back in 2013 that exploits bus conflicts in the PPU.

Or make a game released in 60-pin format only, and have the game depend on the relative timing of when the CPU and PPU start. Bonus points for checking that the game isn't running on a front loader through riding the open bus from $3F16 to $4016.

[Bigbass]

Just heard about this and decided to do a little hardware testing. Can confirm that replaying a TAS on real hardware is unlikely to succeed (couldn't sync to a quick TAS I threw together; initial state of the game was always different). The game is still "TAS-able" though, as in, you can still make a TAS in say BizHawk, and it'll still sync on that emulator. But replaying on hardware is ineffective.

I'm only roughly familiar with OAM decay; just what's written on the nesdev wiki. While it's already possible to manipulate the system for situations requiring a specific initial RAM state, and while I have an idea on how to adjust for the alignment of the CPU/PPU clock dividers, I suspect OAM decay will be significantly harder if not impossible to deal with.

Could you elaborate on how this game is relying on DRAM decay? I'm guessing you're seeding RNG after waiting for the data in OAM to decay?

[Dacicus]

It depends on the format of the emulator-recorded movie. Many emulators lack granularity tighter than a frame for recording timing of button presses and releases.

True, but my goal here was to make something that did not depend just on the timing of input. I did read through some of those threads that you linked as I was searching for ideas for sources of randomness.

The game is still "TAS-able" though, as in, you can still make a TAS in say BizHawk, and it'll still sync on that emulator.

Right. I imagine it would only desynch if the emulator somehow randomizes the start-up RAM state and does not save that info in an input file.

Could you elaborate on how this game is relying on DRAM decay? I'm guessing you're seeding RNG after waiting for the data in OAM to decay?

Yep, using the decayed data to seed the two RNGs. However, I also disable rendering during gameplay in order to allow OAM to decay and then use that decayed data to determine the spawn location of the next berry when you pick up the current one. There are somewhere around 50 scanlines without rendering, everything below the outline of the playing field.

[Bigbass]

Could you elaborate on how this game is relying on DRAM decay? I'm guessing you're seeding RNG after waiting for the data in OAM to decay?

Yep, using the decayed data to seed the two RNGs. However, I also disable rendering during gameplay in order to allow OAM to decay and then use that decayed data to determine the spawn location of the next berry when you pick up the current one. There are somewhere around 50 scanlines without rendering, everything below the outline of the playing field.

Thanks for the details. Are you performing this RNG seeding process on every frame, or just once at boot?

[Dacicus]

Are you performing this RNG seeding process on every frame, or just once at boot?

The seeding occurs just once at boot, but the RNGs get advanced multiple times during each frame.