This beats the current published run by 307 frames (~5.1 seconds). Most time was gained from better preicision.
Due to still having Snake rattle'n roll in fresh memory I decided to also take up this game since they're kind of similar due the isometric overview and quite similar controls. Also it's a short game and the run only took a few days to do.
The previous runs were seemly done with the bad rom dump so I switched to the rom I assume is the good one but I'm not entirely sure, it syncs with both dumps though so it's not a big deal.
Improvements
1 frame was saved in the name entry.
Level
Frames saved
Total frames saved
Practice race
16
17
Beginner race
16
33
Intermediate race
64
97
Aerial race
64
161
Silly race
96
257
Ultimate race
50
307
Level comments
A level can only be completed in multiples of 16 frames.
Practice race
Better blind stering, the frame rule knocked me back a few frames.
Beginner race
Quite limited level due to the frame rule of the bridge. The time was almost all gained in the part between the two pipes.
Intermediate race
Better stering overall, not very viable in the second half though.
Aerial race
Better stering... yeah that's it.
Silly race
Small route change in the beginning and better stering.
Ultimate race
In this level the goal is to make the screen scroll down as fast possible which saved 32 frames. I also ended input earlier, I could've ended it even earlier but then the ingame completion for that level would be 16 frames slower so I decied to have it this way.
Thanks...
goes to the previous autors for finding shortcuts and stuff.
I always thought the technique used to end input was part of the category of the run. That is, "fastest to end input" and "fastest to game completion" are two different categories (the first obviously having a shorter time via TASvideos timing, but the second, which isn't allowed to end input until after the game is completed, being more interesting for some games). Obviously, you wouldn't publish both (unless for some reason they had entirely different routes; wasn't there an April Fool's TAS that completed half a game with basically no input at all, just luck manipulation so that the first half of the game would complete itself from there?), but you'd choose whichever category was better.
So all that really needs doing is to add a category explaining the issue, and the run suddenly isn't suboptimal any more.
The games where ending the input way, way earlier and the game still reaching its end, and this producing an interesting run just because of that, are extremely rare (there might be about one game in existence where this is possible). Hence it doesn't deserve a category of its own.
The slightly (but just slightly) more common case is when the input can be ended some seconds before the actual ending, and doing so causes the game to end significantly later than if an optimal input was appended. This usually only results in a run that looks flawed and doesn't really add to the viewer entertainment.
I'd say that doing so is just bending the rules with no real benefit (for the viewers).
Emulator Coder, Site Developer, Site Owner, Expert player
(3598)
Joined: 11/3/2004
Posts: 4738
Location: Tennessee
Warp wrote:
adelikat wrote:
When to end input often has no clear answer. Therefore we have always let the author make that decision for themselves.
Perhaps there should be a more unambiguous guideline. I have always liked the "no further input appended to the end of the movie can make the game end faster or slower (or cause the game to not end at all)" principle.
No.
I love how you miss the point. There is no right answer, why would I force one? The guidelines discuss all possibilities in detail.
When to end input often has no clear answer. Therefore we have always let the author make that decision for themselves.
Perhaps there should be a more unambiguous guideline. I have always liked the "no further input appended to the end of the movie can make the game end faster or slower (or cause the game to not end at all)" principle.
This rule still wouldn't have solved the one argument where game end became an issue, i.e. super mario bros. The big debate was on the final axe touching - a certain type of jump would allow you to end the input earlier, but touch the axe slower. This would have passed your rule, because once the jump was executed, you can't speed it up or slow it down, however, it still ended slower.
The resolution to this issue was that movie times were calculated from the first frame touching the axe. The point is, when there is a conflict, rules are made within the community of runners that everyone agrees on. Yes, it takes some debate, but that debate is healthy.
Additionally, if we set finite rules, we'd miss out on entertainment in the clever ways TASers figure out to end movies early, such as this, this, or this.
So yeah, Warp, you are constantly trying to restrict the rules down, so that every movie could be auto-judged by applying the set of rules like a computer algorithm. That isn't how this site operates, and misses the fundamental reason the rules are loosey-goosey. We are looking for the most entertaining movies; it is just the reality that the audience finds the fastest movie to generally be the most entertaining.
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
Joined: 7/17/2004
Posts: 985
Location: The FLOATING CASTLE
Cool, thanks. Looks like this uses the lua script but not the rom hack. That's fine, the rom hack just helps a little in the practice and intermediate races.
Thanks for the encode, FerretFaucet! That definitely looked better.
Ordinarily there'd be no question that the camhack encode would get published alongside the normal encode, but in this case the camhack actually changes the run slightly. I'd say go ahead and publish it but note the difference in the publication?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Thanks for the camhack encode FerretFaucet (and TheAxeMan for the camhack), that makes the run a lot more entertaining. So yes, the camhack encode should definitely be published alongside the regular encode.
Also Aglar, nice run and an obvious yes vote.
This movie has been published.
The posts before this message apply to the submission, and posts after this message apply to the published movie.
----
[1728] NES Marble Madness by Aglar in 02:43.01
I agree that ending input when the finish line is crossed is the proper choice for this game.
Now if you ended input early, and the marble rolled around five corners and THEN crossed the finish line, THEN it would be entertaining and worth publishing. :)
