The idea of beating a game with no input is a compelling one, arguably allowing for perfect speedruns. However, most games in which this is possible are rather trivial. More interesting still is the idea of a game which can be completed without ever even gaining control of the character; although a game that could be won this way would likely be pointless, it turns out that there are highly-regarded games that can be lost this way.

NetHack is an old yet highly regarded RPG. Despite originally being released in 1987, it is still widely played nowadays; the most recent version, 3.4.3, was released in December 2003. Two of its properties make it particularly suited to TASing: the entire game is balanced around the idea that you cannot undo actions and cannot go back to save (and thus tends to be broken wide open merely via the use of savestates), and almost anything in the game can be luck-manipulated without spending in-game time (although it can take some time in real-time), meaning that almost anything can be caused to happen.

This run plays back on JPC-RR version 11.4, but some settings changes are needed. In order to get the game to emulate correctly, you need to turn on the "shorten pipeline on self-modifying code" option (although the emulator should turn it on automatically); this is absolutely necessary as NetHack assumes the processor has a shorter pipeline than JPC-RR uses by default. Additionally, NetHack is a DPMI game; the normal way to run these on real hardware is to add a DPMI extender (such as the one that comes with Windows, or CWSDPMI) to an otherwise normal DOS system. The same thing can be done on JPC-RR to get it to emulate such games, but unfortunately most extenders don't emulate correctly. Thus, I added HDPMI32 (available via the HX website), and run it on the emulated system, to allow NetHack to load; it's the only DPMI extender I know that JPC-RR emulates correctly. (The choice of extender should be irrelevant to how the game plays, although may affect sync slightly due to lag as the extender is loading.)

Following a discussion on IRC (which I thought was between me and Nach, but if it was I can't find it in my logs), the topic came up of which endings to a game are really considered wins. The NetHack community only considers the best ending, "ascension", a win; but the game itself does not define what counts as a win or a loss, and the comment /* super big win */ in the source code next to the code for ascension implies that there may well be other, less super big, sorts of win.

I'm not entirely sure if dying before you gain control of the character counts as a win, but it has to count for something.

Of course, a game where you routinely never gained control of the character would not really be particularly fun to play; in fact, it would be considered more of a video than a game. (Admittedly, this seems to be the goal of some modern RPG designers, but NetHack is not like that.) In NetHack, a death this early has an extremely low probability (almost certainly below 1 in a million, although it's hard to calculate); although the exact rerecord count was lost in a computer crash, I spent over 4 million (and probably around 4 and a half million) automated rerecords aiming for it, using nethack-tas-tools (the project I'm working on with dwangoAC to produce our joint serious TAS of Nethack, which is still a WIP; although I think this run was done entirely with my own code). The run was converted to JPC-RR format after it had been produced.

Everything happens so fast that it may be difficult to follow what's going on, so here's an explanation: first I TAS the FreeDOS boot process in an attempt to end input as soon as possible, then I start HDPMI32 and NetHack, then I load the keyboard buffer with keystrokes necessary to skip cutscenes and clear message boxes, then I end input, then the game loads. (It's a pity JPC-RR doesn't put up the "Movie end" overlay.) The speed/entertainment tradeoff in the run is that I don't skip the game-over cutscene, but instead space through it as fast as possible; I could and the run would go slightly faster, but then it would be almost impossible to see what had happened at all. (Change the last three presses and releases of space, to a press and release of escape, to skip that cutscene too and get a marginally faster run.) In the game itself, a female Tourist comes into the dungeon, finds a shiny artifact silver saber (Grayswandir) on the stairs she entered by (probably the most unlikely thing to manipulate in the run), picks it up (the default options pick up all items you come across), takes damage from touching the artifact (a 1 in 4 chance for an unintelligent crossaligned artifact like the lawful Grayswandir for a neutral Tourist; there are no intelligent artifacts capable of spawning there), and dies from the damage (around a 52% chance for a starting Tourist due to their low starting hitpoints, much lower or even zero for other characters). The game's turn counter says 1, but it always says that before the first turn, and we get the "Do not pass go" message that normally comes from dying on the first turn, a whole turn later than when we actually die (although the message never appears onscreen, as it's skipped by the Esc in the keyboard buffer).

The luck manipulation itself was done by changing the system date and time, which are used to seed the random-number generator.

Some questions people familiar with TASing might be wondering about: the reason there's an unusually long pause after the "e" of "nethack" is that I was tab-completing its name in order to be able to fit more into the keyboard buffer and end input earlier (although it delays the movie end somewhat); the reason that the character selection is specified on the command line, rather than in-game (which would be faster in terms of ending input) is that I don't want to have any control over the character at all once the game's loaded; and the reason that the Tourist is female rather than male is a parser abuse (the "correct" way to specify female is to write "-fem" at the end of the name, and to specify male is to write "-mal", but "-f" is recognised as female and "-m" as choosing a Monk, so the gender was forced to save one keystroke).

Some questions people familiar with NetHack might be wondering about: the item on the starting stairs is picked up via autopickup (which is non-time-consuming (thus the blast happens before the first player action of turn 1, on an effective "turn 0"), and controlled by a game option). The default setting for autopickup in the DOS version of NetHack 3.4.3 is on, thus I had no need to change the options; this run uses the default options. Additionally, there is a bug in NetHack 3.4.3 that causes items on the starting stairs to be autopicked up even if the autopickup option is turned off, so the setting of the option is actually irrelevant to the run. Although I haven't checked, I believe that a sensible pickup_types option setting (that excluded weapons, almost universally true among NetHack players who customize it) would prevent the artifact being autopicked up.

The item generation algorithm is actually room-based; it seems that apart from a few special cases (which don't apply here), and excluding certain item types like chests and scrolls of teleport that have other codepaths via which they can also generate, there is a 1 in 3 chance of items in any given room, with a 4 in 5 chance of one item, 4 in 25 of two, 4 in 125 of three, 4 in 625 of four, etc. (Things like stacks of 7 candles count as just one item, internally.) Then a random location in the room is chosen for each item, in order to place it.

In order to determine the chance that we get an item on the upstairs, we need to calculate the average area of a room. The level generation algorithm makes this very hard to calculate, as it depends on a huge number of things, but on dungeon level 1 it seems most likely to use the "completely random" algorithm, which it tries first before constraining things in order to increase the chance that the room can be placed. This gives a width of 3 to either 14 or 10 inclusive, depending on how much space is available; and a height of 3 to 6 inclusive, with (width-1)*(height-1) capped at 50 by reducing the height. Let's approximate the width as the range 3..14 as there will typically be a lot of space on the level when placing just a few rooms; then trying all combinations, and taking the harmonic average of the areas (necessary because we're trying to find the expectation of 1/area), we get an average area of about 28.149. On average, we have about 0.4167 items per room, so the chance that any item generates on the upstairs is approximately 1 in 67.5.

For any given item, the first thing that is generated is its item type (all randomly generatable artifacts are weapons, so 10% chance of a weapon); then the base item is chosen. The base items of randomly generatable artifacts, and the chance the base item has of generating given that a weapon generates: Demonbane*, Sunsword*, Giantslayer, Vorpal Blade, Fire Brand, Frost Brand = long sword (5%), Grayswandir*, Werebane = silver saber (0.6%), Snickersnee* = katana (0.4%), Cleaver = battle-axe (1%), Magicbane = athame (0%), Mjollnir, Ogresmasher = war hammer (1.5%), Grimtooth* = orcish dagger (1.2%), Orcrist* = elven broadsword (0.4%), Sting* = elven dagger (1%), Stormbringer* = runesword (0%), Dragonbane = broadsword (0.8%), Trollsbane = morning star (1.2%). (Note that some artifacts are marked as randomly-generatable, but don't because their base items don't generate.) The artifacts that can blast neutrals are shown with asterisks; a random weapon has a 5% chance of being an artifact if possible, so the chance that a random weapon can blast neutrals is (0.05*2/6 + 0.006/2 + 0.004 + 0.01 + 0) * 0.05 = about 0.001683333. Taking into account the 10% chance the item is a weapon, and the average 1/67.5 number of items that generates on the upstairs at all, we can calculate the chance of a blasting artifact at about 1 in 400000.

Finally, this needs to be combined with the 1 in 4 chance that the artifact actually blasts the character (only unintelligent artifacts can be spawned this way, as intelligent artifacts either don't generate randomly or have a base type that doesn't generate randomly), and the approximately 52% chance that the blast does enough damage to kill a starting Tourist, to get a final probability of 1 in 3 million.

I never gain control of the character, so these are kind-of pointless.

Obviously, this is not the most entertaining category for this run, but it's still pretty surprising. (I'm currently working on a "best ending, in-game time" TAS with dwangoAC.) In this category, though, I wouldn't be surprised if the run was completely optimal, due to the narrow definition of what is allowed; to beat it, either a faster route will have to be found (which seems really implausible), a different keystroke sequence to get the same effect (possibly more plausible), or a faster TAS of the boot process (which is obviously irrelevant, but could affect the time; this is the best I can do, although it's plausible that someone else could figure out a faster way to boot DOS).

Encoders, please allow the game to run back to the command prompt before ending the encode, or you'll cut out the entire game. (NetHack's credits are shown in-game by pressing V, rather than coming up at end-of-game, so those can't easily be included.)

DarkKobold: Claimed.

DarkKobold: This is clearly a funny concept, and probably the best April Fools submission of 2011... but it really doesn't follow the rules of the site:

Your movie should begin from the console power-on and end when the last decisive action has been delivered. There are no specific rules for an exact endpoint but it must adhere to the following rules:

Under special consideration we might allow movies that play a single level only or a part of the game only.

While one might say that it plays only part of the game, the run ... doesn't really. It doesn't actually even get a chance to play any of the game! Amusing concept, great execution, but I don't see it fitting with the site. Rejecting for goal choice.