Alright, let's finally get started with the full-game speedruns discussion (and more !). My apologies for the near weekly wait, it must have felt like an eternity to some and I completely understand that. New findings, realizations and discussions have kept pushing it back, until now.

My post is very long and exhaustive, it’s about 18k characters, and I would say it took me about 8 hours to write in total. Not counting the extra time spent thinking and debating these concepts, and talking with people. This isn’t to flex or to look goofy, but rather to warn people that this discussion is not to be taken lightly. This is not an exercise. I mean, how could it be. This is the most crucial, important moment of designing the leaderboard. This is it, the hardest part, right here, and we’re heading to it right now. This is where everything will play out... where the board will gain its official outlook. But only if we find a common ground to every single points discussed below. Some may be easy, but others might take a while...

Let alone with designing many leaderboards at all, the Klonoa community has never dealt with a game this big, this complex… I have personally learned so much with it, but saying it was easy to manage is simply not true. Many times I had to reconsider my opinions and become more tolerant of certain things, and I’m sure this will get happen countless more times in the future. I hope you may get to learn a thing or two yourself as well.

All this to say that this final-ish discussion will take time, and that a consensus won’t happen overnight. So, please take your time. I may have missed crucial points. Please point them out. For all we know, tomorrow might bring its new set of problems to solve. More reasons for this to take time. But at least, with this post it can finally take off.

I wrote a summary at the end of most of the points, that way it is easy to get the gist of what I have said. Use the abbreviations of the elements for easier discussion.

I : Main points

I.a : Metric used to time the run

We have access to two distinct timing methods, that I will define as such : IGT, which is simply using and following the incorporated in-game timer of the game, and RTA, in order words how long would the run take in real time.

And already, we can see that RTA has a big disadvantage. Indeed, it counts loading-times and overall game performance in the final time, but the thing is, these two elements are slightly different depending on the platform you play on (let alone within the PC playerbase). Which means that playing on some platforms may end up being faster than others, solely based on the game itself and not because of the player.

Note that on its own, this isn't inherently a problem. You could still choose to run only against players who play on the same console as you, and live your day. But it would be less fun given that you would ultimately get to play with only a fragment of the playerbase. Which in return could unnecessarily incite people to spend money and buy faster versions of the game that they may already possess, just so they can play along other people. It would also make difficult to judge how fast a time really is, if all platforms were to have their own secluded leaderboards with varying time ranges. All these, when the game is supposed to be the same for everyone all along.

Although it is true that we do not currently have direct evidence of these loading-time and performance differences, and that such a leaderboard would still be very possible to manage (Door to Phantomile works like this), the fact remains that IGT is programmed in this game, and would allow to evade all these issues, much to our fun and wallet.

Everyone would be able to play on roughly the same game, there would be no real incentive to change platforms, it would be much easier to know how fast runs are… And times would be even easier than RTA runs to determine, not necessitating that we download videos to retime runs, since we can do it simply by looking at the final time (assuming they have the timer enabled, which would be absolutely mandatory if we were to really use the IGT metric).

So it seems that IGT is at face value a very good timing method. But is it truly perfect ?

I.b : IGT and pausing

So, you remember that in RTA timing, the run lasts real human time ? You can thus never allow yourself to slow down or take a break, at least until the run is over. Which sucks when the game gets exhausting, or when you have the nerves.

Well unfortunately, it looks like the IGT timer of Phantasy Reverie Series is flawed by this very aspect. The timer is currently programmed so that it stops when you have the game paused. Pausing is free to do, you can do it basically anywhere you feel like to, at the press of a button the entire run is paused and you're not getting penalized for it in the slightest. The timer is also not active when you are not in direct gameplay, like in the stage select map or cutscenes.

Furthermore, a trick called costume/difficulty warping technique has been found that also involves pausing. It's a pretty destructive trick because it allows teleportation to any checkpoints, you automatically regain your health if you play on easy and normal, you can reset the cycle of rooms. It can even be used to escape death if your health goes to zero but you don't touch a ground or death-plane yet (so the game still allows you to pause), at the cost of no extra lives (basically a way to cheese hard mode). But you can also go back in time and try Mirror-Fairy sections again. While it's definitely a very interesting trick (and honestly meme worthy), it has one major caveat if we time runs using IGT... because not only you would pause the timer (run) for like 8-10 seconds each time... you would have no reasons not to strike checkpoints from far away then constantly use the trick on every checkpoint you see in the hopes of saving a bit of time a little bit of walking…Because of this, its abusiveness, its likeliness to slow down the pace of runs considerably, and its use in obtaining the lowest IGT times by incidentally killing time rather than actually going fast through the game, this trick should probably be banned for normal speedruns. As for pausing the timer itself, either manually or by hanging on certain screens, they may not need to be regulated for now. It’s easy to improve one’s gameplay without relying on them. Such regulations may concern top level runs in the future, to ensure that they are speedruns that focus on going fast and having the timer run as much as possible.

I think that for now, and for the leaderboard completion sake, we should focus on normal runs, and leave aside runs that consist of getting the lowest IGT time possible by abusing everything the game. In the future, we may discuss adding it, and I believe it can have a place, but it would take significantly more time to discuss, and anyways we should really get more information about how this type of run would look like. Right now, there is barely any info on the matter, and new discoveries could change everything, so it really should be best that we leave it evolve. Same deal about allowing exceptions to the warping technique for interesting and handy uses only. We’ll discuss it at a later date.

So for now, it could be enough to ban the warping technique from speedruns. In the future, we might consider warping use exceptions, regulate pausing for top level play, and new categories for these tricks. This way, the only real drawback to IGT timing would be solved.

I.c : Timing the full-game speedrun

Starting from now, I assume that we time the game in IGT. If this were to not be the case, defining runs in RTA would not be a worrying thought, as there appear to exist clear timing points we could use.

So if we time using IGT... we simply go by the final time. Or rather, the final second, due to there not being milliseconds. As a side note, in Wii² this timer seems to start roughly as you gain control of Klonoa the first time (but not quite on the frame). But as for L'sV²... the timer starts half a second past that. Weird but okay. At least, the way the timer stops at the end of the game is obvious and clear.

Sadly, it doesn’t appear to be all that simple. For instance, the general in-game timer doesn't show up during the timed extra stages, and as a matter of fact, it considers the run paused if you play them. How would we go about timing 100% speedruns (which would probably be getting all dreamstones and save all phantomilians) ?

A simple solution is that we add the time of these extra stages to the final timer count, at the end of the run. Only small issue with this practice : the most precise time unit value the in-game timer tracks are seconds. Which means that it would be gameplay-wise possible to gain one second by adding up the fictive millisecond counts of the in-game and extra timers, but the final time wouldn’t count it because it doesn’t count milliseconds, nor the time spent on the extras. A second sure is annoying, but is it really that much when talking about 100% runs ?

Similarly, as far as we know, it is impossible to start a normal stage with the timer set at zero (outside of the first stage of both games). It will always start with some extra time carried over from previous stages. There, the way to time the run using IGT would be to take the beginning stage time, and subtract it from the time of the end of the stage. It sucks, because it entails that depending on when exactly you start the level, and the remaining time before the seconds digit updates, you could play with a one second IL disadvantage if the counter were to update as soon as you start the level. Which truly sucks for small stages such as 1-1 (though maybe not as much for longer stages like Kingdom of Sorrow). I do personally not see a way to solve this issue, without relying on RTA. Either people reset the stage as soon as a second ticks so that they can avoid this issue, in other simulating the timer starting at zero (which doesn’t sound that painful all things considered since you can easily do that from a failed attempt), or you simply wouldn’t want to care about stage optimizations when there remains only one second left to save.

Lastly, I would still argue that we should keep RTA around, but as a side, information based run metric. Its use would be to tell us how long has the run/IL actually lasted for, which is always nice to have around when it comes to IGT. It's very simple to define : RTA starts and stops accordingly to IGT. Since it's not as important as IGT, exact accuracy is not required, after all we are only looking for a rough estimate of the real time duration of the run. Thanks to this extra gap of flexibility, timing RTA wouldn’t require anyone to download videos for frame-by-frame rewind. Hence also not necessary to fill out for players.

So basically, assuming we go IGT, we would use the in-game timer for everything. Easy. When running 100% or normal stages ILs, however, we would have little choice but to make simple arithmetic calculations to calculate the final time. The timer not having milliseconds and being potentially inaccurate by a second in the aforementioned categories is really not great, but I guess there are still ways to get around it. Anyways, I don’t personally think that a single second is big enough to fully argue against IGT timing. And, we would still keep RTA, just to know how long the run has lasted outside of the game.

With this, I have now brought to your attention the main points we need to address in order to be able to design full-game speedruns, at least their main outlines.

Unfortunately, we are not done yet. There are a number of smaller, but still important points we have to address before we can fully set home.

II : Side points

II.a : Framerates

The Klonoa Phantasy Reverie Series is a game that officially runs in 60 FPS, but the actual framerate of the game isn’t exactly perfectly continuous at all times. Especially on some platforms, like the Switch, the framerate might drag down to 50 FPS. It truly does suck, as it makes overall gameplay less accurate. In this instance, it’s perfectly reasonable to want to upgrade to a better version of the game.

But the PC platform has it different. Indeed, on PC it is possible to play the game at higher FPS counts. Some computers may even do it by default. And it has been discovered that the game does seem to behave differently depending on the framerate. Although we do not know the impact of high fps runs on the game as a whole, according to the following videos, we can only imagine :

This thus brings the problematic of allowing custom FPS runs. Should we enforce Fps regulations for PC, or distinguish their runs altogether ?

Well, it is a personal stance, but I find it obvious that everyone should play under the same game constraints, so it’s a fair playing field, and 60 fps gameplay can’t be cheesed out. This doesn’t mean that the behavior and effects of high fps should never be studied with the game. I completely encourage it, and I’m all up for more funny glitches and interesting game breaking stuff to be found. Perhaps then, high fps speedruns may be considered.

If we do set up a fps limit, this is how I would suggest it to be done. Bear in mind that I am in no way knowledgeable about PC spedrunning so my opinion may not have much wisdom. But we all gotta begin somewhere.

The FPS may be limited between 30 and 60 (don’t mistake it with lag, but rather the game running at normal speed but with overall less frames being displayed per second). The FPS value needs to be consistent over the run, so obviously, spontaneous out of range framerate counts are tolerable. It’s also acceptable if the framerate for some reasons stays barely outside the range, for instance at 61 fps, as even though we do not have sufficient data on its consequences, the impact of a single extra frame seems insignificant. Not only crossing the former limit is proven to slightly affect the game, at that point, we might as well consider your game defective and not acceptable to run on. For the latter limit, it’s just to prevent impossible gameplay and unforeseen consequences to take place, and to be in line with console runs.

Now for the cumbersome part of this decision. To ensure that we can see the runner’s framerate, we would henceforth enforce PC runs to not only have a FPS counter on their run (Steam’s built in FPS counter, others software like geforce experience, Rivatuner...), but to also force the game FPS to 60 using other programs… a guide might have to be written to help players with setting this up. Of course, this choice may imply rejecting runs that do not not respect this. Including some of the already pending runs, which couldn’t have known. Anyways, this is only my proposal, and this is a forum discussion thread for a reason.

If we choose to separate PC runs (using a 4th variable for category separation), then no rules would need to be emitted at all (though it would still be handy to know the general framerate of runs).

Small note, lag strats are yet to be found.

II.b : Support move binding

The Support action button need a second controller in order to be used. On most platforms, this will mean that players will juggle two controllers at once. But PC players have the possibility to avoid this trouble, by binding the Support move button onto the same input device through various means. It is susceptible of making Support mode speedruns slightly easier. And as far as I know, it is way less accessible if not completely unavailable for console based platform runners.

The main problem here is that policing this potentially advantageous practice seems only possible via extremely strict policies. Such as, asking for real-time handcam proof to make sure that they play with two distinct controllers. Furthermore, it remains to be proven if this input bind actually gives any actual real benefit for PC runners. Such that this point might not be a concern until we reach super top level territory, and even then, it will need to be debated.

So, personally, I would leave the matter be.

II.c : Game versions

Usually, game gets updated. And when it comes to speedrunning, games might sometimes receive gameplay changes that thus affect the overall running experience. Will this happen with this game ? Have things already happened ? The question is mostly left open. This game may very well remain the same, or suffer the same fate as Super Mario Odyssey, with updates bringing significant gameplay changes, and nearly inaccessible updates.

This is just for information.

II.d : Mods

Should we allow runs performed on a game that has mods installed ? For texture or music changes ? Even for fixing the broken cutscenes in the Lunatea’s Veil remaster ? (https://github.com/entriphy/KPRS_Mods/releases/tag/20220715) This will also concern PC runs the most. I think that all types of mods should be banned for the simple reason that non-PC platforms can’t have them anyways. But this is also a new territory for me, so please share your ideas.

III : Details

This last chapter groups a bunch of elements that are too small to have their own points.

• For full-game speedruns, you should play the game on a new save-file. That way you would start the same way as everyone else, with the same amount of extra lives, same game integrity.

• Support mode is a setting you can choose in the option panel, and a gauge will show up at the bottom right of the screen. It is not the same as actually using the Support move. If you submit a run in the Standard category, but in which the Support mode is enabled, but you never use the move once in the run, the submission should still be worthy of being submitted in the Standard mode category.

• For top level only, but in order to mitigate pausing in full game- runs, you would be required to have the Support mode activated before the run, or at the very least, right as the run begins, as doing it there is mostly insignificant.

• Again, for top level runs of the current speedruns, runs might need to need to be single segment.

• In most cases, a given submission might not be able to fill two separate categories. For instance, you wouldn’t be able to submit a boss IL performed on the hard difficulty and normal, even if the runs would prove to be be exactly identical to one another regardless. An exception could however be made, that you could reuse footage of full-game runs to submit IL times (excepted for bosses, since they have their own dedicated time-attack mode with milliseconds).

• Using a costume in the run is allowed.

• No skips/glitchless runs might be considered in the future, though not for the same reasons that IGT optimisation runs.

Alright, that is finally the bottom of it. Again, let me know what I may have missed with this investigation. And most importantly, thank you for your time.

(blame src for condensed text)

This is a minor point, but I'm mostly just curious if I'm missing something. At the moment I'd be inclined to drop the bit mentioning the lower value of 30 FPS; I think the 60 FPS cap is the salient point and I actually find it a bit unclear as to whether the mention of 30 is suggesting that you can set the cap to 30 so that the game never goes faster than it (which isn't something available to console players, so not something I'd love) or if it's suggesting doing something to try to keep the frame rate ABOVE 30, which isn't really something that shows up as an option using the most common methods. That's simply because the assumption by e.g. most video driver software is that if you cap the frame rate at 60, you want the game to run as fast as possible up to 60. And if your computer can't keep the frame rate above 30, well, an option that says "I want the frame rate to be between 30 and 60" is typically just going to be wishful thinking (barring things that dynamically adjust quality, etc. which I don't think is going to be relevant here at all).

I know both the Crash and Spyro remakes on PC both say "Your FPS must be capped between 30 and 60 FPS." I think those games might actually have an option for either 30 or 60 FPS on console which would explain its relevance on PC (does someone know for sure?), because otherwise I have to admit that I find it a bit confusing why 30 FPS is mentioned there too, or what exactly it's asking for (again, does it mean the frame rate should never go BELOW 30, or does it mean you're allowed to cap the frame rate at 30 if you want, which would seem weird if such a thing were NOT available on console).

No, you are right in raising this doubt. Console runners can't really control the framerate, let alone have a counter for them, so they are not concerned with anything related to this point. But PC runners can absolutely control it, so if should most definitely be enforced on their end (if this is the path we go).

Either that, or you have the misfortune of playing on a terrible computer with very limited resources, which on top of making the game behave potentially differently (and funnily enough, something that console runners also can't reproduce), is just unfortunate anyways because then the game is a chore to play.

So to reiterate, maybe the enforced framerate (if there is one) for PC play should be 60. If for some computer reasons the FPS counter throughout the run progressively stagnates to other values likes 59 or 61, well, so be it, but it should at least start on 60. This last bit is simply about being flexible more than requiring extra rule text to be carried out. But in the end, I don't even know if this possible anyways.

I really only just used the 30-60 limit because that's what some people in the discord were saying about this topic. But now this should make more sense

My thoughts on the above :-

Timing: I don't have too much to say regarding IGT vs RTA. I don't mind either. IGT feels fairer in my mind for those playing on consoles/lower end PCs, but RTA feels more "true" to going fast. IGT is obviously also much easier for everyone. But overall I honestly don't mind which one and am happy to go with the flow of how others feel.

IGT might cause an issue if there is an All Visions category, as I think (and this needs testing) the full game IGT stops when you get the final hit on Nahatomb. IGT does not include Extra Vision's time. Unless you want to allow manual addition of the clear-game IGT + Extra Vision's IGT in submissions.

Framerates: As we know that the game plays slightly differently on different framerates, I agree that the game should be capped at 60. Switch targets 60 but hits approximately 50. I don't think this will make a particularly big difference, honestly. If it turns out it does we can re-assess, but as other consoles target and achieve 60 and do not go to 120 (to my knowledge), I think it's fair for PC to be capped at 60. I also think it's fair for PC runs to have a small yet clear FPS counter in the corner of the screen. Steam's is fine for this, but others can be used if need be. There will, of course, be an element of trust in that people don't cheat the FPS counter.

Support Jump Binding: I think it's fine for PC players to be able to bind the support jump to a key on the same controller. I personally feel it would be ridiculous to ask for a hand-cam to make sure support jump players are using two controllers.

Game versions: I don't think there's a conversation to be had here at this time. It is impossible to discuss what we would need to do to accomodate an update that we don't know the contents of. Any discussions on an update would need to take place after an update has dropped. Super Mario Odyssey's board just has a Version value against each run. When/If an update drops, a decision can be made at that point as to whether all new runs must use the new version or if old versions are also fine.

Mods: As long as a mod does not give an advantage over a non-mod player, I don't see any issue. EG: A music or sound effects pack is unlikely to give any major advantage. If a mod helps with timing something, or makes weird quirks occur that give an advantage then those mods should be banned. Perhaps it could be stated in the rules that mods that do not provide an advantage are allowed but to ask a run moderator/verifier if unsure?

Other points:

• Agreed on new save file, unless a particular category requires an existing save for whatever reason.
• With the knowledge we have currently, I agree that runs with support mode enabled should be able to be submitted to standard boards providing the support jump is not used.
• I don't see why costumes shouldn't be used so no problems there from me.
• I think a "No Major Skips" category would be a good category to have. Some people like running No Major Skips categories. DTP's board has one of these, too.

I agree with pretty much everything in Balneor's post. I don't personally know a ton about how mods/code works, so I share the no mods inclination; but if folks more educated on the subject than I think and can show that certain aesthetic mods wouldn't be an issue, I could potentially be persuaded to say they're alright. As a starting point, though, having them disallowed seems the most pragmatic.

I also think starting on a new game is a good idea, as is capping PC framerate at 60. The details of insane framerate runs feel like a bridge that should be crossed when people are chomping at the bit to run

IGT would be preferable for me, as I've never used RTA and the built-in timer is extremely handy. I would assume that for skipping cutscenes, slight delays/sub-optimal start-holding wouldn't be penalized. However, would holding too long into the cutscene before skipping either add time to, or invalidate a run?

I almost agree with the post but I have a concern for ban of the warping technique due to pausing on IGT.

The warping technique has a potential for saving time on restart the game from checkpoint (e.g. 5-2). Certainly, IGT doesn't calculate times between paused the game to changing any costumes, but I think the technique shouldn't be restricted for that specification. Because I consider the operation of changing costume should belong a speedrun. More faster, more quickly, more rapidly, that's our doing on runs.

And simply, I feel attractive to run videos including techniques to end a game rapidly which has runners knowledge. In case of death earlier than changing costumes, we will choose death. It's on a case-by-case.

That's my opinion. Thanks reagards.

(don't mind me, I just like to participate in the debate a lot, even if it means that I'm incidentally taking a lot of space and visibility)

Kollieflower :

Ultimately, what we're trying to do is make those IGT speedruns look like RTA speedruns, in the feel and pace of the run. Which is why disallowing the warping trick in general and moderating pausing and time management (at least at top level) is crucial in order to simulate such a speedrun. I'm repeating myself, but moderating pausing for lower level runs would probably be a waste of effort on the moderation side. The time-saves pausing yields are too insignificant at lower levels, compared to just playing better and using new/more optimised techniques. Thus runners are not really encouraged to use this trick (which would be a burden to them anyways, as it just goes in the way of gameplay and movement). So because of this, I statistically believe the timer won't be abused in general and trust that that players will most likely mind their business actually playing the game. And even then, these particular runs won't lose too much integrity out of it. Hence why, there would probably be no rules about general pausing for when the leaderboard opens.

FPS moderation is most specifically designed for PC runners since they're the only one who can affect the framerate of the run (and very easily so), regardless if it's intentional or not. Some people might unknowingly be playing on a completely different FPS than the game, while others, accustomed to other speedruns where FPS is a major component, might enter new games with different framerate values due to habits, or stemming from their first playthrough or something. Regardless of their reasons, we have already met KPRS runners that have done runs of the game with different framerates than the game intends, so it's only natural to expect more of them to come up in the future. Therefore why this point is important

In some way, allowing PC players to bind the Support move button to their controller is essential. I have heard that otherwise, setting the Support mode up for a one player usage is immensely more difficult to set up there than it is for console runners.

I think in general I'd see myself keeping the game vanilla at all time. I feel that modding it, even just for inoffensive aesthetic changes, would still harm the integrity of the runs. Like if you replace Klonoa's model to Sonic just for the visual giggle, to me it's just not KPRS anymore (another example : Stepping Wind to Snow Halation). If you put simple legit track remixes, I also don't know if they would do, even if they were to actually fit the game. Obviously though, outside the leaderboard, everything is possible. Don't let this hold you. As tracksuit said, it's probably better to disallow all mods for the time being. And let's not forget that console players do not have access to this luxuty, even down to very simple mods that try to fix the game like incorrectly animated cutscenes.

Rest I agree.

godjou : I get your concern. The truth is, my post was originally intented to have much more to say on the topic of the warping technique, but I ended up discarding it at the end. One reason for it was that we didn't (and still don't) know much about the possibilites and actual usefulness of the warping technique. Therefore, it is pointless to try and make exceptions to it, especially when... read further below. I am onboard with the idea that in the future, we could allow exceptional uses of this technique, for normal speedruns. But only after we have a clear enough picture of its uses and usefulness. For instance, in 1-2, the stage the warping trick has been discovered (by BobbyKaze), you would think that it saves a lot of time, and is a must go strategy if you want to be fast. But testing shows that the actual time-save is underwhelming. It's like 5 seconds slower than RTA, and even for IGT, it possibly only saves one second, and that if you play well enough. Suddenly, not that much interesting. This is the sort of thing we need to know in advance before we make any exceptions.

Now, about ending this discussion and making the final changes, I do not have a deadline in mind. But if the thread quiets down in the following days, I'll assume that things are mostly settled, and it will probably be time to make the changes.

If you haven't read it yet or are planning a response though, please warn us.

I completely agree with the Balneor's post. By the way, what plan do you prepare about category? For now, setting up Any%(or other name) that banned "pause warping" as main category, and about other categories(aiming low IGT, No skips...) are hold on now, when game updating will come or discovered new glitches, we'll discuss about these, right?

Exactly Neko. It's better that for now, we focus our attention on the simple and most popular categories.

Currently, we shouldn't try and establish special categories like no skips and Low IGT, because we don't really know how normal runs would look like (I sure don't), let alone these special speedruns. And also, if new techniques and glitches where to keep being found as we are discussing these categories, it would strongly make us lose time by having to spend additional time deliberating, each time. This latter issue actually happened as I was writing my full-game post, which as a result delayed it by a couple days, and is one of the reasons why I ended up postponing Low IGT category design discussions. In the future I'll be sure to not make this same mistake twice, not losing time on lower-priority stuff

Also, I realize that I will need the official english names of all the Lunatea's Veil remaster stages before I can add stage ILs (DtP will simply follow the "Vision X-X" structure). Can someone list them to me (plus the two extras) ?

Here you go Balneor, afaik no names were changed, but i checked my vods just to make sure.

//Name of the stages (plus the subtitle of it, in the case of the bosses, it's their name) Will mark the bosses with * //

Main Story:

Sea of Tears (The Encounter) La-Lakoosha (Sacred Grounds) Claire Moa Temple (Folgaran the Armor Beast)* Jungle Slider (Raging Rapids) Joilant Fun Park (A Date with Tat) Joilant Plaza (Leptio the Flower Clown)* Volk City (Through the Crossfire) Underground Factory (Bowels of the City) Volk Hall (Mobile Tank Biskarsh)* Volkan Inferno (Imminent Danger) Ishras Ark (On To Mira-Mira) Mountains of Mira-Mira (Alpine Wonderland) Maze of Memories (The Laberynth of Illusions) Indecision Pass (Polonte the Hatchling)* Noxious La-Lakoosha (The Catastrophe) Dark Sea of Tears (Veil of Darkness) Empty Sea of Tears (Beyond the Sands) Embryo Compass (Cursed Leorina)* The Ark Revisited (Countdown) Kingdom of Sorrow (Where Sunsets Dream) The Forgotten Path (Deliverance) Terminus of Tears (The King of Sorrow)*

Finally these are the 2 extras:

Chamber o'Fun (Klonoa's Whirlwind Challenge) Chamber o'Horrors (Klonoa's Hurricane Challenge)

Thanks, saving them and implementing them later.

Now, while the discussion is going on (though it might end soon), I would like to ask for a slight leaderboard variable change : pushing the difficulty categories before the mode category.

Assuming that in the future we consider adding special categories like "no skips" or "Low IGT", it's possible that we may need to add additional variables to create new categories. Which may be a reason why we may want to order these variables in terms of their relevancy, from most relevant to least.

Naturally you'd have the actual categories at the top, it's just mandatory. Then the difficulties, which is just normal behavior of the game. Nothing to be said And then you'd have the Support variable, not really supposed to be used for anything else than assist the player, but still a deliberate functionality by the developers. But then, you "may" (because it's completely unofficial, just proving a point) have a variable saying if you've used skips or not. Here we're already starting to completely break the game, but it's still easy to follow up upon. Finally then, you could have a Low IGT related variable, where at that point you just completely disrespect the game with overpowered tricks, and manipulate time at will to hopefully edge out normal speedruns IGT wise.

The last two's existence are still up to debate, but you can see that it would probably be interesting and fun to have these variables be in order. I also know that having potentially 5 category distinguishing variables is crazy and excessive, but it still seems like the easiest and simplest way to add these two speedrun types in the future, and still make the leaderboard readable and clean. Either way, let me know what you think. The change won't do anything to pending submissions, it will only reverse the order of two variables.

Added all stage ILs for the time being. They're not open yet but it doesn't hurt to add.

I felt that laying them out in their order of appearance fitted the most. Also, stage ILs shouldn't include bosses, because those have reserved slots in boss time-attack. And it would defeat the purpose of helping with comparing stage portions between IL and full-game runs

Edit : I have just realized that in the IL overwiew page, some of the verified submissions do not appear to show up. After further inspection, it does only seem to display times that are made on the first category distinction of each variable (so, Standard Mode and Easy). I'm afraid there's not gonna be much we can do. Even if we only kept the difficulties variables around, the problem would be the same. Sucks, but manageable.

However, I have one thing to say here. This is because I don't think anyone probably cares. To be clear, I consider the act of tying a 2P controller for assist to a 1P to be cheating by an external tool, unless you use an official Steam function. In other games, it is similar to Mario 64's controller switching or JRPG's turbo. However, I understand that it is hard to tell the difference, but I would like to see an item or input indicator that would tell me if it is a tie or not. I don't think it is required. I do not want to do these and will run with the console. I will use a converter, but 2P mapping is not possible unless you use very specific hardware. I think it would still be more reliable proof than an input display.

I thought most people were fine the way I suggested it, though no one really commented on it

To be perfectly honest, I know absolutely nothing about this stuff, and I'm not qualified to help with anything related. In fact I'd have to be taught.

I don't know if Steam has functions like that, I don't even know exactly how you're normally supposed to play 2 player mode on PC if let's say there were two people. If you even can in a easy, official way. Lots of ifs. It should be obvious that using scripts, turbo and macros are banned. Makes a significant difference on the run when it should normally be off-human-limits, and console can't use them. Abiding by this, using external other softwares may be considered fine. Besides, it's not like we can make sure of it without explicit proof.

I am lost at the mention of a converter. What is it, and why do you think it is more reliable than an input display ?

I am not sure what you mean by item and input indicator. If you mean a variable, yes it is possible. We would simply need that we define the possible situations that the variable can track. Which is hard for me to picture since I don't know how the process visually looks like on PC, so I don't know what could be the best English terms.

I always felt that this subject wasn't of much importance, especially because it only concerns PC players, which have it completely differently with input devices anyways (they have access to many different controllers, and keyboard =/= other input devices). It remains true however that it doesn't hurt to add a variable about this, even if I lack knowledge over this subject to understand its relevancy, and that I wonder if knowing that people bind controllers for Support Mode will ever actually become meaningful to know.

Anyways, that is something I will probably leave up to you to manage Haru, and for the people to discuss, while I try to follow your tracks. Though, please keep in mind that if it gets too complicated, or imply additional regulations to the like of the FPS situation - which is already complicated enough, as every computers are different and need trial and error solutions to play comfortably in 60 fps play - I think it would be best that we simply drop this issue altogether. It's really not that important in my opinion.

As for the leaderboard making progress, I don't think it should be delayed for the sake of this inquiry. It can be added as we go.

That all I know to say

I have absolutely no opinion on the issue of whether to ban binding two controllers to one. There are probably other games that have exactly this same situation (not just analogous, but actually the same) so it might be worth looking at them, but I don't know of any off the top of my head and I'm not sure if I feel strongly enough about this issue to go looking for them right away (although I probably will at some point if no one else does).

Regardless of how that's decided, though, I definitely don't think we should require any additional proof standards, especially not platform specific ones, based on what we know currently. The FPS display already seems like an unfortunate hurdle (but ultimately probably worthwhile, mainly to avoid accidental "cheating"). Obviously an input display is a nice thing to have, both as a verification aid and more importantly (in my opinion) as something to help other people learn the run more easily, but I'm not sure it should be granted any official, special status. I certainly don't think it should be a requirement on any platform.

I do seem to remember there being some fairly strong opinions on both sides of the issue regarding the controller binding issue, though, so it's probably worth taking the time to actually get some real data about how the majority feels.

I agree that this shouldn't delay the leaderboard, but if we do open up submissions for this category we probably should add a note in the rules that this issue isn't decided yet. That way people will be prepared for the possibility that runs might need to be removed and that we may need to go back and ask people what tools, etc. were used.

Though forcing players to set the fps to 60 is unfortunate, I do feel it is necessary since the game does play differently at different frame rates that can allow different strats at different frame rates. I don't think setting the fps to 60 is all that cumbersome to set up, and with Steam's built in FPS counter it's easy to get that displayed.

I think PC players should be allowed to bind support jump to the same controller as player one if they want to but I have no strong feelings about it.

Input trackers should absolutely NOT be required. They can be nice to see for people wanting to learn button timings but they should not be required to be accepted, in my opinion.

I wouldn't want to force a resolve to this issue, Haru, especially if you were planning something for it.

But it seems that most if not everyone who expressed their opinions on the Discord, seems okay with leaving it be. For mostly the same reasons as my post : accessibility for PC, minor to insignificant advantage, and a absolute pain to police. And not really cheating.

In other news, I believe I have mostly finished planning the rules and leaderboard changes once we are good with opening it. Which will probably be around friday or saturday, just to allow a tiny more dialogue.

As for moderators and reviewers, I and Haru will clearly not be enough for the massive workload, so we will need more people. I will expand on what we could do later.

I suggest that we add Neko as moderator, since he's working on running both games, is very good, and would like to become more involved with the leaderboard and moderation side of the game, something I believe he didn't have much opportunity before.

For verifiers, I'd propose we add BobbyKaze. Even not taking account of his past whereabouts, he's very present and active, a efficient game-breaker, interested in probably about anything. He could most certainly at the very least help us with verifying runs. Amoser also proposed himself (albeit in the non-public run reviewer channel) to help with the reviews of this game, and although he hasn't necessarily done a ton with the game, he's still interested in it, has helped with discussion, and is reliable as proven in other games.

I also think I'd be fine with taking brand new people as well. Wouldn't want to always reuse the same people and make these positions effectively unreachable to rising newcomers. Besides, bringing in some fresh air is always good and more fun. So, I think that the requirements would ask applicants to show/have shown interest and investment in the game, are at least decently good at it (enough that they understand what's going on in a run, and perhaps grasp their pace), and being active in the community. And obviously, free-time. This is voluntary work. Additionally, the person would be required to be present on the Discord server. This is necessary as long as you have at least a position in one of the Klonoa boards.

If anyone is interested and think they fit these requirements, please don't hesitate.

This might be a bit early to announce, but I think it doesn't hurt. I'm much less sure if this is how you'd properly handle these things, but at least I tried.

Once the board is open, we will probably review the earliest submissions first, and slowly climb up time. There currently are 72 pending submissions.