Editor, Experienced Forum User, Published Author, Player
(44)
Joined: 7/11/2010
Posts: 1029
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
(44)
Joined: 7/11/2010
Posts: 1029
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
(44)
Joined: 7/11/2010
Posts: 1029
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
(44)
Joined: 7/11/2010
Posts: 1029
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
(44)
Joined: 7/11/2010
Posts: 1029
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
(44)
Joined: 7/11/2010
Posts: 1029
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
(44)
Joined: 7/11/2010
Posts: 1029
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
(44)
Joined: 7/11/2010
Posts: 1029
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: 1029
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: 1029
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: 1029
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: 1029
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
(44)
Joined: 7/11/2010
Posts: 1029
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: 1029
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: 1029
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: 1029
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: 1029
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: 1029
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: 1029
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: 1029
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: 1029
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: 1029
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: 1029
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: 1029
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.