Submission #4865: dwangoAC's Lynx Blockout in 03:14.81

Blockout is best described as a 3-dimensional successor to Tetris with shapes of up to 5 cubes arranged in various polyforms falling into a 3D pit. Blockout remains popular as there is still an active community as well as several leaderboards. The game was ported from the original DOS to Apple IIGS, Macintosh, Commodore 64, Amiga, Atari ST, Atari Lynx, Genesis and arcade, with the Lynx version faithfully ported by the original designers, Aleksander Ustaszewski and Mirosław Zabłocki. The original manual is available courtesy of archive.org (albeit with several inaccuracies compared to the released game) and Hardcore Gaming [dead link removed] has a good history of the game's development and subsequent ports].

This run completes all levels of Blockout as fast as possible, manipulating the next piece drop to be mostly 5-cube polyforms. During the run I pull off several stunts including writing letters on the playfield and clearing a 5-layer deep area while simultaneously flushing (completely emptying) the playfield. The end of the run is carefully crafted to allow the last 5 blocks needed to achieve the final level to fall on their own after input has already ended. The run required a substantial number of rerecords and a number of manipulation methods were used to manipulate pieces. This run is like listening to a Geiger counter; the more manipulation that's happening at any given time, the more it clicks.

The Lynx port of the game is very faithful to the original DOS version, albeit with no music in-game and reduced resolution. Like Tetris, blocks start falling and must be placed at the bottom of a well, although at level 0 (the first level you can start from) the blocks fall very slowly - literally 5 seconds between each drop. The difficulty increases every 150 cubes, i.e. the individual portions of a piece / block / polycube. By level 9 (the 10th level and the highest possible level you can reach) the blocks drop one notch every dozen frames or so and it's nearly impossible to intelligently place some of the more esoteric polycubes in realtime.

The game is highly customizable in terms of the pit width, length, and depth but there are three presets - Flat Fun, 3-D Mania, and Out-Of-Control, with Out-Of-Control consisting of all 41 possible 5-block polycube forms and using pit dimensions of 5x5x10 (WxLxD). When the rotation control is set to fast it's always possible to make movement / position or rotation changes every other frame, although it is sometimes possible to have movement directly following rotation which makes optimizing this game a huge pain.

It's possible to press a button to drop the piece immediately, although there is a forced ~25 frame unskippable window following pressing the drop button where you can still slide pieces around after they have touched a surface. This means that the fastest you can transition from one piece to another is 26 frames, but this is only possible when dropping a piece from the starting position (as in, pressing drop for one frame two frames *before* the piece is even visible on the screen). If you need to do three rotations and move a piece to the lower right corner it can take as many as 42 frames. As far as I can tell it's possible to rotate any block into any position with a maximum of three rotations, although sometimes it takes some thinking and there were a couple of occasions where I couldn't immediately figure out if it was possible or not.

Each piece has a flipping end that rotation is pinned on, and this has an impact on when and how you can rotate a piece. After the height gets to within 5 blocks from the top layer it becomes tricky to position pieces - in particular, once you get above that point the long | bar consisting of 5 cubes in a column can no longer be placed on end, although it is possible to position the flipping end in such a way that standing the piece on end forces it into a hole. After you press the drop button you can no longer move a piece from an area under the piece that is lower to a higher area or rotate a piece in a way that would change its height so a substantial amount of the piece movement has to be done prior to dropping the piece.

After the drop button is pressed and the forced "sliding time" window starts it's possible to press different directional buttons to manipulate what piece will appear next, although there is a limited selection of possible pieces that can be manipulated at any given time based on the frame that the piece was dropped on. Pressing directions that allow a block to move out of place is generally not helpful. There is no "next piece" preview and button presses up to about four frames before the next piece is shown on screen can have an impact on what piece will appear. In some cases the frame where the piece is dropped has to be delayed by performing additional otherwise unnecessary rotations or movement or reset by dropping more than once in order to manipulate a particular piece, but this was kept to a minimum. I created a full spreadsheet showing the delay between each block for anyone who wants to look at the variability in depth, but here are some highlights:

Manipulation in this game is nontrivial; many different sequences of button presses result in the same piece appearing, which possibly indicates that the RNG used in the game is seeded by itself resulting in RNG jitter. The RNG seems to have something against giving you the pieces you actually need, but I suspect that what's really happening is some kind of weighting mechanism that tries to level out the types of pieces you will receive to ensure you don't get too many of the same types of blocks. Most of the shapes (28 out of 41) consist of 5 cubes which is desirable for speed but even then it seemed like it kept getting harder to manipulate them. I eventually opted to allow several smaller pieces to appear to even out the weighting somewhat and used the opportunity for some mid-run entertainment.

Sometimes manipulation was as easy as holding a "safe" direction until the next piece appeared, while other times required upwards of an hour to manipulate a particular needed piece into existence, sometimes requiring backtracking to try positioning earlier pieces in different ways. It was often necessary to alter the frame that the previous piece was dropped on to get a usable next piece but in the majority of cases it was possible to get something usable within the forced ~25 frame drop delay. I successfully used a beta version of the "Basic Bot" tool that will be included in future versions of BizHawk, although it was somewhat difficult to tailor to the particular requirements of this game. The majority of the manipulation was performed through trial and error, mashing different buttons and hoping for luck, as it oddly turned out to be more effective than other methods.

I heavily relied on a Lua script I wrote to show when a new piece would fall, and to make the frame display larger to be visible on my high DPI screen. This was very helpful in manipulation attempts as it saved the state at the first frame the next piece could be manipulated. Blocks can be moved two frames before the block actually appears on screen in most cases, so before I wrote the script it was very tedious to determine what frame input for the next piece could be started. It took me a considerable amount of time to find an address that reliably went to the same value at the right time but I eventually determined that 0x5D31 always transitions to 0 when a new piece is about to appear. I was unable to find an address or set of addresses that was reliably consistent for particular pieces, likely because each piece is comprised of several cubes and can be oriented in many different ways.

Now is a good time to note that I completed the entire project using BizHawk 1.11.1 running in Crossover Linux, a paid-support variant of WINE which I have been an advocate of for many years. I had initially had difficulty getting BizHawk to run in this environment, but I discovered that installing all of the BizHawk prerequisites manually (DirectX runtime web installer, the Visual C++ redistributable, and the Windows Imaging Component) along with the Courier New font was all that was required. CPU usage was far lower using this method compared to running BizHawk inside of VMWare Workstation and I was pleased with the stability, although setting the font to 180 DPI did cause some UI elements to become truncated.

I start the run navigating around the menus with the mouse pointer using the dpad. It's immediately obvious the designers were coming from a DOS / PC perspective but they did a reasonable job making the mouse pointer respond to dpad inputs. I abuse an acceleration mechanic in the menu - if you wait for exactly one frame between changing directions your momentum is carried over even when changing screens, allowing the mouse pointer to move very quickly by the time it moves toward the start game button. Rotation speed is an independent control (despite what it says in the official printed game manual) so I set that to fast before selecting the Out-Of-Control predefined setup which sets the pit dimensions to a depth of 10 and a width and length of 5 each.

One of the first things you'll notice is that the white piece outlines are often misleading once they fall depending on the order the piece is moved and rotated. At many points during the run it will appear that a piece is about to be positioned in a bad spot before it mysteriously places the blocks at an adjacent location further toward the outside walls of the pit. This bug is the most substantial issue in the game as I can see it causing confusion in a realtime run as well but it's generally a harmless graphical bug.

The other thing you'll notice is the complete lack of background music and the cadence of the piece turning and rotating sounds. As noted, with rotation set to fast it's possible to perform an action, at worst, every two frames, and in some cases it's possible to rotate and immediately move a piece depending on the orientation of the flipping end and the type of rotation performed. This can result in some rather intense bursts of what amounts to clicks, with an effect similar to a Geiger counter. The sound is compounded when a piece needs to be moved to the lower right corner and heavy manipulation is required for the next piece. In effect, as the frequency of clicks increases you can generally assume that the manipulation effort was higher for that portion of the run.

Toward the start of the run I immediately fill up the pit to its highest point to demonstrate the height bar on the left side of the screen. Unlike Tetris where each piece type is a different color, in Blockout each layer corresponds to a different color based on the layer chart on the left. Filling the pit to the very top in the upper left corner is risky as many pieces are at least two blocks high and will cause a game over so I leave enough room for pieces to appear.

After manipulating 33 5-cube pieces in a row (165 cubes) I take the first of several smaller blocks as a result of manipulation skew and I knock the height back down to something more manageable a couple of times. At cube 386 / frame 3504 I drop a 5-cube | piece in the upper left corner but it doesn't clear all 5 layers; this is because hidden pits remain unfilled which become visible when the next piece falls. I proceed to clear the field down to the bottom with some particularly tricky points of manipulation along the way, especially at cube count 574 / frame 5030 and from 591 / 5190 until 601 / 5500 where I manipulate 8 2-cube and 1-cube pieces in a row which was quite a feat of manipulation but was possibly made easier because of piece frequency weighting.

At cube count 625 / frame 5704 I flush the playfield for the first time, returning it to the empty state it was in when the game started. I take advantage of this blank slate and the perceived need to use some of the pieces I haven't used much to draw a little something on the bottom of the playfield using different depths to color each letter differently. This is by far the most interesting looking portion of the run and it's worth pausing at cube count 658 / frame 6257.

I follow this up by manipulating two 5-cube | pieces to fall in the dead center of the playfield, filling the playfield to the very top, and I successively remove layers from it and even make a completely flat layer at cube count 779 / frame 7330 before returning to a level playfield during cube count 872 / frame 8275. At cube count 1020 / frame 9410 I successfully build up the entire playfield save for the center position to the 5th layer and manipulate a 5-cube | piece to perform the holy grail in the game - clearing 5 full layers ("lines") and simultaneously flushing the playfield. The only greater achievement than this is doing the same thing on the hardest difficulty with the smallest pit dimensions of 5x5x5, which I perform in this bonus movie.

At this point pieces are starting to drop fast enough to be observable; by the time the last level is reached pieces will be dropping so fast that even with frame precision pieces will drop a notch before it is possible to move them. It's possible at the very top of the playfield to not drop pieces and allow gravity to drop them for you but the math only works out on the last level itself and isn't particularly featured in this run, although you can see the effect in the aforementioned 5x5x5 run.

From here on out, the only thing that matters is forcing 5-cube blocks into appearing and creating a playfield and a set of manipulations that allow the final pieces to fall after input has ended. This turned out to be quite challenging as manipulating multiple 5-cube blocks in a row is difficult even when you still have control over input but after backing up several times and trying different combinations of playfield layouts I was eventually able to come up with a result that I was content with. Input ends on frame 11669 at cube count 1320, with the input that manipulates the last piece occurring before it's even visible on the screen. After input ends, a full 5 pieces consisting of 5 cubes drop in a row, perfectly hitting cube count 1350 and simultaneously reaching the final level and filling the pit to the highest layer. I'm quite happy with how this finished up.

As demonstrated in the piece-by-piece spreadsheet showing individual framecounts for each piece there are several pieces that took longer than the theoretical minimum required which might be possible to manipulate faster. It is also possible that the piece weighting limitations can be overcome with fewer frames spent manipulating different pieces, i.e. it might be possible to manipulate a higher ratio of 5-block cubes than what I was able to achieve. Finally, if memory values for each piece are found it would be possible to write a bot that searches for a specific piece rather than relying on human observation which would greatly improve the control possible in this game.

I initially started this run because the idea of Blockout struck me as worth pursuing - Blockout is very challenging to play and pushes spatial awareness requirements to entirely new heights (no pun intended), and I was honestly surprised there wasn't a run of this game already. I'm overall very happy with how this run turned out, although I ended up spending far more time on it than I initially anticipated as is often the case with TAS projects. Thanks go to Mothrays who helped me refine the goal choice and to adelikat who helped me with emulator tweaking. Enjoy!

Noxxa: Added YouTube module.

Samsara: *expertly places run into judging in order to clear lines from the workbench*

Samsara: It looks like a lot of work was put into this run, and it shows in the execution. The constant clicking, knowing that it's piece manipulation, actually added to the entertainment value quite a bit for me, as well as some of the stunts you pulled off (bonus points for doing those without noticeably wasting time). The goal choice was solid, though a bit vaguely explained in the submission text (I had to read it through a couple times to fully understand it). All in all, this is an excellent run of a difficult game!

With very positive voter feedback and a high level of execution, this is now the first Lynx game to make it to Moons. Congratulations!

Also, obligatory screenshot suggestion:
Frame 6257

fsvgm777: Processing.