So. I've been implementing the SRS (I think) wall kicks into my Tetris clone, and I've been debugging it, and I realized, with low gravity and high input sensitivity, some of these wall kicks can "kick up" the piece at a fast enough rate for it to hover or even climb up out of the tetrion. I'm guessing that's bad. Though not much of a big deal at first, depending on the consensus here, I'm thinking of preventing "kick ups" from happening when there is nothing currently underneath the tetris piece. What do you folks think? You can try it out here to see what I mean. Note, I'm still in the middle of programming this thing. To create a new piece, hit the down key. Any input is welcome.
you should fix: J/L CW CCW rotation. swf being at the bottom right covering the game up. the wall kicks aren't SRS. just call it the well, man. =b
Fine. It's the well. I had CW and CCW entirely switched. That's actually a good thing; when they're only partially switched, you've got a bigger problem on your hands. Fixed now. I dunno what you mean by the swf in the bottom right, but since I haven't worked in the View of the game (right now what you're seeing is a couple of debug tools), I'll let that go for now. Anyway. The wall kicks aren't SRS? How do you mean? I used the SRS study to make the table, so if it's not SRS, then I'll probably want to rethink the table. Could you be more specific, please?
is there a way to lock the pieces? it's hard to test the kicks without being able to create a situation to test. i did notice that the L wouldn't rotate clockwise if it was sitting on the floor in SRS spawning orientation.
I'll switch off the gravity. The up key shifts the piece one row downward. And you're right, something's definitely off about this. A lot of pieces aren't kicking off the floor right... EDIT: Yeah, I think the table is wrong. I'll keep working with it. At least the pieces can't climb anymore.
would it be a lot of trouble at this point to let the player make a stack, or can i only test one piece then move onto the next one with an empty well? it'd be nice to test some SRSish twists.
The SRS tables are set up so that it tries a straight sideways kick before any vertical kicks. This means a kick won't go up unless a piece is near the floor or the stack. The Tetris DX table, however, did allow kicking up against a wall.
Okay, I've remade the kick table from the aforementioned site, and tweaked it a bit because the I-piece was acting stupid. Solidification is active, and the hard drop is back. Lines do not clear, so if you run out of space, you'll have to restart the game. Please, take it for another spin. If testing it is still too cumbersome, let me know. I'm considering making a temporary hot key to quickly reset and restart the game. And remember, it's not finished.
Do I get a cookie? By the way, you should make the well higher (as in, invisibly extend past the visible area), I can't rotate an I piece vertically when I'm almost topped out. Your randomiser seems good, so far I haven't had to leave any holes due to unplaceable parts (something that I can't say about tetris DS), is it a memory randomiser or bag?
It's bag!! *yaaay parade* Though I call it "Hat", it's more proper-sounding. There may be a small issue with the Hat, but getting the wall kicks right takes precedence. Speaking of which, what's the problem now? Forget the colors, aren't the orientations at least correct? Refresh your browser, maybe. I should add build numbers to help make sure people's browsers aren't caching the SWF file. You say the well should be visibly higher. See those red pixels along its left side? That's to help count the rows; there's twenty-two, plus the floor of the well makes twenty-three, at my last count. The top two are visible now, but will be invisible later, and will hide the current tetris piece when it's made until it falls two rows. Is that right? UPDATE: fixed the hat, for what it's worth. And hitting backspace will now quickly reset and restart the game.
well at first the initial orientations were SRS. now they're different. also, the orientations are off. Have you played an SRS game before?
What was this "small issue"? Don't tell me it will give me unplaceable parts now, or I'll strangle you. (Random thought: how about making a memory bag randomiser? Would that be possible? A bag randomiser that tries to avoid giving duplicate pieces in a row...)
Okay.. I just tried again and I was unable to reproduce the bug... The one that didn't work was a two step t-spin triple: Code: XXXXXXT... XXXXXXTTXX XXXXXXT..X XXXXXXXX.X XXXXXXX..X XXXXXXXX.X Instead of rotating into the hole (t-spin single-style): Code: XXXXXX.... XXXXXX.TXX XXXXXXTTTX XXXXXXXX.X XXXXXXX..X XXXXXXXX.X It did this: Code: .......T.. XXXXXXTTT. XXXXXX..XX XXXXXX...X XXXXXXXX.X XXXXXXX..X XXXXXXXX.X ... I'm pretty sure I didn't rotate it the wrong way... But then again maybe I did... Let me try some more..
That worked fine for me. My guess is that you accidentally rotated early: Code: XXXXXXT... XXXXXXTT.. XXXXXXT.XX XXXXXX...X XXXXXXXX.X XXXXXXX..X XXXXXXXX.X Code: .......T.. XXXXXXTTT. XXXXXX..XX XXXXXX...X XXXXXXXX.X XXXXXXX..X XXXXXXXX.X I tried TSTs in both directions, with and without the TSS cave thing, and that didn't happen...
Code: T TTXX XXXXXXT X XXXXXXXX X XXXXXXX X XXXXXXXX X Probably not but maybe the wall was not tall enough?
The kick table I'm using simply runs through a list of offsets. When you rotate a piece, it tries to offset it by (0, 0). If that doesn't work, it tries something like (1, 0), then (1, 1), then (-2, 0), then (-2, 1). All depending on a few piece-related game states. But the rotation you're trying, which is T1 to T2, should consistently use the 3rd offset in that situation. If a piece doesn't swivel the way you expect it to, then it should do so consistently. Try that swivel without the T-spin triple and see if it's reproducible.
