If you watched it after my last edit of that post the other day, you saw the fix... I edited the fix into the video, and adjusted the video to play back at a more correct speed. I meant it as sort of a test run or demonstration from the start.
I know very little about optimizing the physics in this game. As such, I didn't try to optimize a great deal beyond the last 2-3 seconds of movement at any given time. I abandoned memory watching without giving it much of a chance, because I couldn't make a pointer-referenced table that would work for me every time, and because I wasn't able to find subpixel positions, speed, or anything that would be truly useful other than screen X/Y. (Translation: lazy and didn't look enough) All I have determined about the physics (and some was discovered along the way, as you noticed) boils down to, the height gained off a bounce when you're holding S will be substantially higher if the ball is moving below a certain horizontal speed. It seems different for each ball.
I would love suggestions on improving it :) I spotted at least a few small improvements myself as I continued on (not even counting optimizing the jumps and physics fully). I am concerned about the publishability of a TAS of this game, though. There's no way to run it at the exact 57.1 framerate it supposedly has, and the sound effects don't play, so I had guessed that for the time being it probably falls under "not emulated well enough" (well, hourglass isn't an emulator but ya know)
I got at least two opinions from the IRC chat that a run wouldn't necessarily be rejected for not emulating the sound effects or for using 57fps in hourglass. Interesting.
I also stumbled upon this clip-outside-the-map glitch and i need to figure out how it works, and if it works in more places than here, literally the 2nd to last screen of the game... i initially suspect it's only in this particular spot (and almost certainly only with the flying ball). The framerate makes it difficult to see what he's doing.
http://www.youtube.com/watch?v=Y7kamk0NLAk
Aside from this, the only other public knowledge glitch is that the glass ball doesn't break when it bounces exactly into an inside or outside corner, allowing it to reach a maximum bounce height much higher than all other balls.
That "outside the map" glitch looks like it's just a missing wall in that room, which isn't promising for replicating the glitch elsewhere. But the framerate's atrocious so it's hard to be clear on what exactly he's doing.
The only other simple alternative I can think of would be a very narrow wall (like, 1 pixel wide) and a sufficient horizontal velocity to skip past it, which again I have trouble believing would happen anywhere else.
I could easily be wrong though. I hope you find something useful!
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
So I completed a test run of this game.
MKV: http://www.mediafire.com/?y8cbigzrlbabotz
Time is 9:56.57 so I got sub-10min. I have no doubt it could be further optimized by some seconds. This is my first attempt at TASing and the only real tools used were rerecording and frame advance.
DRybes, do you or anyone still have a copy of this TAS? Hourglass doesn't work on my system, so while I'm asking for favors, an encode would be best! I'm currently working on a Normal Any% speedrun and I'd love to see what sort of shenanigans you got up to in the TAS (and if I can't work some of them into a speedrun.)
If you're curious, my best time so far is 12:52, while my sum of best segments is 11:58. I think 12:20 is a realistic goal to shoot for, though it might take me a while to put together a run with so few execution errors.
Here, have this encode that I downloaded and never deleted.
Good luck doing all those corner bounces with the glass ball though!
EDIT: fixed link as per below. Sorry about that!
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Here, have this encode that I downloaded and never deleted.
Good luck doing all those corner bounces with the glass ball though!
Cool, thanks for the quick response. The TAS was very cool but is a bust strategically. Turns out the route I'm using in my speedrun is faster! (That is, a TAS of the speedrun route would be faster than the current TAS route.)
If anyone wants to take another shot at the TAS, here are some optimizations:
- Shinock Reign -
The TAS has the spider follow the red path from A to B. Time can be saved by having the spider follow the blue path, instead. The timing required is too precise for me to do consistently, so I actually do the red path in speedruns, but I've managed the blue path a few times in testing.
(Note that I'm speedrunning Normal, while the TAS is done in Hard. This room requires one more button press in Hard, but I think it's probably possible.)
- Pinewood to Shadowlands -
The TAS takes the red, overland path from A to B. So much time is saved by taking the blue, underground path that my best speedrun gets from A to B faster than the TAS!
- Shadowlands to Wisp -
The TAS takes the red path from A to B. That's the same path I use for speedrunning, but if any of the corners circled in green are glitchable from the room above, and if the jump depicted in green can be made, then the path in blue should be faster.
- Shadowlands Climb -
The TAS takes the red path from A to B. The density of blocks in that route is low enough that the TAS doesn't seem able to exploit any of its natural advantages, namely being able to move around at maximum speed at all times, getting boosts off walls and ceilings without hesitation or shattering, etc. I suspect the blue path should be faster because you'll need to spend less time charging jumps, but I might be wrong.
- Crystal Entrance -
The TAS takes the red path down, deactivates the green laser, then spacebars back to the top of the red path and follows the blue path with the gold ball. If the green circled corner can be glitched, there's no need to follow the red path at all, and the blue path can be followed with the glass ball from the start. Unusually, I've never been able to glitch that corner in testing, so it might not be possible.
- Crystal Exit -
The TAS takes the red path from A to B. That's way more consistent in speedruns, but the blue path is definitely faster assuming perfect execution.
- Miscellaneous -
The TAS is pretty careless with optimizing jump charging on long upward sequences, like climbing the hill, climbing Shinock Reign in both the present and the future, climbing out of the beginning of the future, etc. It also has other weird, random lapses like waiting for fireballs to spawn at the start of the pathetic ball sequence to the lab.
In Shinock Reign in the room in the picture above, it's possible to make the spider hit a wall as it falls down, making it change direction even earlier. Although you'd have to time it quite well to do so, but at least it's doable.
"An artist who can’t take constructive critique on their work is only hurting themselves and their potential.
Conversely, and artist that can’t communicate a critique in a constructive way isn’t helping anybody."
In Shinock Reign in the room in the picture above, it's possible to make the spider hit a wall as it falls down, making it change direction even earlier. Although you'd have to time it quite well to do so, but at least it's doable.
That's a good thought. I've managed this path in testing before:
The timing in the previous two rooms changes a bit, as well, and you're right that it's much faster. That (or an essentially similar strategy) is the source of the 54.72s best time for the "Get Iron Ball" segment LiveSplit reports in my speedrun, and it's definitely something a TAS should be doing. (In addition to hitting the first switch very quickly, as the current TAS does.)
As for the speedrun, there are several faster timings through Shinock Reign than the one I used, but they're just too technical for me to do consistently.
Two new findings --
I was able to glitch this previously unglitchable (to me) corner in Crystal Path:
In fact, flagitious reported doing just that on page 3 of this thread. It was reading his old post that caused me to go back and reexamine some more bounce patterns and I found one that works, though unfortunately it's much lower probability than any corner glitch currently in the speedrun.
And something even more astonishing to me, in the Shadowlands I accidentally managed to slip past a crush block without it triggering, followed by accidentally sticking a landing on a corner I'd never glitched before:
I've never before seen a crush block fail to trigger. I have absolutely no idea what happened, and I haven't been able to replicate it. (I just keep getting crushed by the block marked in red.) But it somehow happened once, so a TASer should be able to figure something out, if anyone ever decides to take another look at this game.
It could be something as simple as the crush block's trigger box being narrow enough that a fast-moving ball can just barely skip over the entire box if perfectly aligned (e.g. box is 5px wide, ball is moving at 6px/tick). That's the simplest potential explanation I can think of for why it usually triggers but sometimes doesn't -- though of course there could be any number of other explanations.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I don't believe terminal velocity is fast enough to tunnel through the entire hitbox in one frame. If it were, I believe I'd be able to replicate it easily, at least in that particular spot. My best guess is that the hitbox doesn't extend far enough to the left, so if you manage to embed yourself 3px into the far wall while falling through that space, you can slip past. Or maybe the hitbox isn't a box at all, it's a circle or diamond, and a 3px embed makes tunneling past its left edge possible?
I dunno. If it's the latter, at least it seems plausible that I just randomly smacked and embedded into the wall at just the right spot, at just the right moment, but can't easily duplicate the feat without TAS tools.
I've worked a few more demanding tricks/routes into my speedrun and managed to get my time down to 11:17. A well-executed run would probably be somewhere in the neighborhood of 11:05, but there's enough RNG and insanely difficult maneuvers in the run now that it will be a real struggle to achieve.
Also of note, I did a very quick and dirty proof-of-concept for a 100% run (just to prove to Midboss and chumlum of SDA that their preferred route was grossly incorrect), and put up a 17:57 on my second try. Be warned, it's not a pretty run.
Edit:
Any%11:5311:5011:3411:1710:51100%17:5716:5916:4116:3415:5715:41
Nice work! That's pretty impressive.
What was the reason for re-incarnating yourself at save points, when you didn't switch materials? You seemed to do it regularly with the glass ball.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
What was the reason for re-incarnating yourself at save points, when you didn't switch materials? You seemed to do it regularly with the glass ball.
It's so I can reset my position and velocity to something that's exactly the same every time. The corner glitch can be quite sensitive to even tiny perturbations, so all of the glass ball segments are split up into precise bounce patterns that start from a spawn.
Each time I spacebar, it's basically just me saying, "It's no longer possible for human execution to guarantee a precise height and velocity. Were I to continue without respawning I would almost certainly just break anyway."
A TAS would have no need to reset in that manner, obviously, but as a practical consideration, the speedrun must be broken up into segments that can be practiced, and then executed consistently.
I also twice do a "double respawn", once at the very start of the Shadowlands, and once when I switch to the glass ball in the Crystal Path. If you pay close attention, you'll note that in both those instances, I spawn the glass ball, immediately spacebar, and then respawn with the same material!
I do that for somewhat mysterious reasons. Sometimes (always?), when you spawn with a material for the first time after changing maps, the ball's starting conditions (i.e. height, and maybe velocity) are slightly different from what its conditions will be on all subsequent respawns with that material. That this is true I have no doubt, I just don't know why it's true.
Anyway, it's quite tedious to search for (and then practice) bounce patterns that depend on spawn conditions that require reloading the entire map to reinstantiate properly. Also, if you fail during an actual speedrun, you then need a second bounce pattern anyway. So, purely for the sake of pragmatism, my bounce patterns in the Crystal Path and at the start of the Shadowlands assume the initial conditions of a double respawn.
A long time ago, back when the speedrun mode of Within a Deep Forest was still enabled, a number of you did speedruns. If any videos of those runs exist, there are some as-yet empty run categories on speedrun.com/wadf just waiting to be filled in:
Glitchless
Any% Hard
100% Hard
Additionally, the Glitchless Hard run is over 10 years old and pretty beatable!
The TAS has the spider follow the red path from A to B. Time can be saved by having the spider follow the blue path, instead. The timing required is too precise for me to do consistently, so I actually do the red path in speedruns, but I've managed the blue path a few times in testing.
(Note that I'm speedrunning Normal, while the TAS is done in Hard. This room requires one more button press in Hard, but I think it's probably possible.)
- Pinewood to Shadowlands -
The TAS takes the red, overland path from A to B. So much time is saved by taking the blue, underground path that my best speedrun gets from A to B faster than the TAS!
- Shadowlands to Wisp -
The TAS takes the red path from A to B. That's the same path I use for speedrunning, but if any of the corners circled in green are glitchable from the room above, and if the jump depicted in green can be made, then the path in blue should be faster.
- Shadowlands Climb -
The TAS takes the red path from A to B. The density of blocks in that route is low enough that the TAS doesn't seem able to exploit any of its natural advantages, namely being able to move around at maximum speed at all times, getting boosts off walls and ceilings without hesitation or shattering, etc. I suspect the blue path should be faster because you'll need to spend less time charging jumps, but I might be wrong.
- Crystal Entrance -
The TAS takes the red path down, deactivates the green laser, then spacebars back to the top of the red path and follows the blue path with the gold ball. If the green circled corner can be glitched, there's no need to follow the red path at all, and the blue path can be followed with the glass ball from the start. Unusually, I've never been able to glitch that corner in testing, so it might not be possible.
- Crystal Exit -
The TAS takes the red path from A to B. That's way more consistent in speedruns, but the blue path is definitely faster assuming perfect execution.
- Miscellaneous -
The TAS is pretty careless with optimizing jump charging on long upward sequences, like climbing the hill, climbing Shinock Reign in both the present and the future, climbing out of the beginning of the future, etc. It also has other weird, random lapses like waiting for fireballs to spawn at the start of the pathetic ball sequence to the lab.
The timing in the previous two rooms changes a bit, as well, and you're right that it's much faster. That (or an essentially similar strategy) is the source of the 54.72s best time for the "Get Iron Ball" segment LiveSplit reports in my speedrun, and it's definitely something a TAS should be doing. (In addition to hitting the first switch very quickly, as the current TAS does.)
As for the speedrun, there are several faster timings through Shinock Reign than the one I used, but they're just too technical for me to do consistently.
I've never before seen a crush block fail to trigger. I have absolutely no idea what happened, and I haven't been able to replicate it. (I just keep getting crushed by the block marked in red.) But it somehow happened once, so a TASer should be able to figure something out, if anyone ever decides to take another look at this game.
