Ocarina of Time—speedrunning & version differences.

After getting 19:35 on the iQue (2nd fastest any% time) I see some people are discussing the age-old issue of version differences. I see so much misinformation being thrown around and I kind of laugh as I see arguments about it from people who don’t play OoT on various websites like YouTube (comments), reddit (/r/speedrun), and 4chan (/srg/). For some reason people who don’t play OoT seem to get the most heavily invested in winning these arguments, despite having no idea what they’re talking about. This post is to explain how version differences work with regards to Ocarina of Time running.

The Legend of Zelda: Ocarina of Time was released on 4 platforms.

It was originally released on the Nintendo 64 in 1998. The N64 has many different version of OoT. There’s NTSC-J 1.0, 1.1, 1.2. There’s also NTSC-U 1.0, 1.1, and 1.2. Finally, there is also the PAL release, which is 1.2. (edit: apparently there are 2 PAL N64 versions. Not super relevant though because PAL is 5/6th speed so it’s not a very useful version).

NTSC-J runs the game in Japanese. The Japanese text saves significant time over the English text. As this was realized, more and more people switched over to the Japanese version, as it was faster during cutscenes and various bits of text in the run.

NTSC-U runs the game in English, which as stated before, is slower than Japanese.

The PAL release has English, German, and French. I believe it was found out that English is the fastest among those, although the PAL version runs at 5/6th speed. This gives PAL a huge disadvantage. PAL also has the oddity of shortened roll invincibility, which ruins megaflipping and supersliding in many instances. Overall, PAL is heavily disadvantaged.

The 1.0 and 1.1 versions have some glitches that were not fixed until 1.2. For speedrunning this is relevant because you can not do the “Eyeball Frog early” glitch on 1.2. This gives N64 an advantage for speedrunning 100%, as it is the only platform with 1.0.

In 2002/2003, the GameCube version was officially released across these 3 regions as well.

The GameCube version is 1.2. Depending on which version you got, it also could come with Master Quest! The MQ version is only available for GameCube and OoT3D.

The GameCube version features a difference in lag/loading. It also saves the game differently. It saves to the memory card (which btw can vary in timing depending on what type of memory card it is). When you reset the game, it goes back to the game selection screen, and slowly loads the entire game off the disc. This means savewarping is very slow on the GameCube version. It can be faster in some cases to save, continue, kill yourself with bombchus, die, do not save, do not continue, and reload your file that way to achieve a savewarp, instead of hitting reset.

On the GameCube PAL version, the game runs at full framerate instead of 5/6th speed! This was nice for European players who wanted to play on console and didn’t want to import.

Due do the extremely slow savewarping, nobody runs the GameCube version very seriously. However, the GameCube version does feature a unique glitch regarding Out-of-Bounds bombchus.

Normally, when a bombchu is released in midair, it explodes. If it is released above a void, the game crashes. On the GameCube version, instead of crashing, it creates a massive explosion that can be shielded during Kokiri Boots backflip hovers. This means the GameCube version can achieve some OoB tricks that are not viable on any other version, such as hovering from the truth spinner room to the boss room of the Shadow Temple using 50 bombchus. These tricks are at best gimmicks though and the GameCube doesn’t gain strong advantages with it.

In addition to not crashing for OoB chus, it also does not crash when you use a Deku Stick as adult Link. This means you can do things like light torches and get ISG using Deku Stick on B as adult. This opens a couple fun routing possibilities, but again these are more gimmicks and not too useful for main categories.

The GameCube version has a higher resolution. The shoulder buttons do not have to be pressed all the way down to be triggered. It supports rumble. The control stick sensitivity is a bit different from N64, which makes the ESS glitch harder. This also affects movement somewhat. The C-Stick for Ocarina songs is unforgiving and considered more difficult than C-buttons.

Also in 2003, Ocarina of Time was officially released for the iQue Player. This version has some unique features as well.

The iQue is version 1.2, however it is fully translated into Chinese. The Chinese text is even faster than Japanese! It is not as big as the different between Japanese and English, but it does provide a small advantage.

The iQue version has a very slow savewarp as well. It is faster than the GameCube version, but slower than all other versions. This is because the iQue goes back to the game-selection screen (the games are stored on a flash cart which plugs into the iQue).

The iQue version has less gameplay lag than every other version. This is most relevant during the first room of the tower collapse, and the collapse cutscene.

For some reason (perhaps having all of the Chinese characters loaded at once), the rare “Hyrule Field” glitch is more pervasive, which can get in the way of collecting the Big Poes. It can also happen in the Spirit Temple.

The iQue looks identical to N64, down to the resolution, particle effects, etc. The iQue crashes in the same places as N64 (no Stick-B or OoB chus). The control stick sensitivity is similar to N64.

Some misconceptions regarding iQue:

Some think that iQue is faster for all categories. As any% only has one savewarp, it is probably best used for any%. It is worthless for 100% due to being version 1.2. The Hyrule Field glitch would probably get in the way as well. For other categories it would be questionable. Due to the huge unpause lag, pause buffering is made a lot more difficult. There are more savewarps in other categories, which means big time losses every time this happens. The left/right are difficult to hit accurately, which maybe could be overcome but is still a factor in playing well (so much so, that Runnerguy gave up trying to play on the iQue for any%).

Some think the iQue is pirated Chinese romhack. It was actually officially released by Nintendo. The reason it has a special name and controller is because China had a console-ban, so it had to be a plug-n-play device. This is why the iQue’s hardware is built into the controller.

Finally, a third argument is that it is difficult to obtain, and should therefore be banned. Compare this to other versions. The run on the Wii-VC NTSC-J version,  you need to either import a Wii from Japan, or buy an NTSC-U Wii, an SD card, load homebrew software on it, and then get a wad-manager and install a WAD, region free the WAD, or region-change the hardware. Obtaining the N64 NTSC-J 1.0 version may be harder than finding an iQue, but it necessary for 100% WR attempts. Either way accessibility is a poor argument.

In 2007, Ocarina of Time was officially available for download on the Wii Virtual Console. Wii VC had 3 releases, NTSC-J, NTSC-U, and PAL.

Unlike the GameCube release, the PAL version is 5/6th speed again, so the Wii VC PAL version is heavily disadvantaged.

Wii VC is version 1.2. There are graphical differences from the N64 version, including a couple glitched textures. The particle effects are different. It has double the resolution.

The VC version has the fastest load time, a pretty fast savewarp (slightly slower than N64 due to the Classic Controller message). It has reduced lag. It can use Deku Sticks as adult. It doesn’t crash from OoB chu explosions, but they are normal-sized and not huge like GameCube. The shoulder buttons have to be fully pressed, and there is no rumble. The control stick deadzone/max input range are large, so the sensitivity is high. As such, precise aiming is difficult and the ESS glitch is much harder.

In 2011, Ocarina of Time 3D was released in several regions.

Due to the bugfixes, altered scenes, redone animations, new textures, new framerate, new game modes, added tutorials, etc. This is considered a different game than Ocarina of Time and speedruns are not to be compared.

During all this time, different unofficial N64 emulators were in development.

Progress was slow. For a long time there were many issues such as extreme pause delay. Finally, the emulation got decent enough with Project 64 1.6 that some people started running on it. This was mainly convenient for Europeans, whose choices were to play the GameCube version and deal with the slow resets, or hack their Wii to play a non-PAL version. The iQue was not well-known back then so people did not consider it.

PJ64 1.6 runs OoT fairly well, although there are some problems. PJ64 1.6 has less lag than the N64 version. Most people didn’t care about this because of things like Wii-VC being faster, which is a valid point. However, as version 1.0 is only available on N64, this means that if you are doing an OoT speedrun using tactics only available on ver1.0, you must use an actual N64 because there’s no emulator that has been proven equal/slower to actual N64. This is mostly relevant for 100% speedruns, where Eyeball Frog early is an important glitch.

Additional problems with PJ64 1.6 is that the Forest Trial could randomly crash, destroying MST runs. Some people running on PJ64 1.6 would enable a cheat code in the emulator right before they entered the Forest Trial, and disable it when they dispelled the Forest barrier. This was pretty ridiculous solution, and would probably be banned nowadays as it is modifying the game.

Entering the Kakariko Bazaar often crashed the game on emulator. Stick-B could crash the game depending on which plugins were used. Using the Sun’s Song in Kakariko could crash the game.

Project 64 1.7 is slightly better about some of these issues. At this point, the people running OoT seriously on emulator use 1.7 with the Japanese version (for faster text).

A ROM of the Chinese version has not yet been ripped. Even if it was, it would be disallowed on emulator because the emulator would not have the iQue menu for savewarps.

Project 64 2.0 and 2.1 were released. Both of these versions have the same fundamental flaws for speedrunning.

PJ64 2.x on default settings runs the game at an unstable framerate. This framerate tends to make OoT run at approx 21fps during gameplay (normal OoT framerate during gameplay is 20fps). Over time, PJ64 2.x saves loads of time due to this. During pauses, the framerate shoots through the roof, to open the pause menu much faster. This is another issue as no official version of the game does this. PJ64 2.x has no gameplay lag.

One flawed argument some people make is that PJ64 2.x is simply running the game more efficiently. The truth is that it’s simply running the game faster than the base framerate. It is the same as running the emulator at 200% speed. The only difference is that the framerate boost isn’t so obvious to the average person.

You cannot allow an unofficial emulator to run the game faster than the base framerate on a leaderboard of times. Why? Because the long-term result of this is all the runs being done at 2000% speed, played awfully but much faster because of the framerate increase.

OoT on all of these emulators also runs different depending on the plugins used, and the settings, such as the VI refresh rate, counter factor, sync to audio, frame limit, etc. These settings can all be edited freely and will change the speed of the game.

There are other N64 emulators, which are generally agreed to be of lower accuracy than PJ64 1.6/1.7, and haven’t been proven as fair. There are also GameCube/Wii emulators that do not seem to run OoT all that well. There is no iQue emulator.

As the Wii has been hacked, you can inject a ROM into a WAD and run it on the Wii. This means it is possible to run ver1.0 on the Wii VC.  It is also possible to run Master Quest on VC. These WADs are banned for being unofficial emulation that is faster than official hardware.

I hope this was educational and clears up some misunderstanding!

In summary, Ocarina of Time is available officially as:

  • N64, NTSC-J 1.0
  • N64, NTSC-J 1.1
  • N64, NTSC-J 1.2
  • N64, NTSC-U 1.0
  • N64, NTSC-U 1.1
  • N64, NTSC-U 1.2
  • N64, PAL
  • GCN, NTSC-J Collector’s Edition
  • GCN, NTSC-J MQ disc
  • GCN, NTSC-U Collector’s Edition
  • GCN, NTSC-U MQ disc
  • GCN, PAL Collector’s Edition
  • GCN, PAL MQ disc
  • iQue Player
  • Wii VC, NTSC-J
  • Wii VC, NTSC-U
  • Wii VC, PAL

These are all considered valid, official platforms to run Ocarina of Time on for speedruns.

Ocarina of Time is also allowed on ZSR using some unofficial emulation:

  • Project 64 1.6, NTSC-J 1.2 (default settings)
  • Project 64 1.6, NTSC-U 1.2 (default settings)
  • Project 64 1.6, PAL (default settings)
  • Project 64 1.7, NTSC-J 1.2 (default settings)
  • Project 64 1.7, NTSC-U 1.2 (default settings)
  • Project 64 1.7, PAL (default settings)

While not preferable, these are still allowed as they have been proven to not carry significant advantage over the official releases.

The following are explicitly banned for Ocarina of Time speedruns:

  • Project 64 2.0
  • Project 64 2.1
  • Using ver1.0 or ver1.1 on non-N64 for time-gain

These are unfair to use when comparing with actual hardware.

The following are considered entirely separate games:

  • Ocarina of Time: Master Quest
  • Ocarina of Time 3D

These are tracked entirely separately from vanilla Ocarina of Time.

72 hours of #leaderboards discussion

With nothing set in stone completely here’s what we have accomplished in the last 72 hours:

All | Official Releases | Accepted Emulators
defaults to All. select what you desire.

Accepted emulators are determined on a game by game basis, after being proven to not have advantage over an official release. Obviously allow things like higan/bsnes. For the sketchy stuff like PJ64 1.6/1.7, you are not allowed to change settings from default. Many games (Lots of N64 games and later) wouldn’t have any acceptable emulators (as they aren’t reliable enough yet).

Also, similar to the filtering system above, every version difference that affects the run’s speed would also have its own filtering options, such as English vs Japanese text, version 1.0 or 1.1, SNES or VC. These could all be filtered to make any sort of leaderboard view you would want. Additionally, you can submit multiple runs, and although only one would show per list, it would allow your other times to appear if you do runs on multiple versions.

Additional metadata about a run may be collected and filterable, such as if you used the Tingle Tuner in a run of The Wind Waker (which requires GBA attachment), or perhaps character class choice for a game like Dark Souls? (Not knowing a lot about Dark Souls, but perhaps this could curb the endless “categories” being made up to get “WR” as every possible class. Instead, the class chosen would be listed and could be filtered if you wanted to see for example the fastest “All Bosses, Pyro” run.)

Categories would be based on the actual category difference, and not version differences. By default, all the versions would combine in a table with ALL of the filtering options presented above. This way, when somebody is trying to find out what “the fastest time” is for a game, they will quickly be able to get the information they want.*

*This is by default. For some games, the community vastly plays on a slower version on purpose. For example, The Super Mario World 2: Yoshi’s Island players play the NTSC version pretty unanimously. It turns out in the PAL version, Yoshi moves approx. 30% faster. In this case, the default view for the SMW2:YI leaderboard would default the region to NTSC as opposed to “Both NTSC and PAL.” Other notable examples: The entire Pokémon speedrun community uses English despite Japanese being faster. The entire A Link to the Past community avoids the GBA version (although this might be considered a separate game entirely). Due to these versions being official and unbannable, the solution is to, by default, filter them out of the leaderboard and let the user decide if they want to see runs on versions that were otherwise avoided.

This leaves a leaderboard where the #1 time is the fastest time on an accepted version of the game, and should therefore satisfy all random Twitch viewers wondering what the “world record” is and what the competition is like.

Videos will be required for every submission (hosted externally). There will be no segmented runs. There will be no partial-game categories (nor individual level runs). It is likely that pausing the timer during a run timed with real-time will not be allowed.

Still a lot to discuss, but this is sort of the current line of thinking. Again, nothing is final, but I thought I’d let you guys know where we are at in case you aren’t lurking in irc.speedrunslive.com #leaderboards all day long.

Thank you for dealing with my constant barrage of questions, hypothetical situations, and devil’s advocate approach towards this. I am taking it incredibly seriously.

- Cosmo

Emulators vs official releases

Our initial conception of SRL Leaderboards was to build a tag system which allows proper filtering by whatever criteria you want. If you wanted to see the fastest English WiiVC run, you would be able to easily filter the leaderboard and see those times. Or you could look at a mixed table with all times.

We also wanted to allow emulators in this filtering system, so you could have one nice leaderboard with all the times, official versions or not.

After the Project 64 2.0 silliness (it runs really fast on default settings), and then looking into it further (you can tweak the settings to get the emulator to run at whatever speed you want), it brings up issues.

For races, we can do things like ban 2.0 because it’s faster than the fastest official version, but races are just races. Races people have fun with, and the more that can join the merrier. When it comes to actual personal bests in legit categories, and trying to list those times in direct competition with others on a leaderboard system, there are issues with trying to declare what settings are fair. SRL doesn’t really have any sort of authoritative figure to list “legit” settings for an unofficial emulator. It is entirely arbitrary and made-up.

The issue with unofficial emulation is the fact that they are not just one nice little package: you can modify settings to run at a hundred different speeds. Where do you go from there? List the emulator AND require submitting all the settings as well in order to somehow construct a list? Where is the line drawn?

No, the answer lies in the way I have seen the Japanese RTA Wiki function, which lists official times in one table, and then, as a reference, lists unofficial emulator times. This separation seems like the only way to fairly handle unofficial emulation.

My current vision of SRL Leaderboards are therefore:

  • Official versions together in a table, on a per category basis.
  • Tagging & filtering system in place to separate times if you want to see something like fastest “no tuner” time for The Wind Waker, for example.
  • Additional listing of emulator times as a reference, but not taken as seriously.

Comments and thoughts appreciated. This is an open discussion.

A concern

Twin Galaxies recently brought their database of records back online. I browsed through some of them. There are plenty of issues + reasons to not take their leaderboard seriously at all. Among the many reasons, one reason is the huge amount of clutter and useless dupe categories everywhere. This got me thinking about SRL Leaderboards, as we have been making progress not only in the planning, but the design, coding, and implementation.

One concern I have that hasn’t been figured out is the issue of category prestige. In a perfect world, categories would be easily definable with a blanket rule across all games. SDA sort-of tries to implement this a little bit with their Any%/100%/Low% ideology. Unfortunately due to the huge numbers of exceptions to the rule & the amount of “forced” 100% and “vaguely defined” low% categories, I’ve come to the conclusion that blanket rules do not work for separating out categories across all games. I think most people understand this.

The problem is that many games do warrant having more than one category. The question is how far do you go? This joke page shows what might happen if you went wild and allowed a category for every possible thing in a game.

This page, despite being a joke, actually got people to go turn on their game and snatch up a couple of the “records.” This shows me that if it is built, people will submit for it, despite it being ridiculous. This puts the responsibility in the hands of the people adding categories to the site to maintain a leaderboard system that encourages competition, which is a big ideal of SRL.

The huge cluttering at TG is a great example of their being so many “world records” to go snatch up, that it spreads the competition ridiculously thin, and makes getting the high score or a good time pretty meaningless. On SRL we want the amount of categories to be limited to encourage competition and make more exciting stuff happen such as the dxtr vs funkdoc battle for the Batman record, or Garrison vs kottpower trading the Super Metroid record back and forth. This is exciting not just for the runners but especially the speedrunning audience, which is growing larger every day (at an alarming rate).

After much discussion, I think the blanket rule (I know this is dangerous, but I have not seen a counter-example) of requiring the game to start at the beginning and end at the end is a good first step. This prevents things such as ALTTP Master Sword or Pokémon Red/Blue Beat Misty, which is obviously good. From there it gets more tricky.

Categories like SMS 78 Shines or OoT No RBA/WW have had their runners in the past (and some even recently) working hard to get good times, despite it not fitting as cleanly into a “fastest completion” type of goal. It is hard to say where exactly this line would be drawn. If all of these types of categories are allowed, it would spread out the competition and risk starting to clutter the leaderboard. If they are not allowed, that is somewhat annoying to the actual runners of the game whom might want a resource to find such times.

The truth is categories have differing levels of prestige. From an outside observer’s perspective though, this may not be evident. To them, if it appears on the leaderboard it will be “legit,” and if does not appear it won’t be. In the interest of appealing to people “not in the know” one solution is to axe the stuff that is “less legit,” which can be somewhat subjective at times.

I’m not sure if a tiered category system could somehow get onto the SRL Leaderboards that would imply correctly to an outside observer that “yes, this is one way people play this game, but it isn’t taken as seriously—here are the fastest times for it anyway.”

Not sure how to handle this problem, but with the growing speedrunning audience, it must be handled correctly so we don’t end up with the PAL 200% Speed Emulator ALTTP Glitchless Master Sword WORLD RECORD and turn into TG.

Why Bingo is a bad goal for most SRL games

A long time ago I created a 7×7 grid of items for The Legend of Zelda: Ocarina of Time. It was a static image, but the items were roughly “balanced” in their position so that there wouldn’t be large balance issues.

The idea is that you would be given a starting square, and you must connect 5 in a row from that square in any direction, collect those items, and then you would be done with the goal.

After a few races it became clear that there was always a fastest row which defeated all of the others. A friend of mine, Siglemic, figured out and wrote down the optimal 5 items to choose in every possible starting position. This was obviously against the spirit of the Bingo idea.

I decided to change it to a randomly generated 5×5 card with no specific starting restrictions. This changed things quite a bit, as people in the same race could be executing entirely different rows with 0 shared items. This is pretty different from the typical idea of racing something (where two close players would be traversing the same obstacles around the same time).

There are a number of great things about Bingo. It allows people to pick and choose what they want to do. It allows people to try to route out their path in a more creative way than other races (no pre-planned routes). It brings out unexplored parts of the games. There’s some huge problems with Bingo though.

OoT Bingo has been re-balanced dozens and dozens of times, and there are still oftentimes rows that are much too fast, beating out the rest of the board. When there is an imbalanced Bingo board, there is no reason whatsoever to choose a sub-optimal row. This results in two groups: The people who recognized which row was too good, and the people who didn’t.

The people who recognized it might claim that part of the skill of the Bingo system is that you get rewarded for identifying what row is the most successful. This is actually not the intention of Bingo at all; in a perfect system, the script would produce 12 options that are all perfectly equally viable. Although that can never happen, it is definitely in my interests to get it as balanced as possible.

The people who did not identify the best row often feel cheated. The current way the Bingo is set up, you have very little time to plan out your route, so that you have to think on your feet. Thinking on your feet is a definite intention of Bingo; players are rewarded for coming up with a game-plan while simultaneously executing the plan. If somebody picks a row they like, plan it out correctly, and execute it, they might still lose if they didn’t realize a different row was inherently superior. Sometimes there isn’t enough time to properly assess all 12 possibilities in comparison to one another, so some players might get a bit lucky in seeing the best row immediately.

What this means is that the Bingo must be constantly updated and maintained in order to minimize imbalance. It is difficult to constantly adjust such a complicated goal generator, because items have not only a difficulty, but types and sub-types which are used to minimize the effect of synergy vs difficulty. It is a very delicate balance which needs a lot of deep thought and foresight.

Another huge issue is that routing is completely fundamental. The game needs to be seriously open-ended, with complex routing options and item/ability upgrades that change the route even further.

My friend PEACHES_ had an idea to get Bingo working for Blast Corps, where each level would be a square on the bingo. You would complete your row from a 100% file, so that you have access to every level from the beginning of the race.

This is a bad idea for a couple reasons:

  1. With each individual level having been time-attacked frequently, there is going to be a clear amount of time that each row would optimally take. Your level choice is simply your knowledge of the length of time each level takes, which is a poor test of ability.
  2. The over-world map travel would be the most important aspect of the routing, because the individual levels themselves would already be pre-routed. Routing the map is another poor test of ability.
  3. Every square is completely independent of one another. What you do in Ebony Coast has absolutely no effect on what happens later when you complete Orion Plaza.

In order for Bingo to work correctly with a game, the game is going to need to be open-ended, with complex route possibilities, lots of objectives that can be completed under a number of different conditions, and have many different upgrades/items that may be obtained to influence the method in which certain objectives may be completed. The community who creates the Bingo must race it often, update it frequently, and have serious discussion about balance issues and the optimal way to tweak various objectives, both in their initial difficulty and their type and sub-types.

I have a solution though! Instead of giving the players choice, take away the choice. Put everybody on the same playing field. Balance no longer matters because everybody will be completing the same set of goals. The routing may be as complex or as simple as it needs to be.

What I am saying is that SRL needs more goal generators that give a list of objectives or restrictions that every player must follow. A good example might be a Mega Man boss order generator. Take advantage of what the game offers and think critically about what makes a fair and interesting race, as opposed to just trying to blindly copy Bingo!