About
Tera: Mind Over Matter is a modern puzzle action game about dropping blocks of different shapes to clear lines. The game has a rapid difficulty curve that emphasizes speed and accuracy. Get as many Teras as you can!
Controls
Left/right - shift pieces left and right
Down - soft drop
Up - hard drop (locking behavior can be changed in options)
Z/X - rotate pieces (direction can be changed in options)
Z+X - hold piece
Changelog
v1.2 | 3/5/19
- Don't reset key repeat for left/right shift inputs when placing a Teramino
v1.1 | 2/17/19
- Fixed incorrect spawn delay curve which caused pieces to stop spawning at high levels
- Score display is no longer limited to 4 digits
- Time display is now minutes:seconds
v1.0 | 2/7/19
- Initial release
Best version of Tera I have ever played. I can see my reflection in the polish on this game. Like, every little detail just makes this a joy to play. This cart is making me wish there was a solid way to play pico8 carts in a handheld. Bravo!!
@paloblancogames I've been playing this on the GameShell by ClockWorkPi and it works great! Awesome job @tesselode.
@tesselode perhaps "Clear x number of lines within a time constraint"?
I have been looking for something precisely like this for a long time. Quite frankly, I'm speechless. It's pretty much perfect!
As for new modes, however, might I suggest a 150-line Marathon mode, or a 3-minute Sprint mode, like some other modern games of the 4-piece block stacking variety?
I like the idea of a time attack mode, where a timer is constantly ticking down and you get time back by making lines.
This is my favorite Tetris on PICO-8! Looks great, plays well (especially with the much appreciated hold function), and has a bumpin soundtrack.
I actually like it difficult, although I seem to get messed up around the 10 minute mark, where I can't auto shift pieces sometimes and then they lock very quickly, and one mistake pretty much dooms me and I can't recover. I don't know if this is by design, I resort to tapping each shift and constantly doing so to avoid locking just to be safe.
Really nice implementation! (although I'm terrible at it no matter how it's called)
Fantastic game! Gets very difficult very fast, but I really love how perfectly it captures... the copyrighted other game, down to how it controls and how it feels.
However, I do feel the input problems that joseph3000 talked about. I think it's from the btnp() function, and how it works. When you hold down one key, the btnp() repeat timer starts counting. When you press two keys at the same time, the btnp() repeat timer resets to make sure that both the btnp()s become true at the same time. This cart is a great example of what I'm (trying to) talk about. If you try to press two buttons at the same time, they line up with each other.
I think this is intentional, to make weird input issues on slower games less of a problem. To fix this, you may have to straight-up overwrite the btnp() function.
Still, even with these input issues, (more caused by PICO-8's function than your coding) this really is the definitive PICO-8 clone of tetr- err... game involving falling pieces made up of four boxes that are affected by slowly increasing gravity.
Ahhh...yes, I thought it might have to do with btnp(), but wasn't sure how exactly until seeing the pad test. It must be when I'm holding shift before next piece (to beat DAS) and then pressing rotate; at super high speeds this effectively cancels my auto-shift and the piece locks where it insta-drops.
ok, i just released an update that removed some vestigial code that was making the inputs stiffer than they needed to be. @joseph3000 @TheV360 how does this feel to you?
I think the stickiness problem is gone...but I seem to have another issue now! Maybe this is a consequence of whatever input changes you made? Sometimes when I rotate a piece, it double-rotates, and therefore I mess up. This only happened sometimes in the previous version, but now seems to happen a lot. I always thought it was my controller at first, but maybe it has to do with the built-in input repeating?
I think holding rotate only counting as one input might help!
Hmm...ok then. I don't hold rotation, but it's definitely double rotating on occasion when I press. I'll try and figure out what I'm doing when it happens.
I tried to fix the btnp() issue by remaking btnp() from scratch. It's not a perfect fix, but here's my code.
___btnp={pause = 8, old=btnp}
do
local b, p
for p=0,1 do
___btnp[p]={}
for b=0,5 do
___btnp[p][b]=0
end
end
end
function update_btnp() -- run this every frame. if 30fps, halve the ___btnp.pause value.
-- b: buttons, p: players
local b, p
for p=0,1 do
if(not ___btnp[p])___btnp[p]={}
for b=0,5 do
if btn(b, p) then
if not ___btnp[p][b] then
___btnp[p][b]=-___btnp.pause
end
___btnp[p][b]+=1
else
___btnp[p][b]=false
end
end
end
end
function btnp(i, p)
p=p or 0
return ___btnp[p][i] and ___btnp[p][i]~=1 and ___btnp[p][i]%___btnp.pause==1
end |
I've been playing a lot, trying to figure out what it is I'm doing to cause the double rotation. I honestly don't know, sometimes I just press only rotate and it double rotates, even at the start when things are quiet still. Maybe it's just my controller, or how PICO-8 runs on my Mac??
I mess up a lot more and it's hard to get my usual scores, but I did just get this :)
Game's alright I guess :P
One thing I noticed, especially past 20G was left/right movement would occasionally lock up for about a second sometimes. Not sure why, might be something to do with how DAS can be buffered between pieces. Regardless, excellent job
tetromino gang (wat) here, got ~1900 on first try. it's always nice to have a new modern tetromino game with good handling but also not completely copy-pasting srs.
though there's still some bit of defects:
the O piece is spawns with 1 grid bias to the left. (although, Atari has their I piece 1 grid to the right)
ISZ are initially all flipped, so, in air, CW/CCW rotation leads to left/right bias.
there's room of choice (and yes some old BPS T® just followed this scheme), but there's also T® DX, that spawns ISZ "facing" up while JLT facing down, and they rotate identically to SRS (except for wallkick).
another game to mention is DTET with its famous 3-positional ISZ, although it's overall ARS-flavored, it also followed CCW-for-left and CW-for-right bias.
it also use only 2 rotation buttons and Z+X is for 180° rotation (works like Z+Z when first rotation succeeds, otherwise will try real 180° rotation), no hold function is present.
imo it's better to use DX spawn position, base rotation with SRS wallkicks. although, SZ under high gravity on the ground still rotates weirdly due to SRS wallkicks...
i can feel the complete "buffering" of actions during the ARE (i.e. spawn delay) that tries to implement what we call Initial Rotation/Move System (but seems no hold :x) but unfortunately it might need more detailed tuning. from a (fast?) player's perspective, i encountered both "kept pressing ←/→ hard but the next piece doesn't move at all" and "already released before the next piece spawns but many repeated ←/→ are buffered then bang i can't predict where the next piece will appear".
this is truly THE detailed part for the tetromino game. of course different implementation exists, but some feels better. the basic rule is, the game got to identify the intent of fast players on how to move the next/active piece by the keystrokes received, that may or may not appear on the right time.
different implementation also fits games with different ARE. like T® Effect Connected already provided options on their types, the keydown event buffering vs. keydown status on-the-last-frame triggering. keydown status on-the-last-frame IRS with 0 ARE just makes disaster.
rotation should not auto-repeat, generally....
IMS (some other name is DAS precharging) is even more complicated (to name some good example, DTET and Quadra made this well). some general idea as my preference, the IMS should buffer (at most) only one horizontal move (only the one by keydown event that happened DURING the ARE), not the auto-repeated ones, especially those "leaked" from the previous piece when harddrop is pushed before the move button is released. but after the next piece spawns, if the move button is held long enough, das should go on (no matter it's newly pushed during ARE or lasted from the last piece)
more details coming, like Quadra cancels any buffer and never accept more if opposite moving/rotation happened during ARE, DTET cancels (actually shrinks) ARE if IxS is triggered. dot dot dot.
some tuning will help making tera capable of being even harder. decreasing lock delay rocks 8)
[Please log in to post a comment]
