Forums  /  Sonic 3 & Knuckles  /  Suggestions for the rules (Locked)

As there are more runners using emulator now (including me), and the rules are somewhat dated I thought I'd put forth some suggestions for the rules that bring them to more "modern day" standards. Feel free to discuss, berate etc. 😃

Emulators: Allow recent emulators, but just ban the use of Input Playback/"Movie" capabilities.

For proof of not using input playback, have a rule for showing something distinct about the emulator in use that doesn't have those capabilities (e.g. Retroarch's XMB menu,or the yellow "Reset" text), OR recommending the use of something like gamepadviewer (or Retroarch has an albeit crappy one built in), so real-time inputs can be seen - technically, this could allow emulators like Bizhawk still to be used. Obviously Bizhawk and others with input playback with an input display wouldn't suffice though so a separate display should be used.

Ditch the hard reset rule, as far as I'm aware this was for input playback emulators so they are shown as starting afresh, with the above this should be unnecessary and has parity between console and emulator.

Motivation for these:
1) There are a few emulators out there now that are cycle accurate, and even down to emulating the CRAM dots (the noise at the bottom of the screen in s3k) - telling the difference between these and a real genesis capture would be close to impossible. Having "hoops" for emulator users to jump through might just mean someone would opt for declaring they play on real hardware to avoid those hoops entirely.
2) Using input playback and having it shown on gamepadviewer is going to be almost impossible to achieve. Having a TASBot playback on real hardware would probably be an easier option 😛
3) Bizhawk uses Genesis Plus GX, which is allowed, but technically has the same features that got Gens banned.

Another rule that probably should be clarified is the save file rule - allowing starting saves that haven't completed Angel Island. Which is technically already allowed given Chronoon's PB, and is a nice small QoL improvement when running the game, given how a lot of runners will reset in AI, and it doesn't seem to affect the CN2 ceiling either.

Zaxon96Zaxon96 likes this. 

I wrote the rules initially so I think I should give my input on this.

If you do runs on emulator I do think you should be able to put in the extra effort to make the life of the verifier easier. There is simply too much variation in emulators so I think there should be a single or couple standard emulators and settings to do runs.

But the emulator scene has evolved a lot as well and I'm not up to the speed on it so if people agree on adding or removing one to the list I'm all for it.

Regarding outside programs with input view etc I do think that would be a good idea, but it has to be free and supplied here on this site, and also be supported on pc, mac and linux. Or have alternative versions that are equivalent.

BenInSwedenBenInSweden likes this. 

Yeah, the one I mention - uses the html5 spec for gamepads, so works with the browser component in OBS (apparently XSplit too), and should be cross platform compatible as well - I know it works on Mac as HDL said it also worked for him when we discussed it a while back in the discord. (also it's free).

BTW: what variation in emulators really matter when verifying? Aside from input playback, I would say the choice of emulator is fairly moot, as all emulators strive to make the game as close to the original as possible, and is more down to the way the game is played (hence the input display) 🙂


Ah if it's a website like that it could be fine.

The main problem with allowing any emulator is that someone could record footage of an emulator then just put that into the window of a another emulator and lie about what they are using. It's much easier when verifying to have a standard set of emulators with known pecularities to check for.

It's also the reason I initially had the rule about recording the entire window, because all videos I had to check before was without documented emulator so double checking what emulator something was played on to see if they lied about using a TAS-enabled one became unreasonably difficult.


I think the main thing is gamepadviewer gives an easier time for verification. Maybe it should be the requirement for using "any emulator", and relaxing the reset rule. And if not using it, keep the predefined list of emulators that need a hard reset beforehand - I would wager most would go for gamepadviewer though as it's a very minor thing to set up recording for, and is practically set and forget. But obviously we need some form of catch-all for existing legitimate runs as well.

The list does still need some clarity though, Bizhawk uses GPGX which is allowed Technically I guess someone could splice together a Bizhawk hard reset video and one with input playback to hide that it's a "human TAS", and submit it. (an issue gamepadviewer alleviates anyway). 🙂


From what I've seen, different Genesis emulators use different input displays, so as long as this feature was enabled it should make it easy to identify which emulator is being used, no?


Just to clarify the points Ben is making in simpler words:
1) If someone shows gamepadviewer, which an external tool not embedded in any emulator, it would require some serious dev skills to cheat, therefore any emulator may be allowed
2) Is someone is not, then the old rules may apply

Just to add my 2 cents, to be able to cheat with such setup (1) one would need to recompile a custom version of both gamepadviewer AND the emulator, which is definitely harder than just hack an allowed emulator to get around the "allowed emulator" rules, and is therefore a stronger security measure.

BenInSwedenBenInSweden likes this. 

I would say using the built in emulator input display should be discouraged, as ones like Gens and Bizhawk show the inputs from a playback file.. so harder to verify as legitimate.

RetroArch's is mostly an overlay for phones etc, and could be used, however, using something like the site is separate from the emulator, so is a lot harder to fake with recorded inputs. I believe there are probably others out there, e.g. I think flying_fox uses a different one for her youtube videos, as I've yet to find a genesis skin for gamepadviewer (not that I looked for very long).

^ Thanks Lake 😃


Making your own inputviewer doesn't require serious dev skills though. And I haven't thought about it before but you can probably make it read from the same input file as the emulator with little effort. Is there a way to verify that the input viewer used is the one from the site?

Just thinking out loud here but as a C# novice I can think of a number of ways to circumvent the issues you guys think are solved with an input viewer if tas emulators are allowed.


So the conversation picked up on discord a couple of days ago and then earlier in Zaxon's stream.

Some key points that have been raised:
- Genesis Plus GX allows Retroarch, however, by the same rule this also allows BizHawk (which also has a hard reset feature).
- Restarting/Resetting in Retroarch is a soft reset, rather than a hard reset.
- A hard reset in Retroarch requires reloading the rom, however, this is how it looks which looks open to splicing.
- It was suggested that using a display capture and cropping, however, I believe having complex capturing requirements was why the rule was relaxed in
- A 3rd party input display could potentially be written to read an input file along with an emulator and could potentially "sync" them up so it looks legit.
- A number of reasons for a hard reset exist for real hardware too (clearing level select etc), however, for real hardware this comes with wear and tear.
- Hard resetting for emulator is mostly to prevent input playback. However, this strategy doesn't prevent splicing of a hard reset video and a video of a run using an emulator.
- Hardcore mode for retroarch was suggested, however, there comes an issue with when this should be displayed... before every run would be silly, but possibly at the end would be better - but again... splicing.
- Any rule created in attempt to prevent cheating has the potential to be worked around with enough determination.
- haty12345's latest knux run has also shown that a run can follow all the rules and still be further scrutinized to establish how legitimate a run is.

We could ban emulator outright, this is unlikely to happen, it would reduce the runner base, also BlastEm! and (to some extent) Exodus could pass off as being run on legit hardware when not. So is pointless trying to take a sledgehammer approach.

I think the rule set needs to still make things fairly simple for the legit emulator players, and making it easier on the mods for verifying, and help cater with past and future runs.

The Hard Reset rule is nowadays pretty weak to prevent cheating, video editing could be done to either add it in, or just splice it together with a tas'd run. If it's game related (e.g. for Level Select reset, or potential memory manipulation before the run etc), then it should be required for console as well (which it won't be). Also a hard reset for retroarch imo creates an easier avenue for a splicing point.

In addition to what I mentioned originally, I think we can have some more generic rules to cover a lot of scenarios present and future.
- Reset rules (whatever decided) should apply to both console and emulator
- Any emulator can be chosen.
- Declare the emulator in the submission, and have something during the run that visibly shows it is that emulator (Retroarch XMB or the yellow reset text), or window decoration is fine as well.
- 3rd party input display is recommended (e.g. ).
- Using the autosplitter is recommended
- Special Rules for Emulators with input recording/playback (TAS-like emulators).
--- Input Playback & Recording is visibly shown to be disabled (this makes it flexible for Retroarch getting this in future, and Hardcore mode is used). However, flexibility needs to account for when to show it (start of every run would be a pain, so maybe at the end)
--- The following items need to be shown/used:
---- That the emulator is visibly recording the input (Gens has the red dot in the bottom right, and bizhawk has one in the status bar), and the input file is provided with the submission.
---- The frame counter.
---- The in-emu input display (in addition to requiring the 3rd party input display).
---- The autosplitter needs to be used (and it needs to support the emulator in question)

The combination of these things are "set and forget", with the exception of setting up the recording of inputs. If the emulator is recording inputs then logically it cannot be playing them back. The frame counter makes splicing very hard, and the input displays will need to match up with the 3rd party one.

The point about the autosplitter is it is very hard to manually replicate the functionality, i.e.where it pauses the timer and where it splits. Obviously it can split for a complete TAS runs, but would mean to create a cheated video with all the above would be some serious hard work to achieve.

These suggestions also cater for all submitted runs so far, as I don't think any emulated run either doesn't have something distinct about it, or the window is captured.

Other things that can be recommended to make run verification easier: hand/crotch cam, and streaming the runs. Neither of these should be a hard requirement, but obviously the more things runners do to legitimize their runs makes them easier to verify (or easier to spot inconsistencies).

Zaxon96Zaxon96 likes this.