|
|
|
|
|
by mohn
2911 days ago
|
|
I'm not sure about systems older than the NES, but as of the NES era, it was reasonably common for a game's "physics engine" to model player position and velocity at finer values than just the displayed pixels. That is, an x position might consist of one byte for x [in pixels] plus one byte for x_sub [in sub-pixels] and similarly, the minimum non-zero speed could be smaller than 1 px/frame. If there is some modeling of acceleration, it will be slower to stand and wait right next to a barrier or trap and not start moving until it disappears. Instead, it's best to have some speed already and be positioned so that you're about to run into the barrier on the frame before it disappears. Then on the next frame, where it does disappear, you move into the vacated space without slowing down or taking damage as the case may be (or starting from a stop, as you would have if you stood still while waiting). If you're not already familiar with tool-assisted speedruns, I highly recommend tasvideos.org In some TASes, the player will move/shoot/jump/etc. in ways that seem bizarre but are actually done to favorably affect the pseudorandom number generator (e.g. prevent enemies from spawning or shooting, so the additional sprites don't cause lag frames). Since the goal of this bot was score, not speed, there's probably not much of that going on here. I really like the move at 0:35 in the top video for Montezuma's Revenge, where the bot climbs up to the next screen and then immediately back down, presumably to reset the position of the green bug thing and get on the left side of it. That reminded me of some ladder action I've seen in Mega Man TASes. |
|
And then there’s movements like the arm pumping in Super Metroid, where it’s done “because you can” while performing long stretches of movement that aren’t very entertaining/complex on their own. (One might say that it’s done for a demonstration of skill when human players do it, but there’s no similar justification for a TAS doing it.)