Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
Thanks for writing up such a detailed submission text – even if your prediction that there might be only like 4 people that read the submission notes is correct, I'm one of them (and they answered some questions I had, such as why you talked to Zelda).
I enjoyed the run, too – even realtime runs can do pretty silly things in terms of sequence breaking, but the TAS takes it to a new level.
Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
The .gzm file itself is just a binary file, where:
[...]
The next 12*[number of rng seed] bytes are RNG seeds
So one significant difference here is that in the original game, you would need to spend time to manipulate RNG via providing inputs that manipulated it, whereas the practice ROM has an option to set the RNG to whatever you want, without taking any time, at certain points in a game. As a consequence, times obtained using the practice ROM won't be directly comparable with times obtained using the game itself – we'd expect them to be slightly faster, because a new method of RNG manipulation has been added that wasn't in the original game.
I can see two possibilities here. One possibility is that the RNG seed values were never manually changed, and have the same value as they would "naturally" have just from controller inputs – in that case, they would be acting more like miniature savestates than like part of the input file, and aren't being used to gain an advantage. In such a case, we could imagine an alternative input file format for the practice ROM that doesn't include them (where the emulator instead calculates them based on previous controller input), and the run would end up being timed purely based on the inputs. It probably wouldn't sync with the original game due to the lag being slightly different, but would be very close to "a run of the original game played on an inaccurate emulator" in spirit.
The other possibility is that the RNG seed values are being used to gain an advantage, in which case what we have is essentially equivalent to a romhack that allows the use of an extra controller to specify what the value of the RNG should be (rather than manipulating it with controller inputs on the main controller). That would be expected to be slightly faster than the original game, although the gain would probably be fairly marginal (I don't expect RNG manipulation to take a lot of time).
In both cases, we have a situation where the specified sequence of controller inputs would not be expected to complete the original game, but where a very similar sequence of inputs probably would (requiring resyncing for changes in lag and possibly RNG manipulation). So this is likely to be a good way to visually see what a run with this route would look like – but it's also going to have an inaccurate final time, and determining what the time would be for the same run on the original game would require someone putting in a very large amount of effort to resync.
Perhaps the solution is a disclaimer like "this run was made on an Ocarina of Time practice ROM, which is in most relevant respects very similar to the original game, but the timings are slightly different. The run is completed in 3:07:24.17 on the practice ROM, but we don't know what time it would have taken on the original game".
Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
For what it's worth, I think much of the issue may be that speedrunning communities in general have become much more fragmented than they used to be (and primarily blame the existence of Discord for this).
It used to be that speedrunning communities would often work together on a small number of webforums – I could get a fairly good view of what was going on in speedrunning just by monitoring TASvideos' forum and SDA's forum (and just following TASvideos' IRC channel would get you discussions about a big range of different games). Some large games had their own forums, but even those were publicly accessible.
Nowadays, though, it's common for speedrunning communities to be much smaller and more specific, and that means that people are gaining less visibility of what's going on elsewhere. In my case, I've mostly stopped following speedrunning and TASing in general, partly because it feels futile to try; there are so many places that I might have to look, and many of them are hidden from public view unless you make an active effort to see what's going on. (For example, if a community makes a big discovery, nowdays the "default" is probably to post it on their own Discord, but then there's nowhere that people from outside the community can look to see what happens until someone goes to the trouble of doing a serious writeup that can be hosted on a website or video sharing site – and that puts a big delay in the whole process, making it old news by the time that people outside the community find out.)
So the problem nowadays is that the current structure of speedrunning communities strongly pushes players towards following only one or two games in detail, rather than taking in the breadth of what speedrunning in general has to offer. And a side effect of all that is that it reduces the potential audience for any given TAS, because there's likely to be less crossover interest from people who cared primarily about other games.
Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
The game does apparently explicitly state that the gap without a tile can be anywhere and the solution still counts.
I assume they did that because if the gap has to be in the bottom-right corner, swapping 14 and 15 is (famously) impossible – so a rule change was needed to make the game possible to complete.
Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
Enterim wrote:
3.7.0 development continues but I don't think any more huge changes that would upend general strategy are coming down the pipeline.
I a) spent much of November doing very well in a NetHack 3.6 tournament, in a clan of some of the game's top players, and learned a lot about the game's balance and a lot about the available exploits as part of that process, and b) am now on the NetHack DevTeam and may well end up putting those lessons into practice when rebalancing the game. (I haven't worked much on it recently for much the same reason I haven't worked much on the TAS – I've been having trouble doing much of anything recently.) As such, I think it's definitely premature to make assumptions about what 3.7 general strategy will be like (although admittedly, the sort of change that could have a huge impact on a normal game is unlikely to have much effect on a TAS).
Generally speaking, we've been reluctant to use versions after 3.4.3 for TASing because those were informed by the development of the TAS itself (with the exploits the TAS uses being known by the DevTeam, and fixed for, typically, 3.6.0). That partly means that a lot of interesting glitches have gone (e.g. the branchport-based ascension run skip was discovered during the making of the TAS, and patched out before I joined the devteam, probably because it's too easy to pull off in a tournament game), and partly means that it wouldn't be a "pure" TAS because the game had been changed in reaction to the TAS development.
Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
There's a somewhat large genre of "inherently uncapped games" which (assuming lag isn't a problem) can process commands as fast as the player can enter them, because there's no timing dependency in the game logic itself.
In such cases, I think it doesn't really make sense to use time as a method for determining how optimised a TAS is – the time of a run is something that the game doesn't care about and doesn't affect the gameplay. (For a non-TAS run, it would measure a skill – the skill of entering input quickly and precisely. But in a TAS we assume that that skill is already at ideal/super-human values, so it isn't a meaningful thing for TASes to compete on.) With this sort of game under TAS conditions, you'll always be able to get a faster time by running on a faster computer and connecting it to a faster keyboard, so optimisations that make the run go faster in realtime don't really make sense. Instead, the goal should be to minimize something else – maybe fewest lines of input, or fewest keystrokes, might make sense.
(For example, in the NetHack TAS that dwangoAC and I've been working on, the main optimisation goal is in-game turncount, because realtime is mostly a factor of how fast the computer runs and how fast the keyboard runs; the game is designed to let you think as long as you like about each move and has no time limits, which also means that it lets you think as short as you like, too. To nonetheless come up with some meaningful realtime measurement, we have a rule to not send input any faster than a typical physical keyboard of the time would be able to send it, which is often a tighter limiting factor than lag is – but that basically only affects tiebreakers. We may in fact slow some of the input down for the final submission to make it more viewable, and if we don't, would at least slow down the encode.)
Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
Is there a reason (luck manipulation? avoiding the "is this what you were expecting" cutscene?) to uncover the "1" tiles when playing Voltorb Flip? If I remember correctly, the victory condition is to uncover all the 2s and 3s.
Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
I don't think that it's possible to make this game entertaining to watch in a TAS (although, of course, that doesn't necessarily mean the run shouldn't be accepted). There were some funny moments, but overall the game is very repetitive.
Also, does this actually complete the game? It doesn't seem to reach actual credits, only a fake credits roll. (Although I've played this game, I forget how completing it actually works – there are a large number of game modes and it isn't clear which are relevant.)
I'm assuming that the reason that most of the microgames were played on easy is that you have to do the difficulties in order? (There are three difficulty levels for most microgames, but I can't remember exactly how you select them.) Admittedly, seeing them played on the hardest difficulty probably wouldn't change much about the run.
Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
I remember, several years ago, thinking that this would be a good category for a TAS. With this run, you've demonstrated quite convincingly that it is. (I love the way that out-of-bounds somehow manages to end up faster despite everything – the "takes no damage" isn't a self-imposed/categorised restriction, but rather "complete every level without taking damage" is part of the game's 100% definition, so you can take damage if you happen to replay a level for some reason, and there is actually a reason.)
Even further back, close to when Kuru Kuru Kururin first came out, I wrote a sort of clone of it as one of my first big for-fun programming projects (except with a much lower physics resolution and ASCII art graphics, and a few somewhat significant gameplay changes). Shortly after that, I wrote a feature for playing back recordings, and a bot to brute-force the levels of my clone and work out the shortest paths. I guess that's technically the first TAS I ever made, back before I had ever heard of TASing or TASvideos (and didn't realise it was a TAS until much later). So for this site, Super Mario Bros. 3 TASes are what take it back to its roots – but for me, it's Kuru Kuru Kururin. I'm therefore very happy to see it TASed to such a high standard.
In case it helps the judges for anything where community feedback is relevant: I prefer this run to the out-of-bounds run. I like the out-of-bounds run too, but this one is even better. The forced waiting periods don't slow things down all that much, and in a way they improve the run: the run is technically impressive due to the lengths it manages to go to to avoid, skip or shorten them, and the fact that some of them are unskippable makes it easier for the viewer to appreciate the optimization in the rest of the run.
Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
I guess my point of view is that a cartridge containing a PvP-only game is an "incomplete game", as one player can't play it by themself. It becomes an actual game upon adding an opponent to it. (This is similar to the way that some games consist of an engine plus level files – you can't play the engine on its own, you need to find a level file in order to create a complete game.)
In practice, attempts to play a PvP game solo normally work by defining some standard behaviour for the opponent. For example, I've seen examples where such games were analysed as "how quickly can I win against an opponent who does nothing?". Allowing arbitrary opponent behaviour could be interesting in some situations, but generally isn't (especially because most games have an option to concede).
Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
After overwriting the lock-on status memory address, which save file is the game saving to? In particular, could you reset somewhere during the Sonic & Knuckles half of the game, reload the file, and a) continue from the same point in the game and b) have the game think you are completing Sonic 3 & Knuckles? Or would the file fail to load for some reason?
This is a really interesting category as far as legitimacy debates go: I think one possible comparison is a "glitched newgame+" that plays Sonic & Knuckles via copying over data from a Sonic 3 & Knuckles save file via a glitch (which probably wouldn't be considered a Sonic 3 & Knuckles completion), but that's not the only way to interpret what's going on here. I guess another potential way to look at it is that the "continuous playthrough" posted two posts above is a playthrough that uses a glitch to start a Sonic & Knuckles game in a Sonic 3 level!
We've had various discussion of "completing the wrong game" in the past (although I can't easily find it at the moment), but don't think we came to any clear conclusions. (EDIT: I found it, although it probably isn't applicable here: Post #486426)
Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
A question about the category: do you actually have the stones/medallion you collected prior to BIT upon collecting the game? Or is the requirement just "collect the item for completing each dungeon at least once, even if you lose it later"? This is something that might need to be clarified in the description of the category (and which hasn't really come up before because the game isn't intended to have you lose stones and medallions after collecting them, and there isn't normally a reason to remove them).
Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
The game's limited only by a) lag and b) reading input from the keyboard. Lag does have some effect, but the speed at which input can be read is often the limiting factor, especially during luck manipulation (because the luck manipulation techniques are designed to minimize the amount of lag produced). There are very few moments where the game intentionally waits for the next frame, or performs a timed delay (and timed delays can be disabled in the options). So in most cases, you can play the game as fast as you can press the buttons.
Although I'm not 100% sure, I think that input on DOS uses a maskable interrupt rather than polling, i.e. it actually interrupts the processor in much the same way that, say, vblank would on a NES. That means that if you press a key, it's handled as soon as the keyboard manages to communicate that fact to the processor – there's no "poll once a frame" or equivalent. The limiting factor on luck manipulation speed is therefore the rate at which the keyboard is able to send the "a key was pressed" message.
Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
For what it's worth, part of the reason I care about the label given to the run is that I consider the reset-during-save technique to be somewhat illegitimate, in the sense that it's going outside the bounds of what the game can reasonably be expected to handle. In a way, doing a reset during a save is going beyond the realm of controller input, whereas normally for a TAS the whole selling point is "this can be achieved using only controller input!".
Meanwhile, this run is not falling into the same grey area in terms of legitimacy: not only does it not reset during a save, it doesn't reset at all (the save is reloaded using a death, something which should be noted in the movie tags). As such, if someone is intentionally avoiding runs with reset-during-save glitches, they might nonetheless want to see this run. However, there's very little clue in the tags or category at present that that is the case (the tags are missing "Uses a game restart sequence", but that's hard to notice).
Also, if I remember correctly what other people have said about this glitch, aren't the edits made to the save data via the memory corruption not persistent enough to survive a console reset (which is why a death has to be used)? If the edits to the save data aren't actually saved, then in a sense you haven't corrupted the save data after all.
Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
It works differently from most save corruption glitches – normally save corruption glitches are done by turning off the console mid-save so that the save data isn't written properly, but this glitch instead overwrites the memory holding the save file directly. The effect is much the same, though (it's used to produce a save file in a state immediately before the game is beaten, which is then loaded, and the game beaten from there).
I guess the philosophical problem here is "in a 'save glitch' branch, is the determining factor that the glitch changes the save file or that it exploits the process of saving?" This glitch doesn't do anything glitchy with respect to the process of saving (and the save produces a normal save file), but then uses a (somewhat constrained) memory corruption glitch in order to edit the save file (because we don't know how to use the glitch to win the game directly, and doing so may well not even be possible), and loads the edited save file as a means of warping to the end of the game. I don't think I've seen a glitch quite like this one used in any other game in the past (for most games which are capable of doing something like this, there's a much easier/simpler way to win the game directly and thus the roundabout method via using memory corruption targeting a save file isn't necessary and isn't even considered). As such, the question of how to categorise it hadn't really arisen prior to this run being submitte.
Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
Some progress: I've confirmed that monster hypercharging is a real glitch (and have documented it at Wiki: GameResources/DOS/Nethack#MonsterHypercharging). The setup that I used for the tests was to be in the a corner of a room, with a hole next to me, and water on all the other adjacent squares and below me: a dragon is flying over the water, with my character in homunculus polyform (which is speed 12, able to fly, and bad defensively). Waiting the turn would cause the dragon to attack the character, rehumanising it from HP damage and causing it to climb out onto the square with the hole, immediately falling through to a lower level. The monsters on the level that I fell onto would gain a turn's worth of actions, and if I immediately level-teleported out and repeated the process, the monsters would gain another turn's worth of actions, and so on. (I also confirmed that, if I waited on the new level rather than level-teleporting out immediately, the monsters would immediately take all their stored actions.)
Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
I just thought of a simple way to make the events on the quest goal level much easier to manipulate, without costing any time: use two quantum mechanics. The events on the second monster action of turn 2000 would be "Archon ORKOs the Dark One, quantum mechanic teleports us onto the Dark One's corpse and we autopickup the Bell, quantum mechanic teleports us next to a level teleport trap, steed throws us off into the trap". For both teleports, we have access to teleport control, so the only events that need manipulating are a) the Archon landing next to the Dark One, b) there being a level teleport trap somewhere on the level, c) the steed throwing us off in the right direction, d) arriving on the correct square after the teleport. There is some scope to use monster actions in between these in order to help to manipulate the results. The worst of these to manipulate will be d), which may be solvable via the "fire the arrow at the tree, then paint the target around it" principle (i.e. we first find a seed that works and check to see where we would end up, and then do a setup on the Quest home level that works starting from that specific square) – I estimate that the odds of there being a setup for the Quest home level that works from some specific random square are around 1 in 4, although lining up the RNG for that could be difficult because lots of random numbers will be consumed during the setup itself.
Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
I was working on something like this several years ago (primarily for native Linux programs, although running Wine in it was an obvious "further work").
There are three main problems:
Sandboxing the environment so that it doesn't interact with processes and files outside the sandbox. I was using containers + xvfb for this, just like you were (although I was using namespaces directly, rather than going via Docker). There are plenty of alternatives nowadays, such as bubblewrap and AppArmor, although I haven't experimented with these myself.
Savestate / reload. There are programs like CRIU and rr that are good starting points for this. I didn't personally get anything like that working; IIRC dwangoAC has some experience with getting CRIU to work.
Determinism / sync-stability. This is the really hard part, which I invested most of my time into, and eventually gave up. There are a huge number of things that can potentially affect the behaviour of a running program and cause it to act differently given the same input, and to make a stable TASing platform, you need to ensure that all of them work deterministically – otherwise, attempts to replay an input file from the start will fail to sync and there will be no way to verify runs.
I believe that all three problems are solvable, but the third will require the most effort. There are non-deterministic system calls that are very commonly used, like gettimeofday, and your execution environment needs to ensure that they give consistent values in every run of the program; that means that it needs to keep track of "emulated time" in a way that's consistent and that doesn't cause the program to malfunction. There are blocking system calls for which the effect of the program will change if they are run out of order (including thread synchronization calls like futex, and pretty much everything that does I/O); you need to create rules to make sure they will run in a consistent sequence. That in turn generally means that you need to ensure that only one thread is running at any given time (across all processes, e.g. you don't want the game and xvfb to run simultaneously because otherwise you might have non-determinism based on which of them gets to a system call first). There's no reason in theory that that shouldn't be possible, but it is hard to get that sort of code right, and very easy to accidentally introduce deadlocks. There are processor instructions that have nondeterministic behaviour, like RDTSC and RDRAND; there are ways to get around this but it requires extra levels of emulation. (And of course, you need to replace system calls that allow a process to ask for non-deterministic behaviour explicitly, such as attempts to read /dev/random.)
Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
Isn't this a hardlock, rather than a softlock? Softlocks require the game to be running enough of the main game loop that they're reacting to user input to at least some extent (the classic example used to be something along the lines of being stuck in a wall, allowing you to pause the game but not to move), whereas this seems to be an infinite loop that bypasses any player control of the game at all (if the name screen were reacting to the player's keypresses, that would presumably escape the loop.
Of course, that doesn't really negate any of the interest in the run – you just have to change the category name.
Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
slamo wrote:
So I'm realizing this is a weird case, and I'd like some opinions, because the rules are a little unclear on this.
Wondermail in a Pokémon Mystery Dungeon game is very similar to a newgame+ in games with permanent upgrades – it effectively makes it possible to get late-game items very near the start of the game, and play through the game with some of the character's statistics in a late-game state (whilst others are stuck in their early-game state). As such, we should probably be judging it by similar standards.
One notable difference is that we don't have a verification file for the Wondermail passwords used here, and it's likely that none exists; the "ideal" sort of Wondermail for use in runs has late-game rewards given from missions in very easy dungeons, and (although I might be mistaken) I don't think the game is capable of generating those naturally. So this run is more comparable to a newgame+ on a crafted save file. Previously, we wouldn't have allowed that sort of thing, but the rules have changed and this looks like a good fit for the new rules.
Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
Isn't the obvious thing to do here to time by when the game is beaten, rather than timing by last input? (As other people have mentioned, if you time by last input, the optimal thing to do is to simply not give any. But the autoplay is slower than playing it yourself, and we should pick a timing method that takes that into account.)
Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
HappyLee wrote:
Awesome TAS, just from a technical standpoint. Few people would expect to see game end in 0.32 seconds.
Sorry that I don't know much about the technical details, but are there lots of NES games can be done this way just like SMB3? What about SMB1? Thanks.
This sort of run exploits a bug in the game's controller read routines. Different games use different read routines – some of them are exploitable, some of them aren't. SMB1's controller read routine is very simple and doesn't have this sort of bug in. (The reason games might want to use a more complex read routine is to work around a bug in the NES in which the DPCM unit occasionally causes incorrect data to be read from the controller, but if I remember correctly, SMB1 doesn't use the DPCM unit and thus it has no need to try to "fix" the controller data – it'll always be read correctly first time. The DPCM unit has no effect on this glitch itself; the DPCM glitch is the reason games use complex and potentially buggy controller read routines, but not the cause of the bug exploited here. That bug being exploited here is a different bug which was accidentally introduced by the SMB3 programmers while trying to fix the DPCM bug, as opposed to being the DPCM bug itself.)
Even when the controller read routines are buggy, the bug doesn't necessarily do anything useful. With SMB3, we're kind-of lucky that the effect of the bug is to start running zero page (which contains some important registers like the controller registers) as a program, but other games might just crash, and it isn't always possible to manipulate the crash.
Editor, Experienced Forum User, Published Author, Player
(45)
Joined: 7/11/2010
Posts: 1036
I also think a no-SRAM run might be more interesting. There'd be more downtime, but being able to start with (nearly) all the moves removes one of the main aspects of the game (i.e. buying the moves and becoming more powerful over time). However, if you go that far, you'd probably want to also ban Troff 'n' Scoff skip (i.e. "no bosses early" in addition to "no levels early") so that everything that was meant to cost collectibles would actually cost them.
I also think that any run that relies on things unlocked on a previous playthrough should be marked as newgame+ (or "glitched newgame+" if the previous playthrough isn't meant to matter but has been made to matter, as here).
Nonetheless, I still enjoyed this version of the run for what it is, even if the category is a bit arbitrary.