With the addition of Easy to the leaderboards, I think difficulties in Shinobi should be explained to avoid confusion. You should know that not all versions of Shinobi have all difficulty settings, and not all identically-named difficulties are identical.

First of all, there are two mechanically different variants of Shinobi for the PS2, released in various regions:

• US
• JP/EU/KR

Across both of these variants, there are a total of four available difficulties, listed here in order of enemy health and therefore challenge rating¹:

• Easy
• Normal
• Hard
• Super

The US version has access to Normal, Hard, and Super, whereas the other versions have access to Easy, Normal, and Hard. In order to play the difficulty that's unavailable for your version, you will have to find yourself the respective version of the game, potentially ran on a region-unlocked PS2 or via emulator.

In particular, the US version does not have access to the Easy difficulty, which is the cause for this post. The Normal and Hard difficulties appear to be identical between versions though, making Normal an optimal "main" category for this speedgame.

If you want to go further into the differences, placement of Oboro Clan Coins differs between versions, so don't be surprised when you're looking for a guide and the descriptions don't make sense to you. Because there is no "All Coins" or w/e speedrun at this point, the above list does not differentiate between different coin locations. According to The Cutting Room Floor:

(...) The US version removed Easy, shifted the Normal-level collectables to Hard, and added an extra "Super" difficulty with the old Hard-level collectables (...)

Another functional difference for the EU version of the game specifically is the selection between 50Hz and 60Hz. While 50Hz is currently untested in any form, it seems sensible to me to require EU runs to be done on 60Hz, as that will result in the identical NTSC output that the other versions have (this is because the PAL PS2s output actual NTSC instead of PAL60).

I have no information about the PS3 version of the game, and I can't test it because I don't have access to it.

No worries at all! I mainly posted to make sure I wasn't supposed to do something different - thanks for the edit!

While this is (hopefully) not my final time on the leaderboard (and I therefore don't want to cause too much of a fuzz about this particular submission), maybe I can ask how the time difference was calculated... I've been given a 7 second compensation (18:13 to 18:06), but that doesn't seem to be the visible difference in load time. Let me compare the following two runs, using the visibility of the "loading" text as the measuring indicator:

• https://www.speedrun.com/goose/runs/yv0p0poz (6:10.23-6:12.45, 2.12s loading time)
• https://www.speedrun.com/goose/runs/zpp57x8z (9:45.58-10:01.39, 15.81s loading time)

The difference between those times is 13.69 seconds (assuming I didn't make any mistakes anywhere), which is about twice the loading time that my run got adjusted for... I'm not saying anyone did anything wrong, and I'm perfectly fine if the 7 seconds is what Switch runners get (which, you know, you compensating for load times in the first place is really generous and fair!) - just trying to understand where the difference comes from.

So again, sorry for reiterating on this, and thanks again in advance!

Related: https://www.speedrun.com/goose/news/m4xo1q62

In the news post above, it's mentioned that load times for console runs will be removed. I did a run on the Switch (which has ridiculous loading times, for who knows what reason), and I took the phrasing of the change as "moderators will adjust the time accordingly", which is why I submitted the RTA time (aka without loads removed). This also makes sense given that there's no list of times per console and category that will be subtracted, nor any mention in the game/category rules that runners should modify their times themselves.

Now that a run of mine has been verified, but the load time has not been removed, I wonder if I did anything wrong, or whether that was just an oversight in the verification process.

Thanks in advance!

Ah, I only just noticed it, and submitted my run to that category as well. Thanks!

Some feedback as far as the category rules are concerned, given that I did spend some time tinkering with them. It's picky feedback for sure, and could be considered "identical enough" with a less critical view for sure, but let me mention it at least for posterity.

RNG Manipulation is banned in this category, it does not Matter whether it is intentional or unintentional

The reason why I originally went with the phrasing "unintentional RNG manipulation has to be avoided where possible" is that playing the game is for the most part unintentional RNG manipulation, as everything that causes the RNG to advance would fall under that aspect... which is most of what you do in battle, or on a dungeon map. What I intended with the phrase "has to be avoided where possible" is that you should create a save file that's unknown to you before the game, and if you want to save during the run, stick to the procedure described in my doc, and if you do (and of course avoid intentional RNG manipulation as well), everything that happens is fair game as far as RNG is concerned - that is the important difference in my mind. Of course, it isn't phrased as in "do what RC says" because people might find other ways of functionally avoiding unintentional RNG manipulation.

Another downside is that runners not intimately familiar with how RNG works in the game (and let's be fair, that will be most of 'em) will not intuitively handle save files the way I described it in my route, which is why I included that description along with the category rules originally... of course, this is a bit more tedious on src, but at least a quick note on what to do and not to do would probably be helpful.

Item Drops from Bosses are banned (can't use/sell/feed)

That is technically a functional change from our ruleset, yet one I don't think makes a difference for the run. I will point out that it's potentially confusing for enemies that appear both as bosses and regular enemies, or just simply seem to be "scripted encounters" rather than bosses, such as the White Dragon battle. Under our ruleset, if you got a Holy Fruit drop from the "boss" battle, you would be allowed to use it because White Dragons appear elsewhere in the game, and you could later farm that fruit if you chose to - under the src rules, you wouldn't be allowed to use the boss drop, but the regular one.

Again, both of these changes are probably close enough, not significant (Holy Fruit is pretty certainly never going to be utilized by a runner, and I can't even think of another boss that falls under that rule), and will be understood by most people... but I like to get as close to water-tight with these things as possible, personally (which is where I'll say that I do recognize that these changes might not be accidential as well, in which case I guess that's fine).

Whether rules will be changed or not, since there's even more confusion from having two different rulesets, I'll edit my route document to point to the src rules instead (but leaving the paragraph about how to avoid unintentional RNG manip as best as possible) some time during the coming weekend.

There's a route that I created for this, which has our (Derxu/Skipsy/mine) ideas of what would make sensible rules for such a category in the addendum part of it. That can be found here:

https://storymode.ancientcave.net/nomanip/#categoryrules (note that the route itself is still a work in progress and needs refining in a lot of places; it is, however, complete and fully runable)

That's also where I go into how to avoid unintentional RNG manipulation, and aside from being able to manipulate the initially created save data (which cannot be safely regulated), it is actually surprisingly waterproof. I tested everything mentioned in that section - not extensively, but enough that I can comfortably say it should be reliable.

And disallowing random boss-drops is to not have an outstanding advantage from runs that actually drop the item in the "dev-intended random way".

While that's not wrong, I'd phrase it a different way, My original idea with this rule was to prevent people from having to reset over and over for no reason. With as big of an advantage as especially the Catfish Jwl. is, in a category that disallows RNG manipulation, soft-enforcing a reset grind seems like a terrible idea. Now, this rule (just like the rest of them) was written not for an src leaderboard, but for what the three of us at the time thought was a cool challenge run. While I do think it is a very sensible rule and makes the category magnitudes more enjoyable to play, it isn't a rule I would consider to be typically "speedrun-esque". It is, while practical, undoubtedly arbitrary, and as such possibly not fit for the category. If the run were to be added, I would like to see this rule featured in the ruleset, but that's not my decision to make obviously.

And as a final remark - as I said, the category has mainly been considered a challenge run by the original three of us, and as mentioned in the doc, those willing to run it can still submit it to the Lufia 2 Any% NMG (US) leaderboard. I said in a discussion in the AC discord a little while ago that "noone asked for it to be its own category on the leaderboard" (which obviously has changed now), but I don't disagree with it becoming one. My personal opinion is that it's a fun and interesting category that isn't too arbitrary for an src leaderboard, and it might do for the game as a whole what it has done for Derxu/Skipsy/me - give you a(nother) fun way to speedrun the main game, especially if RNG manipulation isn't interesting.