Tetro TUI is written in Rust 1.95.0 and can be compiled as usual:
bash复制代码
git clone https://github.com/Strophox/tetro-tui
cd tetro-tui
cargo run
FAQ
How does the base game work?
Tetro TUI is about tetromino pieces falling from the sky and stacking inside a 2D playing field. When horizontal lines are filled they automatically clear away and everything 'stacked' above moves down.
A skilled player may keep playing indefinitely.
Different game modes will change up the gameplay while still using the same base mechanics.
How good is it in terms of configuration / features?
We provide a solid amount of customization options / features for casual and (potentially) experienced players alike:
Graphics: Unicode/ASCII/Elektronika styles, old-terminal-compatible or very modern designs, 10 color palettes, hard drop/piece lock/line clear effects and much more.
Game mode miscellany: Regular ('Marathon'), Swift ('40-Lines'), Classic & Master (unlocked after Regular), Puzzle, Cheese, Combo, Custom (select: win condition, initial gravity, toggle: gravity progress, no top out, cmdline flags: start board, seed).
Highscores, replays, statistics, ... - can be viewed as well as backed up with a simple savefile.
Visuals can be customized together with your underlying terminal settings.
E.g. one can set a bigger font to scale the game, or use cool-retro-term for a nostalgic look etc.
See also: Big overview of actual Tetro TUI v3.5 menus:
- Title screen -
New Game
Settings
Scores and Replays
All-Time Stats
About
Quit [←↓↑→/Enter/Esc/Del] or Vim, Press [?] to view keybinds anytime
+ Start New Game +
Regular: Clear 160 lines as gravity increases.
Swift: How quickly can you clear 40 lines?
(unlocked after Regular) Classic (lvl 0+)(*): 'NES' Gameplay/Graphics settings recommended.
(unlocked after Regular) Master: Clear 320 lines at instant gravity.
Puzzle: Clear 24 hand-crafted puzzles (feat. the Ocular rotation system)
Cheese-40: Efficiently eat through some lines. Limit∈[None, Some(10), Some(11), .., Some(40), ..]
Survival: Lines regenerate as you place more pieces.
Combo-30: Get consecutive line clears. Limit∈[None, Some(10), Some(11), .., Some(30), ..]
(unlocked with Ctrl+U) Placement: Practice placing pieces.
(unlocked with Ctrl+U) Ascent: Experimental gamemode (requires 180° rot.)
Custom: [Del]=reset
Initial fall delay = 1.000000000s (Gravity: 1.00 Hz)
Why do some gameplay preferences (DAS/ARR/SDF...) or some keybinds (Ctrl/Shift/Alt/...) not work for me?
It is likely that your current terminal provides too little input information to enable custom timings¹ or those special keys.
(¹Instead, DAS/ARR/SDF will be determined by how quickly your terminal sends key-repeat events.)
If possible use an enhanced terminal like Kitty or Alacritty (also others) for flawless game handling.
Explanation:
The fundamental problem lies in how terminals usually send input signals.
Due to historical reasons, most will only send "key pressed" but not "key released again".
This makes it impossible to implement mechanics such as:
"If [←] is pressed, move left with a certain speed until key is released again."
Affected mechanics: Generally unable to actually 'hold' any buttons; DAS & ARR & SDF determined by terminal (& holding Soft Drop may 'accidentally' lock the piece), unable to hold Teleport, unable to hold for IRS/IHS/IMS/ITS.
Note that some terminals e.g. on Windows do send key-release signals, without this being auto-detected:
Use the override in Advanced Settings for such cases.
Also due to history, modifier keys can only modify 'actual' text signals and are never sent by themselves.
Affected mechanics: Cannot register modifier Ctrl/Alt/Shift/Win/⌘/... as individual key presses.
Where's the config file? Will it clutter my system?
The application will not store anything by default and 'Keep save file' needs to be opted in;
The exact location of the config file is shown in the Advanced Settings menu and is based on dirs::config_dir():
Usually /home/yourname/.config/.tetro-tui_v1.0_savefile.json
or C:/User/yourname/AppData/Roaming/.tetro-tui_v1.0_savefile.json
Savefile grows primarly due to number/length of saved replays.
As a rule of thumb, 1min of gameplay with fast inputs adds ≲ 1 kB.
If you end up with a lot of play time but can't/don't want to spare the kB / MB, you can:
Delete some entries (// just their replay data) in Scores and Replays using [Del] (// [Alt+Del]).
Configure which categories of data get stored in the first place on program exit (see Advanced Settings).
Experienced players: How does it compare to (or deviate from) common stacker games?
At the time of writing we implement all the most common mechanics found in the wild (and then some).
Groups of (e.g. gameplay) settings are bundled in a 'slot'(= settings template/profile) which allows us to provide common presets as well as our suggested defaults.
See list of notable differences:
Keybinds:
Default controls suggested to be WASD + Arrow keys (reasoning: We prefer to assign movement and rotation to separate hands instead of mixing; do not use Shift key due to common terminal limitations).
Dedicated buttons supplied for Rotate 180°, Teleport Down ('Sonic Drop') and Teleport Left/Right.
Gameplay:
Default rotation system suggested to be the Ocular Rotation System (reasoning: Ocular is designed to be symmetrical, intuitive and flexible (in different ways) compared to the quirky / sometimes asymmetrical 'Super' Rot.Sys.).
Default piece randomizer suggested to be a Recency Randomizer (reasoning: 'Recency' is biased toward 'fairly' choosing less recent pieces but still technically allowing arbitrary piece sequences, compared to the 'overdeterministic' 7-Bag).
Points (score) bonus system is currently kept custom and simple.
'1pt for simple line clear, with increasing bonus for larger lineclears, combos, spins and perfect clears.'
Note: 'Allspin' without 'minis' (reasoning: we are not preoccupied with just 'T-spins').
Note: Combos, without 'back-to-back' (reasoning: Back-to-back incentivizes playing special maneuvers, but those already yield disproportionate score bonus by themselves).
Time-based lock reset limit (reasoning: Providing a 'hard time limit before lock'(= N⋅current lock delay) seems more flexible/natural than 'hard move limit before lock'(=N 'moves').
Default speed/gravity/fall curve is slightly less aggressive but very close to standard (reason: We use a simpler formula).
Graphics:
Default palette is more pastel (reasoning: Uniform perceptual brightness, 'looks pretty').
Customizable gravity/fall and lock delay curves (exponential and/or linear; also, '20G' (fall rate of ≥1200 Hz) just becomes ≤00083s fall delay),
Ensure move delay less than lock delay toggle (i.e. DAS/ARR are automatically shortened when lock delay is very low),
Allow lenient lock-reset toggle (i.e. reset lock delay even if rotate/move fails),
Lock-reset cap factor (i.e. maximum time before lock delay cannot be reset),
Line clear duration (LCD),
Customizable win/loss conditions based on the time, pieces, lines, points,
Score more points for larger lineclears, spins ('allspin'), perfect clear, combo,
Game reproducibility (PRNG/determinism).
Experienced players: What is the 'Ocular Rotation System'?
An extensive attempt at better tetromino rotation with regards to symmetry and visual intuition;
The Ocular rotation system affords:
Symmetric/mirrored situations should lead to symmetric/mirrored outcomes (e.g. no distinct but visually identical states).
Rotation generally based on 'proximity where it looks like the piece should (be able to) go'.
Pieces should prefer downwards placement, not 'teleport up' in general.
See this visual/'heatmap' comparison of the 'industry default' rotation system vs. Ocular rotation:
Programmers / Terminal enthusiasts: Can you provide some insight into the programming of this terminal game?
This project handles a handful of aspects to try and provide excellent user experience for a classic game. It also aims to maintain a decently high quality in code. The scope of this project consists of:
Several dozens of configurable, advanced and important options.
Provided pre-implementations of extremely common standard mechanics.
Decoupled core game loop ('interpreter') with ergonomic API (hopefully).
Basic but functional modding functionality with ergonomic API (hopefully).
Different and interesting game modes, including special game modes that rely on engine modding.
Extensive TUI menus to allow modifying all relevant configuration options without being forced to edit the save file manually:
* Graphics options, Configurable keybinds, Gameplay settings.
Providing many curated configuration templates for everything, inspired by existing standards and games.
Sidenote: Ever since its inception as a proof-of-concept the terminal user interface (TUI) has directly and only relied on Crossterm. Currently there appears no need to change this situation, though a full TUI library like Ratatui might be reconsidered e.g. to handle UI translation (displaying other languages) etc.
A competent input-update-render game loop.
Implementing game replays.
Savefile storage:
In particular replay data serialization and compression.
Scoreboard and statistics.
Game graphics renderer that handles all of the effects and dozens of graphics settings, efficiently.
Doing all of the above as simply, ergonomically and as correctly as possible while providing feedback to the user when something doesn't work as expected...
Rust code quality.
What is the motivation behind this project?
Tetro TUI started as a passion project from someone who loves programming, minimalistic games and ASCII art;
Out of curiosity I snuck a peek to see how deep the mechanics of such a universal game can go:
Basic versions are simple to code up, but it gets surprisingly complex when it comes to supporting all the modern/advanced features (especially while dealing with terminal limitations)!
To the best of my abilities I have implemented a most featureful & customizable version that still remains faithful to the essential
idea and also looks/runs nicely within a 'mere' terminal - Enjoy!
☺ L.C.Werner
