I happened to run across this game in a different context and decided to watch the encode of the TAS. Unfortunately it suffers from very bad sound desync. If an encoder has free time and wanted to make a fixed encode (or just stretch the audio to match the video in the existing encode), that'd be appreciated.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
There seems to be little point in a pause-glitch run. It doesn't completely break the game, since all the levels still have to be played; it just removes all interest from the playing. It'd be like if, say, a glitch were found in Donkey Kong Country that enabled noclip so you could just walk straight to the exit in every level. Sure it'd be faster than the unglitched run, but it wouldn't really be interesting aside from the fact of the glitch itself.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Neat idea, and I'm impressed by the Lava Reef Zone / Sky Sanctuary Zone playthrough. I do have to suspect that there's some obstacle earlier in the game that would prevent a full playthrough under these rules though. If nothing else, Carnival Night Zone's barrels would be tricky, and I don't think you can clip through terrain to avoid them without the D-pad.
Still, what you did is pretty dang cool!
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
There's nothing wrong with Mario Kart 64 GP as going through the 4 cups, one after another each ending with a reset. I can maybe see the argument that the Time Trials can be done similar to this, however the Super Mario 64 120 Stars invalidates all theories that racing games are too hard to ever take on and shouldn't all be done in one go. If numerous TASers can spend millions of rerecords over 5 years for a TAS of over an hour, there's no reason that a similar effort can't be made for other 3D games of high optimization standards.
The existence of an exceptional TAS for one of the most popular video games ever does not mean that similar levels of dedication and time should be expected for every other game under the sun. F-Zero X is a reasonably popular game; certainly among the top N64 games. But unlike SM64, it doesn't have anywhere near the kind of enduring popularity needed to get tens or hundreds of thousands of man-hours dedicated to figuring out optimal strategies and then compiling them into a single "full-game" run.
Regarding using GP mode instead of Time Attack mode, two things:
1) The other cars would be functionally irrelevant for the vast majority of each course. CPU cars stick to the middle of the track as a general rule, while the player will of course be hugging the edges, so unless a CPU car happens to be in the way right when the player wants to cross from one edge to the other, they won't have any impact.
2) Being unable to select your car for each course would mean that the run times wouldn't really be comparable to those achieved by the speedrunning (racing?) community for this game. It'd also mean that most courses wouldn't be optimal, in the sense that they could be done faster if a different car were used -- that would irritate a lot of people, I imagine.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
A bunch of Christmas gifts I made this year:
I don't know that these all qualify as art necessarily but I'm pretty proud of them anyway. Though the joinery work on the serving tray is pretty crude.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Personally (speaking as an outsider to this particular game's speedrunning community) I think that a 100% TAS shouldn't bother to actually spend all the coins. Spending coins is not interesting.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Nice work! Perhaps a bit of a shame the bossfights end so quickly, but I can hardly argue with the speed with which the game is played. And it's actually played "properly" unlike the runs that use out-of-bounds/suspend glitches.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Considering that such a post is made on practically every new submission, such posts just basically end up as noise. And since plenty of requests are made, but I hardly ever see an encoder get thanked for making an encode, I tend to think of such requests as being more whiny and needy than anything else, even if that's not the intent of the poster.
Our encoders are providing a fantastic public service and don't get very much credit for it. They'll get to a submission when they can, and asking for an encode is not really going to speed that process up any. Personally I think it's more polite to give them space than it is to make requests.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I have no comment except for if there ever happens to be like 50 categories for SM or any other game, I wish TASer's good luck optimizing every one of them. :P
Ironically, Super Metroid is so well-understood that the standards for an "optimal" run are waaaaay tighter than they are for most games.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
For example, we can be reasonably confident that the creators of the game did not expect players to turbo-fire the aiming buttons to move faster -- but at the same time, there must be some reason why the aiming buttons move you. Surely the default would be for aiming to do nothing to your position?
I'm 95% sure it's just a simple oversight by the designers, but only someone like Kejardon would know for sure.
The game stores Samus's position in memory. That value is, as I understand it, incremented / decremented when you aim while running. It requires specific action by the game to make that modification, so someone thought it was needed.
I do think that the devs probably didn't consider the implications of someone turboing the aim buttons to "run faster", but we can't call every unintended consequence of the code-as-written a "glitch". Most of the time such things are just emergent behavior.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Yeah, the glitches that are avoided in this run are the ones that "completely" break the game -- mostly related to the X-Ray Climb glitch used in the "glitched any%" run.
The difficulty with a true glitchless run is in pinning down exactly what qualifies as a glitch. Especially since the entire game is crafted with sequence breaking in mind, which means that it is very hard to get yourself truly stuck -- thus, it's hard to abuse a specific glitch in a way that clearly says "this was not intended".
For example, we can be reasonably confident that the creators of the game did not expect players to turbo-fire the aiming buttons to move faster -- but at the same time, there must be some reason why the aiming buttons move you. Surely the default would be for aiming to do nothing to your position?
Is it intended that you not lose speed if you hit the ground while going through the morphing animation? That trick (the mockball / speedball trick) can be used to retain speed while in morphball form, which isn't normally possible and allows some sequence breaks. But it's handled very cleanly -- you're making a softer landing! My guess here is that they coded the morphing animation to ensure that you don't bounce when you land during it (since that would look weird) and the retaining of horizontal velocity was a side-effect that they didn't really care about one way or the other.
Breaking through platforms the wrong way, using morphball to phase through kagos (stationary hive enemies), and using the Crystal Flash to get embedded in terrain are all pretty clearly glitches of some kind...but still, you're basically saying "I want someone to break this game wide open, but not in that way."
Warp: note that the armpumping that allows for faster running also allows the player to skip past some barriers that normally require speedbooster -- thus, the faster movement is not completely without consequence. In particular, you can get early super missiles through that technique. However, the mockball also allows a similar effect (and is how unassisted speedrunners usually perform that particular sequence break), and I believe there's also a way to make it through using a very carefully-timed spinjump.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
As for synthesizing a new weapon, that would require detouring to Yoko after the requisite souls have been acquired, talking to her several times, then getting back on track -- that's a lot of time that would have to be made up through enhanced offense.
Additionally, any soul that you use in synthesis would have to be acquired twice (otherwise it doesn't count for 100%). Assuming we start with the Kotetsu, the follow-up souls for synthesis are Devil, Barbariccia, Malachi, Gaibon, Malacoda. Getting Yasutsuna (Gaibon) is completely out of the question because by then you're at the Mines and might as well just finish the game. The next best weapon is Kunitsuna at 58 attack (compare Kotetsu at 31 attack).
I don't know exactly what the damage calculation is, but I wouldn't be surprised if weapon damage is merely additive, not multiplicative...
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
That seems pretty consistent with the drop rates.Although, I haven't actually read much on the subject of statistics... and I don't know the standard deviation, but this very much seems consistent.
You think that after 600 trials, being .65% below the stated drop rate when wearing drop-rate-enhancing gear is "consistent"? The Soul Eater ring is nominally supposed to double the drop rate above what the bestiary says. And luck presumably plays some role as well, though I can't find any formulae.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
EEssentia: of course random events can deviate from the expected values. However, failing to find a 2% drop rate item in 600 attempts has odds of 1 in (1 / (.98^600)) or 1 in 183803. For Mothman, the odds of failing to find it in 30 tries is 1 in 105860. These are both pretty unlikely events, and Kriole says they weren't isolated.
I wouldn't be surprised if what happened was that soul drop rates were massively boosted for testing purposes, then when the game was about to ship, they cut it down and didn't test that the new rates were accurate.
I doubt you could blame this on a bad RNG; there's no need for Dawn of Sorrow to use a custom RNG so it probably just used an existing system (either third-party library or in-house system). Either way, that RNG will have gotten a lot of testing to verify that it is a good source of random numbers.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
If a soul has a 2% base drop rate WITHOUT adding the extra drop rate that luck provides and I don't find the soul for nearly 600 random numbers, then clearly there is something wrong.
VINDICATION!
I always felt like DoS was waaaaaay stingier with the soul drops than AoS was, no matter what the stats had to say. Combine that with DoS actually requiring you to use up souls to get new weapons and making many souls not very interesting unless you farmed large numbers of the same soul? Lame, Konami. Very lame.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Easy yes vote. I kept up with the WIPs as they were posted and they were all excellent; the remainder of the game did not disappoint. Great work, Kriole!
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I don't know that these all qualify as art necessarily but I'm pretty proud of them anyway. Though the joinery work on the serving tray is pretty crude.