This is a 3-frame TAS. And yet it took months to actually finish, with thousands of rerecords. Let me explain.
In this game, you have to quickly drag a hand towards a monkey to "spank the monkey" (for non-native speakers like me: this is a dirty joke). If you manage to spank it at more than 200mph, you get a nice music, showing that you succeeded. Besides the incredible music (excerpt of
The Adventures Of Grandmaster Flash On The Wheels Of Steel), the main perk of the game back in the days is that you could very easily glitch it by dragging the cursor out of the screen or pausing the game, leading to incredible scores around 800-1000 mph.
Some of these bugs are somewhat reproducible in Ruffle and can lead to scores within this range with some effort.
The game can be played for instance
here and the .swf downloaded
here.
Finding the maximum score
As a base of comparison, the maximum score you can get from going to the maximum right of the screen to the maximum left in one frame is a bit above 250 mph. But we have no reason to stop here, as we can enter mouse position values below those places.
Ruffle provides the ability to enter x;y mouse positions out of the screen window (labeled as
a bug that I hope will never get fixed). We use this ability to enter arbitrarily high values. But if you think I just entered super high values and was then done with TASing this game, oh god you're wrong.
There are three meaningful frames in this TAS:
- 384: positioning the mouse prior to grabbing the hand (preparation frame)
- 385: grabbing the hand on the right position (pre-slap frame)
- 386: moving the hand to the left position (adjustement frame) while remaining within the range accepted by the game
And hand is then released at frame 387 in an empty frame, ending the inputs.
After a first round of empirical search and a submission that got improved by current co-authors by fixing framerate and timing, I ended up using JPEXS to decompile the game and understand exactly what's going on. Basically, the game checks that the hand is in an acceptable range (between 10 and 350 pixels) at some point of the code, but only after some processing, which still allows us to enter extreme values beforehand, as long as we make sure some variable still ends within this range. With some computations, we can calculate the maximum value that gets the variable containing the hand x position as close to 10 as possible.
(I kinda forgot all the details as I'm writing this after weeks of procrastination, but you can directly check
the core logic handling this, as it's pretty short.)
Current mouse values are optimal because increasing them from even 1 makes some internal variable overflow.
Then we can get some additional extra score by abusing framerate, as one line in the code divides the result by some speed factor (see details
here).
Results
The results are the following:
- frame 384: -53686737 (preparation frame)
- frame 385: 53686737 (pre-slap frame)
- frame 386: -36085227 (adjustement frame)
Score: 214.748.340 miles per hour.
As a reminder, speed of light is 671.000.000 mph. Our score is 500 times faster than the fastest man-made object, the Parker Solar Probe (see
this video to get an idea of what this speed actually represents). We therefore successfully managed to make our monkey the fastest man-made object, at 32% the speed of light.
Considering the size of my screen, that means putting the mouse roughly 15 kilometers (9 miles) left and right of the screen in one frame, which I challenge you to do in real time. Considering one frame is 1/100th of a second, that means moving the cursor at 3000 km/s, which is 15.7 times faster than the parker solar probe.
Category
Besides "High score", this movie could be published under the "mouse glitch" category made up for
this movie, although there really isn't much more to the game. A normal run would be just as fast and within the 250-300 mph range, which is pretty boring.
Room for improvement
While the speed factor can theoretically allow us to get a maximal factor of 10 on the final score, I only managed to make a factor 2 work. perhaps the game just doesn't compute fast enough for more to work. I don't know, I just haven't managed to make something work while starting with a framerate of 1000. Making this work could finally make us exceed speed of light.
Submission / encoding note
As I'm modifying the default framerate of the movie so I can get the internal timer to run at a different rate (while actually changing framerate of single frame only), this make libTAS laggy for frames that are not running at a framerate of 100 (since they're non-draw frames). For encoding convenience, I leave the .ltm file with frames up to the end of the song so they're set at 100 fps, but the movie does end at frame 386.
Versions
- libTAS v1.4.7
- ruffle-nightly-2025-09-22
- monkey.swf md5sum: 23e550300d5ba036a994534eca0a8525
eien86: Spank the Monkey (named "Slap the Monkey" in the .swf file, probably an earlier naming) is a game with the only objective of slapping an inflatable monkey as fast as possible using a quick sideways movement of the mouse. The game is only beaten if you get to exceed 200mph, which this movie does, and then some. The movie achieves the goal arguably in the least number of frames possible, but also with the highest speed (i.e., score) reaching something like 3% of the speed of light in doing so, exploiting a mouse glitch.
The "maximum score" and "fastest solution" goals here are intertwined and cannot be easily divorced. I'd argue maximizing the speed of the mouse is also an expectation of a standard movie and therefore clarifying "maximum score" as a goal is not necessary. Nor it is the fact that a mouse glitch, since this is an expectation of an any% approach, where everything goes. Therefore, I will remove all specification of goals and leave this as baseline. Any obsoleting movie should either (a) be faster, or (b) score more speed.
Accepting to Standard
nymx: Claiming for judging.
nymx: This submission blew me away. At first, I laugh so hard after I saw this video. It took me by surprise. Then, I noticed the frame war battle. Who would ever have thought that such a short movie would have been so complicated to optimize. It just goes without saying, all TASes cannot be viewed at a surface level...you have to think outside of what's visible.
Even though entertainment is not a consideration for acceptance, I have to say that this was quite funny. I think the 14 yes votes are in agreement with me. In fact, watched it multiple times to just be amused over and over.
Accepting to "Standard". :)
nymx: Replacing with a "zero" re-record input file.
It's more complex as there are 5 frames and I can't evaluate the underlying logic (384 - 385 - 386 are not aligned and can't be)... I'm still blindly guessing how to vary their values
