Posts for ais523


Editor, Experienced Forum User, Published Author, Player (44)
Joined: 7/11/2010
Posts: 1022
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 (44)
Joined: 7/11/2010
Posts: 1022
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 (44)
Joined: 7/11/2010
Posts: 1022
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 (44)
Joined: 7/11/2010
Posts: 1022
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 (44)
Joined: 7/11/2010
Posts: 1022
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:
  1. 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.
  2. 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.
  3. 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 (44)
Joined: 7/11/2010
Posts: 1022
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 (44)
Joined: 7/11/2010
Posts: 1022
Perhaps "all unique levels" would work as a branch name? It makes it clear what isn't included, and why.
Editor, Experienced Forum User, Published Author, Player (44)
Joined: 7/11/2010
Posts: 1022
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 (44)
Joined: 7/11/2010
Posts: 1022
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 (44)
Joined: 7/11/2010
Posts: 1022
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 (44)
Joined: 7/11/2010
Posts: 1022
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.
Editor, Experienced Forum User, Published Author, Player (44)
Joined: 7/11/2010
Posts: 1022
The best way to think about this is that it's a 2 games 1 controller run. One of the games is Mega Man X6. The other is a hack of Mega Man X6 in which you start as Zero.
Editor, Experienced Forum User, Published Author, Player (44)
Joined: 7/11/2010
Posts: 1022
and the Game Corner ID is set to 59, which by luck happens to have prize data in underflowed inventory and price data in SRAM.
Huh, this makes me think that there's another category of "arbitrary X exploit" beyond code execution, ROM execution and memory corruption (and script execution, for the people who count that). What's going on here is incredibly similar to ACE, but using a data pointer rather than a code pointer in order to make the game's routines pull data from an area under user control. I'm not sure if this category of exploit has a name yet, but it could probably do with one, because it seems like a pretty major category of exploits.
Editor, Experienced Forum User, Published Author, Player (44)
Joined: 7/11/2010
Posts: 1022
Let's see, there's a continuum as far as memory corruption is concerned. Being able to corrupt all but 1 address is effectively arbitrary memory corruption (most glitches can't corrupt quite every address, e.g. because you need one to hold the cursor). Being able to corrupt only 1 address isn't arbitrary at all, it's just a specific-purpose glitch. So a cut-off has to be drawn somewhere between arbitrary memory corruption and "regular" memory corruption. If we're talking about Vault requirements for 100%, one of the only objective places to draw the line, as far as I can tell, is "can this corrupt the memory that stores the information about whether the 100% requirements are met?". In this case, party overflow could, so we shouldn't allow it. (The only other place I could see to draw the line is "is there any way at all to affect/control which address this glitch corrupts, even within a narrow range?", but that's much more restrictive.) I think the bigger conceptual problem is "how do you define what a single glitch is?". The "classic" version of trainer-escape, for example, generally has well defined behaviour for what it does (forcing an encounter based on a value left in memory from a previous battle), and probably isn't really classifiable as a memory corruption glitch at all (I'd put it in the "storage" group of glitches); the main complication is that some memory in Pokémon is used for two different purposes, and we're corrupting it from one possible point of view but not the other. With trainer-escape into ACE, the execution is a bit different (you need to manipulate stored values in other ways between the escape and the re-entry, e.g. by reading signs, rather than simply just starting a trainer battle at range). So are these the same glitch or not? With storage glitches, the order in which you do things can be critically important, so I could understand a classification of "trainer-escape → fight trainer → re-enter" as being treated separately from "trainer-escape → fight trainer → read sign → re-enter". I think there's a big conceptual difference, though, between "let's do this glitch, but add extra steps so that it gets a different effect", and "let's do this glitch, but move the cursor to a different location so that we're affecting a different part of memory".
Editor, Experienced Forum User, Published Author, Player (44)
Joined: 7/11/2010
Posts: 1022
I agree that this run does not use arbitrary code execution or arbitrary ROM execution. However, I dispute that it isn't using arbitrary memory corruption. The Game Boy + cartridge combination has multiple different types of memory. This run uses a glitch (item underflow into party overflow) to gain control of one of those types of memory (the WRAM), and is able to corrupt it at will; it's definitely using an arbitrary WRAM corruption glitch. Now, this glitch isn't capable (without extending it into ACE/ARE) of corrupting other areas of memory, such as the SRAM, which is why I think the author isn't considering it to be an arbitrary memory corruption glitch. But the WRAM is a large and important area of memory that stores almost (but not quite) everything that affects gameplay, so an arbitrary WRAM corruption glitch is very similar in spirit to a more general arbitrary memory corruption glitch. We don't call a glitch "not arbitrary memory corruption" just because it isn't capable of altering the ROM (which is after all a type of memory). I think this is a similar situation: being unable to change the SRAM, VRAM, etc. doesn't change the fact that the one glitch is capable of affecting almost anything in the game's memory that actually matters. (The glitch could be used to set Pokédex flags directly, for example; the author explicitly refuses to use it to do so, in order to meet a 100% definition, but it would have been powerful enough to do so if necessary, and it's used to do a lot of other things in the game. SDA used to have a rule along the lines that "if a glitch you use is capable of doing X, you can't use it in a no-X category, even if you actually use it to do something other than X", and I think this is a similar case.)
Editor, Experienced Forum User, Published Author, Player (44)
Joined: 7/11/2010
Posts: 1022
This is a bit of an unusual movie, because it's basically a solution to a puzzle, and in order to be entertained while watching it, you have to be thinking about the puzzle yourself. Take the first jump, for example. It's required to jump over the goomba in order to progress, but the run manages to hit a ? block and release a mushroom in the process. So the required jump is being used for two different purposes. It hardly looks any different to the any% (the number of jumps is the same), but it is in a slightly different place and there's a reason for that. As a consequence, I found that part of the run entertaining to watch because it was interesting to realise what the reason was. I think the site probably should be moving away from "visual entertainment" or "entertainment level of the encode, in the abstract" for determining which runs are publishable. Even when the encode isn't entertaining in of itself, understanding the goal that a run is aiming for, and the route that it's using to do that, can be worth it. One thing that gives me pause: how much advantage does this run get from being a TAS? (In particular, are there any tricks that are unlikely to be replicated by a skilled person at the controls?) This is an impressive technical achievement, but it would be more impressive if it were done without slowdown and savestates, and time is after all only a secondary goal. We expect runs to stand out from unassisted play, and because few (no?) unassisted players have attempted runs with this route, it isn't immediately clear to me what the advantages of TASing in this context are. (It's quite possible that this whole thing is entirely TAS-only, especially in regards to RNG manipulation; but I don't have enough information to tell, and that impacts my enjoyment a bit.)
Editor, Experienced Forum User, Published Author, Player (44)
Joined: 7/11/2010
Posts: 1022
From my point of view, finding an optimal plan is actually not what the TAS has been stuck on for a while. I definitely wanted to hit the 2003 turn mark (which seems to be possible with room to spare at this point), but 2002 is probably too much. The basic reason behind this is that some strategies, while it's great to know that they're possible, simply aren't going to be any fun to TAS or any fun to watch. For example, say you hypercharge an engulfing monster and get it to carry you across Air, randomly stumbling into the portal. The minimum possible travel distance for that is 33 squares, and hypercharged monster movement is effectively a random walk; and the average time a walk that randomizes between left and right takes to reach any particular square is proportional to the square of the distance. 33² is 1089. Take into account the possibility of moving up or down (this happens ¼ of the time), and we're going to need an average of around 1452 hypercharges to reach the horizontal position a minimum-distance portal (somewhat more to stumble into the correct vertical position, too, but that's minor by comparison). Luck manipulation can bring this number down a bit, but the more you try to save on hypercharges, the more luck you need, and there are limits to how much it's reasonably possible to luck-manipulate. Now, let's consider that hypercharging a monster requires spending turn boundaries; this isn't something you can increase the speed of by using a faster polyform. Let's say we get insanely lucky and find an RNG state that crosses Air in just 1000 hypercharges (there may not be one of these in NetHack's seed space, or it may require many decades of wallwalking, etc.). The fastest we can hypercharge a monster is 4 hypercharges per turn boundary, so the final run will involve 250 turns – ⅛ of the run – spent just repeating the same glitch over and over again. There might be a way to make that interesting to watch by doing other things in between the hypercharges using spare actions, but there are limits, and it would be incredibly tedious to TAS regardless. And this is just one glitch! My basic problem with the 2002-turn plans is that they require strategies with this level of tedium all over the place. Shaving off actions is great, but at some point the cost of entertainment – and the cost to the TASers' sanity – is going to make the time saving not worth it, at least if you want any chance of the run to be finished. At this point, I think 2002 turns is something that isn't desirable to aim for unless some new glitches are discovered that make such a run actually tolerable. (2003-turn strategies were in this area for a while, but have since been improved, which is what started to bring the 2002-turn strategies within range.) Instead, I think that what would lead to the best and most entertaining run would be to hit 2003 with a lot of strategy variety. I think it'd be both more fun to watch, and more fun to TAS, if we can come up with an endgame strategy which isn't just enexto'ing over and over and over again. There are lots of potential strategies we've discovered, like overflow hurtles and zero-timed descension runs, and I think that using those to help hit 2003 would make a better run even if they aren't quite necessary. Anyway, the reason I'm writing this is partly because I forgot to write it earlier, but partly because I think people are assuming that I'm waiting for a 2002-turn plan before resuming the run. That's not the case – I'm happy to run on a 2003-turn plan. However, I've had various problems in my personal life, and TASing hasn't been a huge priority for me as a consequence (and a lot can change in terms of personal circumstances in 11 years); I've had to put a lot of hobbies on hold, and TASing is one of them. That's not to say I've abandoned the TAS; it's more like I've put it on hold until I can have the opportunity to work on it again. (I think dwangoAC has also been busy with other things, quite understandably! So there hasn't been much progress in terms of actually grinding out rerecords.)
Editor, Experienced Forum User, Published Author, Player (44)
Joined: 7/11/2010
Posts: 1022
To explain my Meh vote: I enjoyed seeing the strategies and routing that was used, but the actual execution was a little repetitive: there's only so many ways you can damage boost through a level before it starts to get stale, and that's the majority of the run. So although I watched to the end, it didn't really capture my imagination the whole time; in many parts, I felt like I wasn't really seeing much new.
Editor, Experienced Forum User, Published Author, Player (44)
Joined: 7/11/2010
Posts: 1022
Warp wrote:
Given that, as far as I know, it's impossible to create a TAS without an emulator, I find the scenario quite unlikely that there would be a console-only TAS with no emulator version.
There have been a few TASes created without the use of emulators. All you technically need is a sufficiently deterministic environment for running the game, and some way to replay inputs. (Having savestates available speeds the creation of the TAS up a lot, because you then don't need to replay it from the start whenever you change anything, but isn't a technical requirement.) Input playback, determinism, and savestates are a combination that is mostly only found in emulators, but you can imagine other platforms which have that combination and such platforms are usable for TASing. I think many of the non-emulator TASes were created via taking a game that's fairly deterministic as it is, and modifying the game to patch in savestates and the ability to play back input. (We also have several published non-emulator TASes: neither libTAS nor Hourglass is an emulator.)
Editor, Experienced Forum User, Published Author, Player (44)
Joined: 7/11/2010
Posts: 1022
At least some Nintendo games for the Game Boy have "delete save" functions that are intended to be used by an end user in some circumstances, and if I remember correctly, they work by overwriting the save RAM entirely with FFs. I think that's evidence that all-FFs is "intended" to be the/a blank state of the save file on Game Boy cartridges, and at least makes it reasonable to use on an emulator. It would be hard to figure out what the save RAM is on a factory-fresh Game Boy cartridge nowadays; there are few that have never been played, and on platforms where the save RAM makes use of a battery, the batteries would be dead by now.
Editor, Experienced Forum User, Published Author, Player (44)
Joined: 7/11/2010
Posts: 1022
I think a good definition would be "a timesave that's unexpectedly large, given the history of the game so far". In the case of Super Mario Bros., a 1-frame improvement is unexpectedly large because any improvement at all (to what may well be our most optimised TAS) is unexpected.
Editor, Experienced Forum User, Published Author, Player (44)
Joined: 7/11/2010
Posts: 1022
Avoiding screwing yourself out of a true 100% is very difficult (there are a lot of minor things you can do wrong that will cause you to lock yourself out of getting particular items and/or the abilities they teach, or certain Monster Bank entries). A few years ago I was working on a guide to this, but never finished it. If all you care about is a 300-mission completion, though (which is all that the speedruns care about), it's much easier to avoid a mistake. All you need to do for that is to avoid discarding important mission items; the basic issue is that there isn't much of a clue in the game as to which are important, and the capacity is somewhat limited, making it very easy to discard an important item by mistake. In case it helps, here's a guide to what can safely be discarded: Can be safely discarded, and will be easily reobtained lategame if you discard it: - Fire Sigil, Water Sigil, Wind Sigil, Earth Sigil - Magic Trophy, Fight Trophy (note: do not discard Sport Trophy) - Zodiac Ore, Mithril/Silvril (depending on translation), Materite, Leestone, Adamantite - Jerky, Gyshal Greens, Telaq Flower - Helje Key, Ancient Medal, Magic Cotton, Panther Hide, Encyclopedia, Rabbit's Tail Can be safely discarded, but will be more difficult to replace if you do: - Badge (note: this must be "Badge" alone, do not discard other items with "Badge" in their name) - Mind Ceffyl, Body Ceffyl, Spiritstone - Magic Cloth, Cyril Ice, Magic Vellum Discarding any other mission item will lock you out of a full complement of that item permanently, and this has a high chance of permanently locking out some mission or other as a consequence. As far as I know, there's no intended way to lock yourself out of any mission unless you discard mission items. (There are online rumours that there's a glitch that permanently locks out "Free Bervenia!", but they differ in the details of what triggers the glitch, and as far as I know there's no confirmation that it actually exists. If you want to make sure, purchase and complete the mission as soon as it becomes available, making sure that you do not lose the resulting battle; this avoids every rumoured trigger for the glitch. There are comparable rumours related to "Left Behind"; the recommended way to avoid any issue here is to save before accepting it, to make sure that it's the only mission in the mission list when accepting it, and to complete its entire plotline before saving again. The plotline ends when you recruit a special character.) There is also a mission called "Memories", which you're unlikely to come across at all (it's hard to get it to come up if you don't know what you're doing). This isn't a real mission, but rather unsets the "game complete" flag upon being accepted. If you do see it, I recommend not saving while the mission is accepted (if you accept it and then re-complete the game, the game simply just resets to your previous save file). Also note that the "reserve missions" are intended to only be completable with the help of multiplayer. There is a 1 in 4 chance for any given save file that the reserve missions can be completed without trading; otherwise, you'll be stuck with some uncompleted missions as a consequence. These do not count as part of the 300-mission total, so won't lock you out of an all-missions completion.
Editor, Experienced Forum User, Published Author, Player (44)
Joined: 7/11/2010
Posts: 1022
Just to explain my Meh vote: I think having all (or almost all) the relevant abilities from the start sucks a lot of fun out of watching this genre of game, regardless of how they're obtained. So I found this less interesting than a typical SotN run.
Editor, Experienced Forum User, Published Author, Player (44)
Joined: 7/11/2010
Posts: 1022
One interesting point: the realtime speedrunning community considers this a legitimate completion of the game, but what it's actually doing is warping to a point in the middle of the credits. Is there a flag or some other way of recording game completion that exists within the game? If so, does the run set it? I think this TAS would be worth accepting anyway, but it may need a category designed explicitly to make it clear what goal it's going for, something like "credits warp".
Editor, Experienced Forum User, Published Author, Player (44)
Joined: 7/11/2010
Posts: 1022
Memory wrote:
Does Microsoft Word count as a game if you could find ACE in it?
Not sure about ACE, but there are legitimately a number of games within past versions of Microsoft Word (and certain other Microsoft Office products). Some were demonstrations to show off the macro language, whereas others were hidden Easter Eggs. I can easily imagine someone making a TAS of one of those if Windows TASing becomes more advanced (although, IIRC, many of them didn't have victory conditions).