[Edit 17 april 2023 : thread renamed from "Banning the usage of pausing for extra vision running" to "About developing the leaderboard". This will now become the main thread for leaderboard discussion pertaining to Klonoa : Door to Phantomile.]

Since Balue's Tower is using the in-game time as its main timing method, it's completely possible though unlikely that people use the pause function of the game in order to either take an undeserved break, or use it to make hard tricks easier or to spend time perfecting their movement without any penalties on their overall times. This would go against the spirit of the challenge. It's similar to the Minecraft pausing dilemma. And I don't think anybody will mind not being able to pause during ILs attempts.

As such, I currently stand in favor of its ban, but I want to make sure we're in agreement before I push anything through.

I agree.

Agreed.

I have no strong opinion so banning it is fine with me.

The only thing that might change my mind is if a really cool pause strat gets discovered that turns it into an entirely different run that wouldn't otherwise be possible (e.g. something at least as interesting as the death abuse, which also exploits the stopping of the IGT), but this seems extremely unlikely given that there aren't even any known TAS strats that aren't already used in the current RTA record, and no pause strats are known to exist in other categories either.

Yea, the clock death abuse trick's also a thing.

It's definitely of a concern. Some IL times on the internet intentionally avoid using for instance. As things are now though, most top runs use it, so I doubt we can just remove it off. Unless we feel very bold. And besides, it's not a super harmful trick, as pausing can be.

... Well actually, should we make a category without that trick ? That would fix everything

(While this happens I'm gonna update the rules with this change)

Maybe a filter/column for whether the death abuse is used would make more sense than a separate category, only because there are already relatively few runs on the leaderboard and splitting it further might make it seem even smaller.

Yea that sounds less harmful of a change. I'll just quickly add in a new variable and work out the rules (Done)

[After four days of no activity, I made the change. I went and introduced a "Hz" variable, and filled all runs with it]

Hello.

Before getting started with the contents of my post, I want to point out that the name of this thread has been changed, and its function repurposed to now serve as the main place for leaderboard discussion of the game.

This is a self statement, but I think it wasn’t a wise decision to have created many threads over every single medium to big changes. Hopefully this should help keep the amount of threads down to a limit. As for the existing smaller threads… we can’t delete them, nor are able to merge them. Will have to live with them.

Alright. With this message, I am proposing the implementation of a new information variable to all runs. This information variable, akin to the game version variable, or disk speed variable, would better help describe each runs. But, not only that, as you will see.

This new information is about the Hz run component, practically equivalent to running speed of the game. All versions of the game run at 60Hz, full speed, except PAL, which is at 5/6 speed.

But, this isn’t actually entirely true. There are a couple submissions who are allegedly played on the PAL version, and yet, the game speed is clearly 60 Hz. https://www.speedrun.com/klonoa1/run/zpqgo48y PSTV also apparently allows to play PAL games at 60 Hz. https://www.speedrun.com/klonoa1/run/y8qp071y And finally, there is a bug that has been known to arise with the USA version of the game when purchasing the game off PSN, where the game can be slowed down to 50 Hz (with sometimes, the whole audio pitched down). I do sadly not have footage of this. As a placeholder, take Klonoa’s catchphrase or some gameplay excerpt of the game, lower the pitch, and there you have it.

So, the game variable cannot help us determine alone if a run is 60 Hz and 50 Hz.

But why would this variable be created in the first place ? Well, there would be a couple reasons.

First of all, it would allow to make such runs easier to find. Between the runs that are in reality 60 Hz, and the PAL submissions whose footage are lost and we’re met with the impossibility of finding out about their Hz, and their very small number in general, it’s particularly annoying to look for them.

Second, it would assist 50 Hz players in finding and comparing runs of the kind much more easily, most notably via the filter option. While 50 Hz gameplay is official and fully acceptable to be played on, quite naturally, RTA wise, it suffers a massive time disadvantage compared to 60 Hz gameplay. Meaning the best runs of which usually sit in the middle.

And third, it would enable us to create a Hz distinction for Balue’s Tower ILs. As indeed, 50 Hz gameplay affect the extra timer, so even though you’re playing slower and have slightly more leeway with timing, the timer will not take this slowness into account. Therefore, without any distinction of some kind, fundamentally incomparable times will coexist and prove to be misleading and inconvenient.

Now, about how to add this. As you read, I first mentioned creating a new run variable. And this implies one thing. For the Balue’s Tower leaderboard, it implies that it will not prevent a 50 Hz run to hold first place over a 60 Hz run. There will be a way to filter runs so you only want to see one of them, and besides, you will know how to identify run and not blindly compare the two. But, there is no hard separation, and I’m aware this may annoy some.

Of course, there are other alternative to this design. With what src allows us to do.

One of them would consist of simply adding sub-categories depending on your Hz. For every category, full-game run and IL. But while this would work fair and square, I feel it would take too much space, and would make that split look very important, when in reality it wouldn’t even affect 1% of submissions, and these sub-categories would most likely be empty all the time. (This is how it would look like : https://imgur.com/a/Ku6ySep)

The other one would be to only establish a Hz sub-category for the extra, and add a Hz information variable anywhere else. Simple in theory, unfortunately less convenient than it sounds in src practice. A variable may either affect all full-game runs, all ILs runs, or a single one of either group. But never more than one. Which means… we would need a duplicate variable for every single IL (because surely enough, one day they will be added)… except Balue’s Tower. From the user point of view, it would also look perfect. But the price would be paid in terms of loss of leaderboard long term structure stability. If leaderboard customization was more expressive, we would be able to do this with two or three variables. But right now, you need like a dozen more. Not fun.

And thus, The simplest, easiest and most efficient method is the “all Hz run information variable everywhere” approach. And it’s downsides are small and quite frankly very manageable.

I will add this new variable in a couple days, and fill every single submissions with it, if nothing transpires since then. Also don't worry, it's easy.

Unrelated to the topic of this post, but I’d like to point out one thing about the PAL version. It must be brought to light that, outside Hz, and in-game different language displays, it is currently impossible to distinguish between USA version and PAL version gameplay. A detection method would be very much appreciated.

After arguably a decade of wait, it’s time we delve into adding one of the most anticipated leaderboard section of this game : ILs.

It’s truly been a long time coming. Here we go.

Discussion on this topic has started on Discord a couple weeks ago. Taking reference from it, I will attempt to draw a rough sketch of what the ILs could become.

First off, a bit of nuance is needed about what we’re about to add.

Technically, we lack ILs for both stages and bosses.

I’d argue though that we should first turn our attention on adding stage ILs before we do the bosses.

That’s because the latter mostly already exists. The Klonoa DtP page of the retroachievement website has had decently active boss ILs for years now (currently dominated by amoser) :

https://retroachievements.org/game/11261

Its existence actually contributed to the improvement of our full-game Ghadius strategies, and to the discovery of the modern Nahatomb phase I strategies.

You do need the retroarch emulator and a ROM to access it, however. Due to this accessibility problem, we're probably gonna have to add boss stuff down the line. We may also want to use a different timing method.

But stage IL wise, we’re empty-handed. It’s quite surprising for a game like this.

We’ve only ever known the stages by playing through them in a full-game setting, using very reliable strategies. Stage ILs have never seriously been tried, even though they have heaps of potential, considering all the crazy strats that’s been found on them since.

Thus, I propose that we focus on them for now.

Similarly, I propose that for every “X-2” stage, we only focus on their stage portion and exclude the bosses.

The intent here is to allow players to fully focus on stage optimization, instead of making them worry about also getting a good boss performance. Which would influence their stage play to be slower.

Alright. Time to go.

Let’s immediately get to the ugly part of this : the timing definition of the stage ILs.

When it comes to finding consistent visual cues, there’s really only so much you can do. I did what I could, and this is my default proposal. If you can think of any viable-looking alternatives, by all means. This time though, I will not go into details about my thought process.

• For the beginning point : upon the first frame that the HUD appears.

It should be easy enough to see even with poor video quality.

Nevertheless, exceptions need to be made for 1-1, 3-2, 5-2 and 6-1. This is because they begin with a cutscene, which displays a cutscene textbox. Problem is, this element has display priority over the HUD, making it basically impossible to read (<youtu.be/PvsRcJ6-Ofk?t=716>)… after verification though, I noticed that both of these elements display at the same time.

Knowing this, we can simplify the definition of the beginning timing point even further : the stage IL starts on the first frame that the HUD area of the game screen lights-up.

(implying that you either see the HUD loading, or the cutscene textbox over it loading.)

• For the ending point : upon the first frame of the screen fades-down, at the end of the stage.

This is applicable everywhere, except for 2-2. There, the stage ends after you skip a cutscene.

I had a lot of trouble coming up with a good cue for this one. But after a while of tinkering, I realized that the cutscene textbox stays for the entirety of the cutscene, until the very end. This is true even if you skip it.

Thus, I believe it to be appropriate that the 2-2 IL ends when the cutscene textbox lowers for the first frame.

...I was expecting that section to be much longer. Good I guess.

Moving on.

As there are four main categories for running the game, the stage ILs should naturally be playable under all four categories

As IL gameplay implies, all runs will have to be timed by the frame.

Like it's already done with full-game runs, it will be necessary for any submissions of these ILs to include information about the version of the game, and the disk speed. As these impact loading-times, and thus the overall time of the run.

That's all I could think of. I hope I didn't miss anything.

The hype thing with this IL system, is that every single segment of any full-game will be compatible with it. For instance, I could start extracting my best segments of my recent any% runs to submit as stage ILs.

I'll let you guys discuss it until say, the end of the week.

I’d also like the opinion of @neko_22 (sorry unrelated person named Neko) and @amoser before we do anything.

I agree with your idea. It's comparatively easy to understand and the rule that can be applied at everywhere.

I think the timing method is good. I am only replying because of the ping, but I did some research, and it seems like using the first frame of fadeout as the ending time would be more difficult than using the first frame the HUD fully vanishes after the screen fades out. I assume that would work for every stage. Please feel free to completely disregard my opinion though! I just learned about this game 30 minutes ago!

I think this should work fine. The only way I can imagine it being a problem is if there's ever a situation where we lose the first frame of the dade-in due to the capture being too dark. This doesn't seem likely to be an issue, and I'm sure we can figure something out if there's ever a problem.

The ending doesn't matter as much, since as long as we wait until the fade out has definitely started, we'll only ever be adding extra frames to the time (not ideal, but at least it won't give any advantage).

I... what a meme now.

My apologies again for summoning you, not "neko_22" named Neko person.

Your proposal for the end stage being on the first frame the HUD fully fanishes isn't a bad one in theory. In practice though, the types of cues where you wait for something to completely disappear in the dark, tend to not work out very well because of video compression. Even with decent recording quality, the footage tends to leave artifacts of the element that's supposed to disappear for the run to end, making it a nightmare to time.

In comparison, the first frame of fade-down is much easier to detect, as even with poor quality, it is clearly visible when the color suddenly switches.

Still, for only knowing the game for that long, this was a pretty well put comment. Quite impressive.

amoser : I'm just praying it doesn't become a nuisance.

I'm leaning on the hopeful side of things. For the sake of this post, I've tested this visual cue on a couple youtube videos, putting them at their worst quality. Even then, the earliest frame was findable.

I may have found a slightly better visual cue for the end of the stages :

Timing ends upon the first frame that the HUD fades-down.

So, instead of it being on the first frame where the whole game fades out, it's on the frame the HUD does.

In terms of convenience, it's not necessarily an upgrade. But the timing cue is more consistent with where the visions each end. The HUD always disappears last, it is in fact the last visible game element before the entire screen gets dark (although in most cases, it actually fades down at the same time as the game view does).

This said, it doesn't solve the case of 2-2. The problem is that if you skip the cutscene, the HUD gets covered by the cutscene textbox. However, the fade-down happens during this exact time. So this method is unusable.

For 2-2 alone, we may still want to go for the previous visual cue : The 2-2 IL ends when the cutscene textbox lowers for the first frame.

Okay, time’s up.

I added the levels, level categories, and wrote the rules (was a bit lazy on that one heh).

Hopefully I did an absolutely perfect job. We can all hope for perfection !

.

Hmmm… I previously said that I found what I argued to be a better timing point : upon the first frame that the HUD fades-down.

But I did an IL measuring test (youtu.be/GFoOErTaM9Q), and I found that it wasn’t holding up so well.

It’s really hard to see when the HUD begins fading down. especially compared to the game view fading down.

So we will probably go with the first solution, upon the first frame of the screen fading down, at the end of the stage.

.

I also forgot about one detail, thankfully it's kinda irrelevant. But you can start with however many extra lives you can. In full-game runs, you always have plenty of spare lives. We don't know of strats where you need to die multiple times to make them happen, yet at least.

It doesn't have to be said, but it's understandable that dying and being sent back to the beginning of the level doesn't count as an IL restart.

For one, the IL is still active, you simply failed a part. But second and more importantly, the game keeps tracks of the cutscenes you activated, and it won't trigger them again if you happen to be sent back. So if restarting the level via dying was allowed, it would allow for an unconventional way to beat some stages :

The player would first reach the end of the stage, therefore having cleared all cutscenes. Because they didn't grab any checkpoints, they would then die in order to be sent back to the beginning, where the IL "starts". The player can then proceed to beat the stage without wasting any time on cutscene skipping, since they won't even show up.

I would argue that this is to be avoided. It's counter culture to full-game runs, where they can't help but play the stage the intended way, skipping cutscenes along the way. You have to remember that our goal and design with these ILs are for the two to be directly comparable. It also goes in the way of practicability, since instead of just pressing start, you need to do a whole setup, which includes reaching the very end of the level and then dying manually... I personally think that resetting the stage by going to the pause menu and pressing retry should be used

.

Oh… and talking about WRs won’t make much sense at first.

Technically, the first ever “IL submissions” come from the earliest recorded speedruns of DtP. So… blackwin5. Setako's 53:04 if we ever find it. And then it continues from there.

Safe to say, none of the upcoming submissions will probably be WR, as I’m sure better times have been produced amidst the hundreds of full-game runs accomplished by top runners.

But that doesn’t mean we shouldn’t try to go up and beyond.

Not that I want to dissuade any weaker IL runners from submitting. We need more submissions from all skill ranges ! And don't forget ! Footage taken from full-game runs is also fine ! That's one of the strengths of this IL board !

.

I'll start submitting some, based on the runs of my any% grinds of a while ago.