That's more the point I was trying to make. Yes professional musicians and athletes invest quite a lot of time. When I asked my favourite jazz pianist Michael Kaeshammer how much he practices, he told me it was typically about 5 hours a day. (!!) Nobody is that devoted to Tetris. Famous TGM player Koryan kept track of his Death Mode performance religiously, recording his attained level for each credit and publishing it on his website. It took him 426 days and 3851 credits to reach Death Gm. That's about 9 credits per day. With an average play time of, say, 2 minutes, you're looking at 18 minutes a day. The estimate could be further improved by considering his survival rate for each credit to get a more accurate average play time, but I think I'm pretty close (I'm too high if anything). I can play the Maple Leaf Rag and do some simple improvisation... It's far outside the leagues of a professional pianist but enough to impress the average person. Lots of people have muscular bodies without looking like bodybuilders. All these things take is small amounts of persistent practice. For some reason things change when Tetris is your hobby... All it takes to succeed is small amounts of determined practice persistent over time. You don't have to sacrifice anything (except possibly your wallet... holy crap Koryan has spent more than I have buying the game and an Astro City cabinet).
And so do the professional tetromino game testers who post videos like the groundbreaking-at-the-time Death_800.mpg to arika.co.jp. But otherwise, you have a valid point. (and now back to your regularly scheduled Gravytris/Lockjaw/TGM speed curve discussion)
Just a quick FYI that all those videos feature regular players you'd be likely to see frequently their local TGM machines. The video you mentioned in particular features a player called NOV, as the video labels. Arika has not paid any of them, though occasionally winners of contests were awarded merchandise.
ok, if around 122 ms is the minimum humans can handle, what about this sigmoidal lock delay curve? drop speed is shown in units per frame and maxes out at 20 units per frame. lock delay keeps fairly constant at 500 ms till around level 10, then mostly linearly decreases till level 20 where it reaches the human limit. then - to force a game to end, it drops till zero. would this be a good lock delay curve ??
In actual practice you are forcing the player to play: (time taken to fall) + (time taken to lock) To approximate it, assume the piece falls 10 spaces and the lock timer is not reset. If you combine your curves to make this "practical curve", you'll see it speeds up rather unevenly. Anyways, why do all this work? All the formulas in the world won't make the game better than if you simply picked individual values. In fact just looking I can see the game would jump quickly from (near) 0G to the most annoying part of TGM: The frustrating 400-500 section that lacks the determinism of 20G while enforcing most of its placement limitations. Very few players will ever see 20G (which isn't that difficult on its own) and will need to play 2-3 pieces a second to once they are there because of the short lock time.
@colour_thief: thanks, i will rethink about that "dropspeed+lockdelay" issue. i just want to combine speedcurves that in the beginning are suitable for casual gamers and in the end are more interesting to progamers. the reason why i dont just choose predefined values for different levels is that i do not have discrete levels anymore. levels increase continuously ala level 3.0 .. 3.1 .. 3.2 etc. so i need a way to calculate the current drop speed and lockdelay given a floating point number level value.
herc: some ideas from a non-expert: Drop speed needs to start slow, around 1 second to fall by 1 cell at the beginning of the game. Then you slowly start to get faster until it's around 2 frames for 1 cell (1/2 G). Lock delay should be 500ms until at least this point. After a couple of levels at 1/2 G, give them 1 G for a couple of levels, then 2 G for a couple of levels. Then go straight to 20 G. After they've got used to 20 G with 500ms lock delay, slowly start taking away lock delay time until you get to the limit of what is actually possible. I think that would be around 200ms. As for not having discrete levels, that's not really a problem, either. You set specific numbers at the start of each level (drop[] = {60, 55, 50, 45, 40, 35};), and then level 3.2 is 20% of the way between drop[3] and drop[4]. I can write some psuedocode if you need me to explain how to do that.
@lardarse: ahhh - of course! just interpolating between values for discrete levels is of course also a way to go! and thanks for your suggestions how to shape speed and lockdelay depending on levels. i think i will mostly stick to your scheme and tepples suggestions.
Taking fall time = 20 rows / gravity assumes that the player bravoes after each tetromino. Sure, this is the case in comedy routines but not in actual Tetris. How hard would it be to adapt the analysis for a typical height of 8 blocks in the field, which would make fall time smaller? For Master style speed curves, you might want to approximate fall_func as a 2-segment piecewise function due to the abrupt slowdown at 200.
I know you like functions, herc, but there are gameplay advantages to quantizing things coarsely like TGM does. It keeps the gravity more predictable.
There's actually another thing you can do... have a curve for each section. Although, you are almost already at defining each level...
@tepples: 2 good points: 1. didnt thought about the real life situation - so reaction time would be in the sections where G<20 indeed only about half the time as displayed in the graph. 2. yes, piecewise would be a way to precisely remodel TGM curces, but i dont want to copy tgm in too much detail. i just want to capture the rough idea. and personally, i even dislike that decline in drop speed around 200, because it disturbs (my) game-flow. @colour-thief: this is a very very good point, i was actually thinking about quite a while after i did these curves. it is much better to actually be able to settle at one speed level , then have a new section and make a mental switch: "oh - now i have to play faster again"... but with continuous functions, this would not happen. but maybe it would be playable as well, because slowly increasing speed creeps subconciously into the mind.. but maybe not. probably its better to have discrete speed steps... lardarse: well - if i would do different curves for different sections, i could as well stick with a lookup table and step-like speeds. probably also because it is better for gameplay, as colour_thief implied. i just wanted to have simple formulas to keep code clean and simple. and more flexible. so i was rather forcing my idea more out of coding reasons and not with the goal to improve gameplay or such. the only goal was to make it a bit more beginner friendly by a slower increase of drop speed in the first 300 levels.
@lardarse: sure, i would agree with you. its just to throw you out of the rythm and maybe add some more gameplay variety. but i think its in the end no good, because it disturbs the "flow".. ok, now another take on speed curves, this time quantized every 50 pieces / level steps. now i an play a level/speed up sound every 50 pieces and the player can prepare for a new speed level:
Do they have "Dance Dance Revolution" or "Dancing Stage" or "In The Groove" where you live? Go play "Healing Vision" or "era (nostalmix)" or "Paranoia Survivor" or "Sakura" or "Burning Heat!" or "Tough Enough" or "VerTex" or any other song that has a bunch of BPM changes or stops. I see that the formula for fall rate is exponential. That reminds me of another "exponential" curve from some fan game.
Bringing up DDR also brings up the point that there's a difference between changing the rhythm for some reason and just being a pain in the ass. "Sakura": there are actual tempo changes in there, so it works. "Paranoia Survivor": more a pain in the ass. "Chaos" (had to add this one): so spectacularly annoying and gimmicky that somebody at Konami needs to be hurt severely. Applied directly to Tetris...well, there are a few directions to apply it to, so I'll go one at a time. First, the 200 slowdown: I honestly think the whole point of that is for the newbs who are struggling around 1g, though once 1g is simple to a player, it can just be a pain. That's one part that has to be analyzed from at least two perspectives (newb and post-newb) to understand; it's also early enough in the game such that both groups need to be made reasonably happy by the final decision. The second is exponential vs. discrete speed curves at 20g. With a discrete speed curve, a player can get into a rhythm (by any definition of the term) for one section and have to change the rhythm when the next comes. Then there's the exponential speed curve, which is trickier to analyze. Naively, it's just saying, "Go faster, whatever you're doing." More in-depth, there's a decreasing lock delay and a decreasing ARE to consider in this case. A lock delay decreasing continuously is no problem; it is saying precisely that the player has to go faster no matter what else is happening. All hiccups in this case are based entirely on the player's speed since the player should always be ahead of the lock. A continuously decreasing ARE, though, is just getting in the way of a player getting a rhythm, as a CONSTANT (the player has no control over it) which determines the player's actions keeps changing without much warning. With that, I'd say that having the ARE change at anything other than a section transition is just killing the rhythm while changing the lock delay works at any time. Yes, that was wordy.
@airgear: and what if a game had ARE-chancelling (triggered by key-up event)? for example by pressing a left / right key during are ( just holding down still charges DAS) ? in fact, i dont like ARE if you cant chancel it by either tapping left/right or pressing drop / down... but maybe it would even more distorb rythm ?
