This is an interesting barely know game. A Disney game featuring Donald Duck that did not come out outside Japan.
It's a straightforward platformer game but with quite various levels.
I don't know much about the story, but basically follow the instruction of a magical hat to defeat Evil Magicial Peete.
The game is played in the normal difficulty (the default one), changing to easy could make for a shorter run since bosses die in 2 hists instead of 4-6
I wrote a Lua script to help me show you various information about Donald (speed/coord/timer) and enemies. It can be found at https://github.com/Skarsnik/sneshacking/blob/master/Lua/donaldduck.lua
The game does not offer many specials tricks to save frame aside keeping your speed or reducing lag, there is no special input, mostly perfect gameplay.
In the first part of the game you need to collect 300$ to buy the magical hat for Daisy, and you can choose between 4 jobs. I used the same one that RTA since you can't do the same job twice.
Windows level: The windows cleaning job. You need need to clean all the dirty windows to complete the level. The big-time save here is you can cut the cleaning animation after the first half of the window is clean and start the animation again, this saves 20-22 frames per window.
Time trial: It's a time trial challenge, you need to finish the level before the timer reaches 0. This level introduces jumping from a peg, which gives you the maximum speed you can get, you move 5 pixels per frame instead of 3 pixels per frame.
Clocktower: This level is all about the pegs! Keep jumping from then and you are good. Also facing the opposite direction of the conveyor make them move sooner and you can jump earlier.
Village: The village is a pretty straightforward level, this is also the first one you encounter enemies you can kill. Most optimisations are just reducing lag.
Village boss: this is where RNG is annoying, the boss can show himself out of one of the barrel and get back immediately before you can hit him, or delay when it shows himself. The only thing I really did there is never going too close where it will show off since it will not show at all. Pressing down before a hit to done a beak attack does 4 dmg instead of 3.
Snow race: The goal here is just to reach the end of the level before the other racer. Two-point to note here, you get the max speed in slope (5px) and the end of the small platforms in the middle give you this speed. The end looks slow since I left the slope, it's because letting Donald run to the exit lag the game a lot with the destruction of the small buildings, so I ended using the 'backup' route since it barely lags and thou save 1x frames.
Mountain: First level with verticality. The trick is mostly to build enough momentum to jump as soon as possible from one rising platform to another
Mountain boss: This boss is easy, just hit him as soon as the invulnerability frame ends.
Cristal level: The only thing that seems out of place for a TAS here is getting here by one of the first enemies, but if you jump over it the game lag a lot that it ends up being slower. The rest of the level is just trying to trigger the block that makes the mirrors fall off as soon as possible.
Cristal boss: The ghost, interesting fight since you have to make it damage itself. You need to not move for him to make appear the falling icicles from the ceiling.
Forest level: This is a really interesting level where the level rotates to make the floor above your always flat. I tried to abuse the fact that you fall faster than you move to save frame, that why you can see some small jump toward the end.
Airship/cloud level: The first auto scroller of the game, there is not much I could do here, since it does not lag, only toward the end you can jump to trigger the end of the level slightly offscreen. Walking in place is done by pressing left & down at the same time.
Castle 1: Hold right and jump :)
Teleport level: This one was tricky, but it's mostly trying the build enough momentum to reach the platform that teleports you the highest.
Juggler boss: I tried a lot of things to make it stop sooner but it does not seem you can't do much. What I could observe that make him stop 'randomly' is the ball sprite animation timer making the invulnerability timer of the juggler pause sometimes.
Second autoscroller: The game actually lags when the big jaws hit the ceiling creating some small debris, that why you see me trying to not move much and keeping them far away from Donald.
Kangaroo boss: this boss is interesting since it reacts a lot to Donald position, if you stay too close to him it will mostly guard and block your jump. That why you see me moving left before getting back to jump on him
Castle level 2: The beginning of this one is more interesting, you can see that you keep the first peg momentum being hit, so it end up being faster trying to avoid him with regular movement.
Peete phase 1: It's mostly trying to hit him as soon as possible, the only variance is sometimes you need to spend more time landing on the platform if you want to make a beak attack register correctly.
Peete phase 2: Jump from hand to hand and hit him :)
Can this TAS be improved?
I am pretty sure there are 1-3 seconds to save (or more, depending on the joggler pattern).
Maybe 1-2 frames on the window level.
I noticed a bit late that you somehow keep a bit of your vertical momentum when jumping after a peg, which could allow you to jump farther in the Time Trial level and make another jump possible in the clock tower that maybe save half a second.
The lag on the second autoscroller is sometimes RNG hell, jump a frame more and you lag more, or save 1-2 frames, the same for moving. I did not try every movement possible since it was already time-consuming to found no obvious method of lag reduction.
arkiandruski: Replacing submission file with one that removes 9657 frames of blank input from the end. Also, claiming for judging.
arkiandruski: Thank you for your submission.
As pointed out in the forum thread, there are certain time saving techniques that this run doesn't take advantage of. One is a glitch in the first level which allows you to save about 15 seconds. The other is a movement tech which allows you to preserve momentum off of slopes which can be used a few places in the run.
When deciding whether to accept runs with known improvements we need to weigh a few factors: the significance of the improvement, the amount of work it would take to implement, the availability of the information, and whether the run itself looks sloppy outside of the improvement. This run happens to be close to the border of acceptability in a few of those categories.
Based off the runs posted in thread, I would calculate that there's 20 to 30 seconds of improvement with these new techniques, possibly more since I'm sure the movies posted are more concept demos than fully optimized runs. In the TAS world for a run this length, that actually is fairly significant. Enough, at least, to give me pause. I've gone back and forth a few times on whether or not it was enough to justify rejection.
In testing how hex edit friendly the run was, I delayed the ending of the first level by a few frames. The run continued to sync until the barrel boss, which leads me to believe levels are hex friendly, but some bosses would have to be redone if the first level were fixed. The momentum trick can be applied throughout the run, however, so levels will have to be examined and tested to account for this trick, which would mean that improving this run is not completely easy or simple. It does seem through a quick look that there's maybe 1 or 2 levels besides the one demonstrated in thread that would benefit. The game doesn't have that many downhill slopes that can be used.
As for the information, the first level glitch was only available on Discord and not in any userfiles or dedicated forum threads. I can't hold this against the author for a few reasons. One is the trasitory nature of live chats. Even if Discord has a permanent archive, topics change so fast that it's hard to know if there even will be useful information. Even if Discord were easy to search, the Guidelines page did not list it as a potential resource at the time of submission. As far as I can tell, the other glitch wasn't mentioned publically at all.
As for whether the run looks sloppy; while the input file does show evidence of an inexperienced TASer, such as being submitted with over 9,000 frames of blank input at the end, having random inputs during lag frames, and using autofire during transitions when only a single press is needed; watching the gameplay I can tell that the author made efforts to have everything happen on the first frame possible. Watching the run and ignoring the fact that there's known improvements, nothing stands out as being obviously slow or suspicious. As such, I can't say the run is sloppy or that no effort was made toward optimizing the run.
Based on this and the fact that nobody has made any moves toward making the improvement in the near future, I feel this run is acceptable for publication. Consulting with the other judges, they are of a similar opinion. Audience reaction has been decent and I find the game interesting. Accepting to Moons.
EZGames69: Processing