Roll Eyes
Lips Sealed
1 page
List results:
Search options:
Use \ before commas in usernames
Edit history:
tonic: 2014-10-24 10:25:06 am
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.
Thread title:  
I like being able to show my controller on stream.

Say what you want about Twin Galaxies verification in practice, but in theory their standards for videos were pretty good.
Quote from presjpolk:
Say what you want about Twin Galaxies verification in practice, but in theory their standards for videos were pretty good. they weren't.  After they revised their video requirements, all videos were either required to be submitted on VHS or in 480p.  Even for systems that don't natively output that resolution (like, say, Atari 2600).  Loads of cheated runs got submitted and verified with no question, too.  There was really nothing at all in place to stop cheating.
Edit history:
presjpolk: 2014-10-24 10:19:50 am
Well then I was misled. I Was told they required a live camera of the runner.  I keep seeing that in various arcade run streams.

Hmm, maybe it differed between arcade and console runs.
That is required for arcade runs, though the runner doesn't have to be in the shot.  They don't accept supergun or direct feed submissions of arcade games, so you have to film with a camcorder.  For console, you can (and are encouraged to) submit directly captured video.
Professional Shaq Fu Speedrunner
Or getting fake runs on Twin Galaxies as well. I still have no idea what the heck an Axelord Upside Down Castle Reach Final Save Point run of Symphony of the Night is, nor how they beat the game in 1 min 28 seconds.
All the things
On some levels I think you are overstating the accessibility of game code modification. It takes a very particular skillset to be able to interpret and modify a ROM file in a way that does what you want and nothing else. This skillset is not prevalent throughout the speedrunning community as a whole, although I guess you could always go the route of asking your TASer buddy McHax to give it a whirl. A more accessible problem is not necessarily modifying game code at all, but rather just having a level of introspection into system state that a normal player would not normally have. For example, consider a case where a player must commit to one route or another based on some random elements. If the player simply has RAM watch open and can see what those elements are actively set to, that simplifies the decision-making process and then he gains an advantage not normally open to him. This is a more likely scenario as it is something the player can have outside of the recording window and there's no immediate way to tell at all.

From an accessibility standpoint, splicing is the most readily available tool for cheating. The concept is relatively straightforward and there are free tools available that enable it, all you need is source footage. Doing it well is something else entirely, but with practice and significant game mechanics knowledge it can be very hard to detect. Music is harder to deal with, but not insurmountable.
welcome to the machine
Have there been any cases where someone's used ram watch to gain information on the state of the game during a run? The closest cases I know of are outside programs a couple people used to simplify rng (PJ with Nitrodon running the 7th saga seed manip program, Miles with the Metroid Prime bomb maze thing), but neither of those directly hooked into the game's memory and they relied on someone inputting information the game made available to them naturally.

this actually came up before in a discussion I was having with someone over the larry script in meatboy, where the conversation turned into, well, ok, so you can't just always force 3cycle, but maybe you can read his state and then manipulate it? and i thought, well, huh. that's a new idea.
All the things
None confirmed, but again, there's very few ways to tell outside of suspiciously good luck on what would otherwise be a guess. The cases you mention involve using something external to calculate an appropriate response based on known game mechanics; I don't see a problem with that as it is reasonably something that could be performed by a human. Think of Zelda 1 drop patterns: people can follow the patterns and know what comes next, but for ease it wouldn't be unlikely they would have a cheat sheet nearby to keep track. For randomness engines and the like this becomes infeasible or impossible in many cases depending on entropy sources, but having a readout of current state removes that need.

It becomes a little trickier in the eyes of PC gaming because in some context you do have access to the full system memory and otherwise. Using a script that calculates next events allows for manipulating the event to be beneficial, which turns into a grey area. I would be against it as a "spirit of the sport" type of argument, but it would definitely have merit in terms of run throughput. It would probably be up to the game's community for adoption and depend on whether it's accessible to every runner.
Edit history:
dunnius: 2014-10-25 01:39:03 am
Intruding N313 and F014
There are cases where Ram Watch can be somewhat useful (varying degrees) while playing.
In Hydlide, displaying the position of the key and fairy 1 (fairy 2 is not as useful) would simplify things greatly for real time play.
In NES Metal Gear, displaying the spawn (countdown) timer can help a player determine when to cause an alert to avoid having to deal with additional enemies.
In ActRaiser, displaying the positions of the monsters can be useful so that it is easy to tell if a monster starts moving to go destroy houses. (Fillmore and Kasandora come to mind)  Also the soul counter would make it so that the player would not have to keep track of that count manually.
Quote from VorpalEdge:
Have there been any cases where someone's used ram watch to gain information on the state of the game during a run? The closest cases I know of are outside programs a couple people used to simplify rng (PJ with Nitrodon running the 7th saga seed manip program, Miles with the Metroid Prime bomb maze thing), but neither of those directly hooked into the game's memory and they relied on someone inputting information the game made available to them naturally.

this actually came up before in a discussion I was having with someone over the larry script in meatboy, where the conversation turned into, well, ok, so you can't just always force 3cycle, but maybe you can read his state and then manipulate it? and i thought, well, huh. that's a new idea.

Not speedrunning, but this is a major debate in the competitive multiplayer Pokémon community. Especially with the older games, it was possible to work out your RNG seed while you were playing, which made preparing for a battle (the capturing, training, etc.) much faster, as you could time your actions to the moments when you'd get perfect luck. (Luckily, the in-battle RNG was impossible to manipulate like this.)

Some people just outright cheated, using external devices that interfered with the console to set the random numbers; I felt that was entirely cheating. However, I was entirely willing to type the console output into a separate program and get it to tell me what the perfect timings would be, and I think that should be considered legitimate for speedrunning too; you're playing entirely with console inputs and outputs. Patching memory watch into a game is cheating, though, because it's giving you direct access to information you shouldn't have direct access to.
sda loyalist
There are plenty of ways in which memory watch can help speedrunning, which would make it 'tool-assisted'. That's pretty much the definition of tool assistance.
Yeah, RAM watching is a good point to add. The example I think of where RAM watch would be completely unfair would be the Golden Sun GBA series, where save + resets are used very often to reset RNG values. Knowing your exact RNG seeds (which are often not frame based) could definitely swing a speedrun in your favor.
The example brought up most frequently in this thread so far with RAM Watch has been RNG, but wouldn't subpixels be another major thing that if you have access to, be another huge unfair advantage?
Instead of starting another thread on the very same topic, I'll just dust this one off...

Judging by what has been said so far, using memory watch seems maybe possibly to be a per-community decision... Someone created a tool that allows us to read memory from a DOS game (Alone in the Dark) and draw a map that shows your character's position at all times, alongside important trigger zones. We could do a blind OOB route that's virtually impossible if you can't see where you're going with the help of this tool and generally optimize the run a ton. Does anyone want to tell me how this would make you feel if it was done in some of the games you know. I'd never really even thought about it before, it really changes the way you approach the run.

In a sense what we're doing is just a more advanced version of writing down pre-calculated results on a paper you have next to you. I remember Puwexil and his ally were doing FF9 at a recent marathon and they used a program to calculate which way they needed to play Triple Triad to win each time. So it definitely has seen play already. It would be easy to say "do whatever you like with memory watch data so long as it never goes the other way around", or to ban memory watching altogether. Or to leave it community-per-community. I feel there's lots of games where people just hadn't thought of the possibility and if they had the runs would look very different... it is a game changer when you no longer have to check where something's spawned etc. but on the other hand when it's about mitigating RNG, I don't think lots of people would be upset Tongue

Allow so long as anyone has access to the same tools, i.e. the runner HAS TO upload them to a known public location? There's the question of whether the run should be obsoleted if someone first writes tools for optimizing it, then they get lost and no-one has the skills or interest to do the same, and so they can only do slower runs even though they're really playing better. If it didn't add more red tape, it would be ideal if the tools were hosted on SDA itself, or some other permanent host solution.
That sounds kinda like cheating tbh lotblind. Are you sure it cant be done without a memory lookup?
Obscure games ftw
If the map is the same every time (i.e. could be pre-prepared before the run) then I see nothing wrong with it.

To clarify: to me, the line is drawn at memory watching during the run. Before the run to learn things about the game (even before a segment for RNG seeds etc.) is completely fine by me, but the moment you're accessing data you wouldn't normally have during the run is where I would view it as cheating.
Fucking Weeaboo
Quote from presjpolk:
Well then I was misled. I Was told they required a live camera of the runner.  I keep seeing that in various arcade run streams.

Hmm, maybe it differed between arcade and console runs.

Yes, it differed greatly between console and arcade speedrunning.
It was never a question if you could study the game whatever way you liked. Ofc you do preparations.

The map is the same every time but it's the fact you can't see where you're going without monitoring the memory values.

Arguably using a program to determine what the fastest way to solve a puzzle (like FF9 that I mentioned or was that FF8) is "accessing data you wouldn't normally have during the run". Are you saying it's okay if you have it written down on a long sheet of paper but not if it's rendered on a computer screen? There is a difference though: those guys had to input things into the software manually whereas this is based on direct reading of memory values. Also a map isn't really a "cheat sheet". But yeah, you have to think a bit more deeply to come up with a general definition.

I think all in all it definitely goes against the grain to have this sort of thing active during actual runs. I'll ask some more people to comment though.
Intruding N313 and F014
Emulator vs. Console -- Even NES emulation is still not accurate after all this time.  This is pointed out by the failure of TASes to console verify.  Therefore emulators cannot be used in place of consoles.

Ram Watch -- Using knowledge gained from research about memory addresses , whether memorized, written down, or  made into a program, is a natural part of speedrunning and luck manipulation, but can be used as long as the the actual values of memory from the game are not being watched while speedrunning.  Using visual/audio clues to identify/manuipulate the RNG or some other important variable is used more than people think.  Actually knowing the game mechanics and how to manipulation AI or general mechanics could be included in here too.  It ends up being too much grey area.  Making a program based off of data is not any different from writing it down or even memorizing it.  It is all the same thing. 

In Dragon Warrior [1] and Megaman 10, luck manipulation is used based off of knowing the seeding and being able to get the perfect frame off of audio/visual cues.  This should be fine because of the difficulty level to pull it off.
I speedrun NES Metal Gear, which has manipulation that is not very obvious.  Knowing about the frame rule on doors and how RNG works allow me to know what guard pattern will be coming up in the next screen, and even manipulate where the guards will spawn.  Getting an alert from a camera resets the spawn timer, which allows me to know about when guards will spawn as long as I play about the same.  In one place I use one guards movement to determine what the another will do.  This is what happens when a game is heavily researched.
Quote from dunnius:
can be used as long as the the actual values of memory from the game are not being watched while speedrunning

Yeah, this seems like where the line has to be drawn. Maybe more so than anything because it's simply the tradition, but also because I don't think it's entirely "natural" to have to set up CheatEngine or something just in order to be able to run your game. Well ironically you may already have had to do it for research purposes :D, but yeah it's for the best a runner could do the same run in marathon settings that they do at home.

But what that means is you CAN take the data you deduce from what you see and hear and plug it into anything you like to get the desired output. The only thing about that is it's suddenly very convenient if you happen to have someone around who can help you with your run (operating the computer on the side) vs. having to do it yourself, which could even save a bit of time. If that's not a widely-known-of issue, I'm more than happy not to think of it today Tongue

There's a guy asking whether he's allowed to use a program to set RNG before a run (done by the community) and also in-between segments. As I understand everyone just grinds and grinds to get it once right? Smiley It's sort of a related discussion so I'd be happy to hear a confirmation about that as well. Do you know of any communities where that's allowed?
Edit history:
ais523: 2016-01-12 07:51:36 pm
ais523: 2016-01-12 07:51:36 pm
ais523: 2016-01-12 07:51:36 pm
In the Banjo-Tooie community, there's one RNG element that's determined at game start and you don't learn until much later, and which has a huge influence on any% (possibly some amount of influence on 100% too).

Instead of running a "true single-segment", it's very common to start runs from a save file made immediately after new game, in which you've already checked to ensure that the RNG will be in your favour. This is pretty much the only way people will run any% because it sucks to reset over and over again due to bad RNG. IMO this makes the runs not single-segment, but the resulting 2-segment runs are similar enough to single-segment in spirit that the resulting category seems like an acceptable one. (Note that this isn't quite the same as what LotBlind asked for, but it's very close.)

Also, DS Pokémon games seed the RNG from the system clock (among other things). Runners manually set the clock to a time other than the real one in order to get perfect RNG (they can control for the other factors involved in seeding too).