The purpose of this post is to explore various concerns with cheating (or illicit activity, as I may call it) in the speedrunning realm. There are many aspects to cover, and I will keep this post objective and free from runner names to foster better discussion. (I’ll throw in my general comments at the end). I do not believe this post belongs in the “Speedrun Verification” sub-forum, because it does not relate exclusively to SDA-submissions. Instead, the post relates to the greater audience of speedrunners as a whole.
Who is affected:
Everyone. Everyone who is involved in the community is affected by cheating behavior, including those who commit illicit activity, those who compete against cheated runs, or even those who spectate and provide support to runners who they believe to be legitimate.
In many communities, a standardized verification process exists to assess whether or not the runs are up to standards. This is a noble process done by community members, but of course, it is not perfect. Well-developed cheated runs can be very difficult to detect, and verifiers often do not have the time, energy or desire to heavily investigate a run. Typically, only world record runs are prone to heavy analysis, which makes sense. Additionally, SRL requires VODs enabled and its moderators keep a steady watch on active races to identify illicit activity when it occurs.
Why does it happen:
This section is a little beyond my expertise, but there is a huge range of explanations behind engaging in illicit activity, including competitive pressure, complacency with poor results, psychological issues, time constraints, and attempting to satisfy fans’ and viewers’ expectations. Everybody has a case by case basis for why they do it, but the effects are devastating on community members, and usually the benefits for the cheater are nowhere near the detriments to the community when the illicit activity is identified.
How it happens:
This will be a laundry list of methods by which illicit activity can occur. There are many, many avenues for cheaters to engage in illicit activity, and this post is designed to bring awareness to these issues so that the average runner identify issues where they may arise:
Splicing – Splicing is the act of manipulating recorded videos together from different runs and segments to produce one “complete” speedrun. This is probably the #1 thing people associate faked speedruns with, and it is definitely a large issue. Many games lend themselves well to being sliced – various gameplay elements such as loading screens and silence in audio give the cheater an opportunity to string together two or more videos that actually don’t belong to the same run.
Verifiers are up against a challenge when trying to identify spliced runs. Cheaters can time the frame-lengths of transitions and ensure that their spliced runs can fool those who are timing out frame differences. As well, advanced programs can seamlessly piece together video and audio elements with no inconsistency in spectrograph activity (audio level/activity). However, many of the cases of cheated runs are a result of cheaters being complacent and fed up with no results, and tend to throw together a spliced run fairly quickly to “get it out of the way.” A careful attitude of verifiers in the past have been able to identify issues as they arise.
Keep in mind that although a relatively small percentage of the community submit runs to SDA for verification and listing, and that world-records are commonly identified outside of the SDA page listing, the SDA verification is probably the most comprehensive and strict verification process there is. Although it may be inconvenient for people to adhere to the process of getting their run verified, there is definitely merit to the “gold standard” that SDA runs have due to their rigorous verification standards.
Emulator vs. Console – There is a very large disparity in the entire speedrun community over whether or not emulator runs are acceptable. Many people are purists and believe that console-only runs are worth verifying (such as SDA), while others believe and quantify that emulators are 100% accurate to a standard console, which definitely varies on a emulator-to-console case by case basis. Emulators such as snes9x and project64 have had a history of having various versions that are different from console. Usually, the older consoles emulate very efficiently and accurately, while newer ones (from N64/PSX onwards) are much less likely to be taken seriously. Although using an emulator itself is not inherently cheating, it would be cheating if it is used for the purpose of gaining an unfair advantage in conjunction with a ROM (the next bullet point.)
ROM vs. Actual Cartridge/Disc – While emulators may have accuracy differences, I wholly believe that the difference of ROM files versus the actual game is much bigger of an issue. I will list some various problems with using ROM files for speedruns. Given the breadth of tools used in the ROM-hacking community, being able to open a ROM file and access/edit its values is relatively easy. Clever cheaters could do many dangerous things to alter a ROM file without ever being detected, including:
- Changing RNG values to be favorable. For instance (speaking from a series I know about), many of the classic Mega Man games have various boss patterns with different wait times between actions/cycles. A well-known example is Heat Man in Mega Man 2. After you hit Heat Man with a weapon, he has either 30, 60, or 90 frames of invulnerability (“i-frames”) before he attacks you, then his i-frames reset. A cheater could easily edit out the possibility of getting the 90 frames window (which is unfavorable). When the cheater would fight that particular battle in his run, a casual observer would just say “Oh wow, he got really good luck”, when in actuality, he changed the game to make it appear that he got good luck.
- Altering lag frames / loading zone areas. This is less of an issue because careful analysis would be able to identify these issues, but the issue certainly gets hazy when a player has the ability to control lag in a game. For instance, when there are too many sprites on a screen, games typically lag. A cheater could somehow reduce the general lag frames per the game code or game size (somehow), and overall reduce lag.
Controllers/Input Methods – This is a fairly large debate among many communities, and is very grey-area discussion when it comes to cheating. Certainly, there are devices (which I will cover) that are much more blatantly used to secure an unfair advantage, but controller setups have long been an issue that are generally undecided on. The de facto standard is to use official gear made by the company (i.e., official SNES controller), but verifying a controller from a video of a speedrun can be nearly impossible at times. Third party controllers offer a variety of differences for gameplay, including the handling and feel of the controller, various extra buttons or button placement, and others.
- Turbo – The use of turbo in most communities is generally frowned upon in the Western speedrunning communities. However, certain communities such as the Japanese RPG speedrun community regularly use turbo. The use of turbo (especially in some RPGs) can be very skillful and require practice and precision to use properly (if you haven’t watched some RPG menuing with turbo, you haven’t lived, in my opinion.) Using turbo in communities where it is generally not allowed, especially in platforming and action-adventure series, is a clear sign of illicit activity for an unfair advantage. Luckily, turbo controllers typically emit inputs at a specific rate (10-30Hz), and can be identified with proper tools.
- Script/Script Devices – Scripts are typically considered to be used with PC games, where complicated series of inputs can be mapped to a specific key or function. However, PC games are not solely affected by this behavior. There exist devices for earlier consoles (NES, SNES, Genesis) that enable users to map a series of inputs to a button on a controller through an intermediary device. These were originally designed for casual fighting game players to be able to execute combo moves with the push of a button, but they can be easily abused by a speedrunner for specific-input movements (you can google these devices.) Similar to the use of turbo, verifying the exact frame timing of scripted inputs and seeing if the same timing is replicated multiple times throughout various runs can help identify this issue, but it is definitely an arduous process on the verifier’s end.
These are just some of the various issues, and if discussion leads to more categories being identified, I can certainly update this post.
The take-away from this post is to always be skeptical, even among trusted users and friends in the community. I think the quality of the verification process among communities and speedrunners’ standards for recordings have generally diminished. When livestreams started to gain traction, “handcams” were much more common than they are today, and now it’s perfectly acceptable to show a stream with no audio or video commentary (which is definitely not a bad thing, but definitely removes a certain part of the “live” aspect of a stream.) Cheaters are clever, and just like people who commit fraud, they can be among the smarter people in the general community.
It’s easy for people to become comfortable or trusting in one another, which give cheaters the ability to take advantage of others. It’s a nasty practice that may well one day ruin communities, and I hope that people are aware and keen on the issues of cheated runs, and actively pursue those who are cheaters to admit their mistakes or to leave the community.
Who is affected:
Everyone. Everyone who is involved in the community is affected by cheating behavior, including those who commit illicit activity, those who compete against cheated runs, or even those who spectate and provide support to runners who they believe to be legitimate.
In many communities, a standardized verification process exists to assess whether or not the runs are up to standards. This is a noble process done by community members, but of course, it is not perfect. Well-developed cheated runs can be very difficult to detect, and verifiers often do not have the time, energy or desire to heavily investigate a run. Typically, only world record runs are prone to heavy analysis, which makes sense. Additionally, SRL requires VODs enabled and its moderators keep a steady watch on active races to identify illicit activity when it occurs.
Why does it happen:
This section is a little beyond my expertise, but there is a huge range of explanations behind engaging in illicit activity, including competitive pressure, complacency with poor results, psychological issues, time constraints, and attempting to satisfy fans’ and viewers’ expectations. Everybody has a case by case basis for why they do it, but the effects are devastating on community members, and usually the benefits for the cheater are nowhere near the detriments to the community when the illicit activity is identified.
How it happens:
This will be a laundry list of methods by which illicit activity can occur. There are many, many avenues for cheaters to engage in illicit activity, and this post is designed to bring awareness to these issues so that the average runner identify issues where they may arise:
Splicing – Splicing is the act of manipulating recorded videos together from different runs and segments to produce one “complete” speedrun. This is probably the #1 thing people associate faked speedruns with, and it is definitely a large issue. Many games lend themselves well to being sliced – various gameplay elements such as loading screens and silence in audio give the cheater an opportunity to string together two or more videos that actually don’t belong to the same run.
Verifiers are up against a challenge when trying to identify spliced runs. Cheaters can time the frame-lengths of transitions and ensure that their spliced runs can fool those who are timing out frame differences. As well, advanced programs can seamlessly piece together video and audio elements with no inconsistency in spectrograph activity (audio level/activity). However, many of the cases of cheated runs are a result of cheaters being complacent and fed up with no results, and tend to throw together a spliced run fairly quickly to “get it out of the way.” A careful attitude of verifiers in the past have been able to identify issues as they arise.
Keep in mind that although a relatively small percentage of the community submit runs to SDA for verification and listing, and that world-records are commonly identified outside of the SDA page listing, the SDA verification is probably the most comprehensive and strict verification process there is. Although it may be inconvenient for people to adhere to the process of getting their run verified, there is definitely merit to the “gold standard” that SDA runs have due to their rigorous verification standards.
Emulator vs. Console – There is a very large disparity in the entire speedrun community over whether or not emulator runs are acceptable. Many people are purists and believe that console-only runs are worth verifying (such as SDA), while others believe and quantify that emulators are 100% accurate to a standard console, which definitely varies on a emulator-to-console case by case basis. Emulators such as snes9x and project64 have had a history of having various versions that are different from console. Usually, the older consoles emulate very efficiently and accurately, while newer ones (from N64/PSX onwards) are much less likely to be taken seriously. Although using an emulator itself is not inherently cheating, it would be cheating if it is used for the purpose of gaining an unfair advantage in conjunction with a ROM (the next bullet point.)
ROM vs. Actual Cartridge/Disc – While emulators may have accuracy differences, I wholly believe that the difference of ROM files versus the actual game is much bigger of an issue. I will list some various problems with using ROM files for speedruns. Given the breadth of tools used in the ROM-hacking community, being able to open a ROM file and access/edit its values is relatively easy. Clever cheaters could do many dangerous things to alter a ROM file without ever being detected, including:
- Changing RNG values to be favorable. For instance (speaking from a series I know about), many of the classic Mega Man games have various boss patterns with different wait times between actions/cycles. A well-known example is Heat Man in Mega Man 2. After you hit Heat Man with a weapon, he has either 30, 60, or 90 frames of invulnerability (“i-frames”) before he attacks you, then his i-frames reset. A cheater could easily edit out the possibility of getting the 90 frames window (which is unfavorable). When the cheater would fight that particular battle in his run, a casual observer would just say “Oh wow, he got really good luck”, when in actuality, he changed the game to make it appear that he got good luck.
- Altering lag frames / loading zone areas. This is less of an issue because careful analysis would be able to identify these issues, but the issue certainly gets hazy when a player has the ability to control lag in a game. For instance, when there are too many sprites on a screen, games typically lag. A cheater could somehow reduce the general lag frames per the game code or game size (somehow), and overall reduce lag.
Controllers/Input Methods – This is a fairly large debate among many communities, and is very grey-area discussion when it comes to cheating. Certainly, there are devices (which I will cover) that are much more blatantly used to secure an unfair advantage, but controller setups have long been an issue that are generally undecided on. The de facto standard is to use official gear made by the company (i.e., official SNES controller), but verifying a controller from a video of a speedrun can be nearly impossible at times. Third party controllers offer a variety of differences for gameplay, including the handling and feel of the controller, various extra buttons or button placement, and others.
- Turbo – The use of turbo in most communities is generally frowned upon in the Western speedrunning communities. However, certain communities such as the Japanese RPG speedrun community regularly use turbo. The use of turbo (especially in some RPGs) can be very skillful and require practice and precision to use properly (if you haven’t watched some RPG menuing with turbo, you haven’t lived, in my opinion.) Using turbo in communities where it is generally not allowed, especially in platforming and action-adventure series, is a clear sign of illicit activity for an unfair advantage. Luckily, turbo controllers typically emit inputs at a specific rate (10-30Hz), and can be identified with proper tools.
- Script/Script Devices – Scripts are typically considered to be used with PC games, where complicated series of inputs can be mapped to a specific key or function. However, PC games are not solely affected by this behavior. There exist devices for earlier consoles (NES, SNES, Genesis) that enable users to map a series of inputs to a button on a controller through an intermediary device. These were originally designed for casual fighting game players to be able to execute combo moves with the push of a button, but they can be easily abused by a speedrunner for specific-input movements (you can google these devices.) Similar to the use of turbo, verifying the exact frame timing of scripted inputs and seeing if the same timing is replicated multiple times throughout various runs can help identify this issue, but it is definitely an arduous process on the verifier’s end.
These are just some of the various issues, and if discussion leads to more categories being identified, I can certainly update this post.
The take-away from this post is to always be skeptical, even among trusted users and friends in the community. I think the quality of the verification process among communities and speedrunners’ standards for recordings have generally diminished. When livestreams started to gain traction, “handcams” were much more common than they are today, and now it’s perfectly acceptable to show a stream with no audio or video commentary (which is definitely not a bad thing, but definitely removes a certain part of the “live” aspect of a stream.) Cheaters are clever, and just like people who commit fraud, they can be among the smarter people in the general community.
It’s easy for people to become comfortable or trusting in one another, which give cheaters the ability to take advantage of others. It’s a nasty practice that may well one day ruin communities, and I hope that people are aware and keen on the issues of cheated runs, and actively pursue those who are cheaters to admit their mistakes or to leave the community.
Thread title: