Lowest KPT challenge

[belzebub]

I agree, and this is exactly what raw KPT does (it's especially nice because you then have this nice relationship of TPM = KPM/KPT (which is something you lose if you use mKPT)). The real problem is that we can use in-game features to exploit this metric. The KPT is still accurate, but it is no longer a representation of the type of game we're interested in. I believe the type of game we're interested in is the type of game Lapsilap played.

So then, the features that change the type of game we're interested in are:

• Letting the piece drop on its own to bypass the harddrop key.
• Slowing down AR so we no longer need to tap and can ride DAS preservation for several pieces.
• Exploit the hold bug.
• 20G in order to take advantage of mobility factors and/or floorkicks (this one is debatable).

If it weren't for those, the records in this thread would be completely comparable to Lapsilap's game. In order to achieve this comparability, we can do one of two things: either change the rules of this thread or create an alternate KPT metric that does virtually the same thing.

If we change the rules, you'd say: "You must hard drop every piece. Your AR must be 0. Your gravity must be 0." And if you fix the hold bug to boot, this would get the desired result of what we're looking for in a efficiently played 40L game that is comparable to Lapsilap's.

If we create a new metric, "xKPT," then it could look something like this:

• All keys pressed count except for locks done as a result of letting the piece lock on its own, as a result of soft drop, or as a result of hard drop.
• All locks count as +1.
• Fixed the hold bug.
• AR counts as a key press, as a function of DAS. So, holding down the left button results in 1 key press. If DAS = 10 and AR = 2, then each AR event counts as 2/10ths of a key press. This is could be represented as (Total discrete AR events)*(AR/(Min(DAS; 12))) = total "AR-adjusted" keys.

So then, if the thread allows for non-0G play, the 20G players will yield the most efficient xKPT. Elsewise, it would be totally comparable to Lapsilap's game.

The first one is kinda easy, as it is just changing the rules, however it will be difficult to validate if everything was done correctly.

The second one contains validation but it is more difficult to interpret I think. Can you please elaborate a bit more the AR/DAS thing, what you exactly want to counter with that (the low das + das preservation I understand) and what the reason is for your formula. I kinda get it but I want to be sure and I'm sure other people on the forum won't understand it. Also I'm interested in the right interpretation if we have to compare later on.

Do you agree on letting hold count always (also if the piece is not used) and counting the hold press as a press for the current tetrimino (not for the one that is holded)?

Eg, if one tetrimino is hold and one is plain hard dropped, the raw kpt is then 2 (what I understand you want)? Or is it 1 (2 tetriminos ingame, 2 presses).

I propose that we can add as many different metrics for keys as we want, and then choose the unit before the play starts. I'll add the unit between parentheses after the block title, like FINESSE (xKPT).

[caffeine]

Do you agree on letting hold count always (also if the piece is not used) and counting the hold press as a press for the current tetrimino (not for the one that is holded)?

Eg, if one tetrimino is hold and one is plain hard dropped, the raw kpt is then 2 (what I understand you want)? Or is it 1 (2 tetriminos ingame, 2 presses).

Say we have two players who play at the exact same KPS and use exactly 100 tetrominoes. One holds and the other doesn't. If they play at the same KPS, that means the one who didn't use hold will finish slightly earlier. In order to compare apples to apples, we need to use (all keys pressed including holds)/(all pieces dropped) = KPT. That's my opinion.

Can you please elaborate a bit more the AR/DAS thing, what you exactly want to counter with that (the low das + das preservation I understand) and what the reason is for your formula. I kinda get it but I want to be sure and I'm sure other people on the forum won't understand it. Also I'm interested in the right interpretation if we have to compare later on.

I only offered the "AR keys adjustment" as a way to prevent people from exploiting slow AR in order to minimize KPT. Basically, I'm taking the delay of DAS as a "base" delay that we can't get around no matter how efficiently we tap keys. Then, I divide up all the AR delays into DAS "base" units. So, if DAS costs 10 frames every time we activate it, we're saying "well, I'll let you use up to 9 frames of AR before we count it as a key stroke, but once it overlaps the DAS base, then it's going to count against you." In order to prevent people from breaking this mechanism, we need to force a value of at least 1 and at most 12. (By setting DAS to 0 or, say, 100, a player can defeat the mechanism's original purpose.) So then, what this means is

Code Select Expand

(Total number of columns traveled using AR)*((AR delay)/(max(min(DAS;12);1))) = total "AR-adjusted" keys.
So basically, we can either A) make a rule saying no AR delay > 1, B) implement the above formula, or C) just let players exploit super slow AR, such as the replay I posted in an earlier post.