When Upgrades Aren't:

The current trend in mechanics customization in official Tetris games is to offer fixed-interval upgrades that can be purchased with in-game points or real world currency. That's not a problem in and of itself, although it does put you at the mercy of designers. (Fan games, on the other hand, give you full control to set your movement sensitivity to your preference, but I digress.) The point of this write-up is not so much a commentary on the numbers that have been chosen, but the fact that these discrete steps players are working to scale haven't always represented actual improvements upon the last. It hasn't ever been as bad as a step backwards (although some may argue that Tetris Online Japan's slippery Level 5 DAS makes the game harder to play), but experimentation and viewing game configuration files has confirmed that some "upgrades" are pure snake oil that represent no observable benefit in-game -- perhaps not by malicious intent of the developers, but by a lack of understanding of their own engines.

In both known instances, the problem has broken down to case where the numbers have changed from one upgrade step to the next, but the inner workings of the engine cause one or more settings to yield the same in-game result. In Tetris Online Japan's Minna de Tetris, the breakdown occurs with Soft Drop Speed Level 5:

[UPGRADE_SOFTDROPSPEED_LV4]
SoftDropDelay = 15
SoftDropInterval = 15
[UPGRADE_SOFTDROPSPEED_LV5]
SoftDropDelay = 10
SoftDropInterval = 10

It wouldn't have been a huge improvement, -- 15ms between iterations is ~60hz (or ~1G) soft drop, 10ms is 100hz (or ~1.66G) -- but whoever authored the upgrade curve at least tried to make it marginally more useful. In practice, they both come out to be 60hz; the engine doesn't actually use the full granularity of the time deltas specified, and essentially just rounds to the nearest frame.

The problem in Tetris Friends is remarkably similar:

public static const kGAMETWEAK_ARR:Array = [50 * 1000, 35 * 1000, 17 * 1000, 7 * 1000, 0 * 1000];

Again, we're running into issues where the engine cannot actually reproduce the effects that the numbers should represent; AutoRepeat Rate Levels 3 through 5 all represent 60hz DAS iteration rates in-game despite the values in the table suggesting otherwise. If the engine were able to handle it correctly, ARR 4 should represent around 120hz DAS (2G), and ARR 5 should represent Instant DAS -- that is, immediately moving the piece to the wall when DAS is activated. Handling DAS rates greater than one shift per frame of game logic would just a matter of looping until all potential shifts are addressed.

Seeing the table of values ripped from Tetris Friends was a moment of validation for me -- so there _wasn't_ a difference! It was a pain trying to estimate values by recording and frame stepping the game when Flash was rendering maybe 30 frames per second -- and inconsistently at that. I ultimately let my assumption that they must be different and small variations in measurements influence my decision to peg ARR 3 and 4 at bizarre numbers like 45 or 50hz. I knew that ARR 5 surely had to be 60hz, but I couldn't believe that ARR 3 and 4 were operating at the same rate instead of just achieving close to the same functionality. It's a little bit depressing to see that the developers either don't notice or don't care that the numbers produce no observable effect when it's just a handful more lines of code to get things working properly.