I'm voting yes on this excellent submission, but I'm voting SUPER YES on zoboner's character development over the course of this thread, which has been adorable.
A warb degombs the brangy. Your gitch zanks and leils the warb.
It remains the case that YouTube, as well as your desktop video player of choice, offer "seek" functionality that allows you to avoid watching sections of a movie you know are repetitive if you do not wish to.
I really don't get how people seriously talk about stuff like this as if it diminishes the value of the run. Why watch a boring thing and then complain, when you could just.. not watch the boring thing?
A warb degombs the brangy. Your gitch zanks and leils the warb.
So something potentially important happened during the AGDQ race - the area 2 boss just didn't appear in Skavenger's run, but the item was there, so the fight was skipped entirely.
Boss despawning has previously been observed in area 5, but in that case, being unable to kill the boss meant the item never spawned, so it wasn't useful. Reproducing this, on the other hand, would a decent chunk of time.
A warb degombs the brangy. Your gitch zanks and leils the warb.
I was definitely entertained and voted yes. I hope this is published in the vault, though I will understand if it is rejected for not meeting notability standards.
A warb degombs the brangy. Your gitch zanks and leils the warb.
This is really wonderful!
The way the spooky head hovers at you but never really interacts with you reminds me more of some kind of stylized traditional theater than any enemy AI I've ever seen. And then there's the bit where you mime climbing down from a ledge, when there's obviously no ledge there. Combined with the subdued soundtrack and sparse sound design, the whole thing really feels like some kind of minimalist performance art more than a game. It's great.
A warb degombs the brangy. Your gitch zanks and leils the warb.
The fact that cart swapping is nondeterministic, which I did not realize, changes my opinion on this, I think.
It's not a great solution, because there are real runs that really do take advantage of uninitialized RAM, but maybe when faced with drawing a truly arbitrary line about unknowable probabilities, we have to just accept that TASes exist to some degree in a realm of abstraction, and declare that we are interested primarily in running the game in its purest starting state, with RAM initialized to 0.
It might occasionally be pretty interesting to have a run that does rely on uninitialized RAM, in which case we could consider allowing an "arbitrary starting RAM state" branch. Any attempt to choose a "reasonable" number of bits we are allowed to flip should really be avoided – we will inevitably be presented with a run whose time scales down linearly with the number of bits we can flip, and whatever line we've picked will be very unsatisfying.
My concrete preference, at this point, is:
The default branch always begins from zeroed out RAM. On a case-by-case basis, "arbitrary starting RAM state" submissions can be accepted to Moons, much as we do with "game end glitch" runs. We never draw a distinction between runs based on the number of bits they flip, unless that number is 0.
A warb degombs the brangy. Your gitch zanks and leils the warb.
I think runs like this can be accepted as obsoletions without much fuss. TASes are full of things you'd need the equivalent of a "teensy metal pointer" for without an emulator - L+R, N64 joystick values you can't push a physical stick to, heck, even autofiring at 60fps is not something achievable on a real console without extra electronics.
Now, we are concerned with validity at some level. We don't want to just arbitrarily change our emulators so that the games appear to be faster. But this does not hit that restriction. An NES doesn't need to have just been powered on to play a game. We can, as feos pointed out, put in our own cart and set them to whatever we'd like. Just like we can plug in our own controllers that can produce the full range of joystick values and autofire.
Trying to define a "reasonable" number of nonzero preset RAM values is a fool's errand. Observing a few NESes a few times won't tell us anything about what's possible on every model at every temperature, and even if we can observe general trends, no one will ever prove that particular unlikely starting state is actually impossible, or probably even that a reasonable seeming one is possible. This approach is fundamentally flawed and will satisfy no one. Imagine a movie where each bit you can set saves around five seconds, but also, the further from the beginning of RAM the bit you choose, the more frames you can save. Who will decide where to draw the line? What if, a month after the line is drawn, someone claims to have observed an NES start up with a bit set further into RAM than anyone had seen previously?
Much better to accept that one of the tools that can assist us is custom carts that set RAM to whatever we want.
If this leads to some really degenerate runs, that game can always have a 'doesn't preinitialize RAM' branch in Moons.
A warb degombs the brangy. Your gitch zanks and leils the warb.
I have zero published movies, but I've played around with TASing a decent bit. Here's what I've done:
* Tried for wacky challenges in established games (one of my first TAS attempts was a "the ground is lava" run of a few SMB3 levels.)
* Made WIPs for little-known games not yet on the site (I still want to get back to Ninja Senki some day...)
* Entered forum competitions, and learned from collaborating with more experienced TASers/comparing our results to those of better teams.
* Raced a friend with a similar level of experience to see who could TAS further in a game chosen totally at random from the NES library, in two real-time hours.
* Downloaded published movie files and fiddled around with them to see if I could find any improvements, or at least get a better understanding of what goes in to making an optimized run.
TAS tools are really fun to play with, and creating and submitting a complete, publishable run is not the only goal worth having!
A warb degombs the brangy. Your gitch zanks and leils the warb.
Mighty Bomb Jack is the king of this, especially the Japanese version. Even the basic game mechanics are chock full of it, but then there are the secrets. Basic ones involve jumping off of random tiles twice to reveal chests, but there are also some in the Japanese version where you have to jump like 10 times or something? I can't find a good reference for it right now, just various people saying you have to "jump fewer times" in the English version, but I know it's absurd. And then there's a really opaque level warp mechanic you have to understand and use correctly to get the good ending... this game is nuts.
A warb degombs the brangy. Your gitch zanks and leils the warb.
I can't believe you delayed saving baby Moses just to demonstrate some stupid glitch. You mean to tell me the fabled heroes Aglar, Aqfaq, nitrogenesis and Wak017 fought and died in the great Baby Moses Frame War of 2011 for this? Tompa and TASEditor, under the unimaginable time pressure of the 2014 Speed TAS Compo, persevered and eliminated yet more frames, for this!?
Voting Absolutely Not until baby Moses's life is no longer being needlessly jeopardized by unnecessary braggadocio. For shame.
A warb degombs the brangy. Your gitch zanks and leils the warb.
feos, it's really awesome to see you pushing for emulator improvements and working towards them yourself. As someone who cares but doesn't have anything like the time, i really, really appreciate your efforts.
Subframe input in fceux this year or next year would be amazing to see.
A warb degombs the brangy. Your gitch zanks and leils the warb.
Yeah I have to just disagree with Warp that a speedrun is fundamentally about watching the screen. A huge amount of my enjoyment of speedruns is conceptual - I can't tell you how many times I've loved the submission text of a TAS but had no interest in watching the video, or just skimmed it.
Sometimes speedruns look really cool, but sometimes they are really cool in other ways, and the value is in the fact that the author has understood a system, exploited it in a novel way, and communicated that effectively to the public. Often the most effective way to communicate it includes a video of the screen, but sometimes that's not sufficient, and other times it's not necessary.
A warb degombs the brangy. Your gitch zanks and leils the warb.
While I would like there to be runs of Mario 3 that showcase gameplay on the site, I have to disagree that the DCPM glitch run is "not entertaining to watch" or that there is "nothing to look at." There is absolutely something to look at: A real console turning on with a Mario 3 cartridge in it and instantly displaying the credits. No one had ever seen that before! Far from being "nothing" to watch, it was amazing to watch, and I'm so glad I got to see the reveal live.
I do agree that if it turns out an enormous class of games can all be beaten the exact same way, I would rather just see one video and a list of all the other games it works for.
And certainly this will get more confusing if more incremental examples are found, for instance, a DCPM-style glitch that for some reason only works after playing one full level.
I think it's ok to let the judges draw reasonable lines about what kinds of run are too similar to existing runs to publish, as long as they accept at least one good example of any such run. Accepting it to a demo category sounds ok too, I have no problem with that, though I do think a note/link should be placed on any affected games' any% pages to the effect that this is not really the fastest known completion.
A warb degombs the brangy. Your gitch zanks and leils the warb.
Both of our hardness proofs are resilient to known glitches [2, 5], where the implementation of Super Mario Bros. is counter to the intuitive Mario physics with which most players are familiar. Figure 1 shows examples of such glitches; see Section 2 for details. By contrast, the previous NP-hardness proof [1] breaks when such glitch behaviors are permitted.
Awesome!
A warb degombs the brangy. Your gitch zanks and leils the warb.
Yes, everything that isn't any% or a straightforward 100% is arbitrary
any% is arbitrary too. we tend to define its goal with vague "know it when you see it" get-to-the-credits semantics, but then when the credits look weird, or behave differently, or are visited in the middle of the run, all that goes out the window and we start talking about which memory addresses were jumped to or whatever. But to my knowledge there has never been a complete specification of which execution histories are valid completions and which aren't, and doing such a thing would be extremely difficult - especially because if, say, there was a secret ending no one had found yet, any definition based on the known endings would almost certainly exclude it, because game designers do not express their intentions with respect to execution histories, they express them with respect to graphical displays.
So we do our best and don't worry about it too much.
A warb degombs the brangy. Your gitch zanks and leils the warb.
This is one of the most enjoyable submission comments in quite some time. Extremely well done.
I personally think ending input early makes the run extra hilarious, and is great.
A warb degombs the brangy. Your gitch zanks and leils the warb.
Warp, you appear to have completely misunderstood what I said. If their construct is indeed not a lock because of a walljump, then the worst case is not as bad as they claim, and their analysis is wrong.
It kind of seems like you're saying that sorting is O(n^2) because bubblesort exists.
A warb degombs the brangy. Your gitch zanks and leils the warb.
