For most of his life, Earthworm Jim as just an ordinary worm engaging in normal worm activities, until the Ultra-high-tech-indestructible-super-space-cyber-suit graced his presence. From this point, he was able to embark on many adventures, and go up against the evil “Earthworm Kim”. Unfortunately, Kim was not kind, and required 74 Udders and 950 Marbles from our favourite worm to beat her and consequently, the game.
That was until Jim discovered the power of being able to jump really high and decided to just skip the game.
Why PAL?
It is standard for most pre-2010 games to be speedrun/TAS’d on an NTSC version due to the increased framerate. However, Earthworm Jim 3D (EJ3D) benefits quite a lot from using the PAL version for Any%. The European releases of games often have a language select feature built in to accommodate the most common languages in Europe, (English, French, German, Spanish and Italian for EJ3D), however the developers added an additional “nonsense-language” called Jibber-Jabber. Either through laziness or to not stretch jokes on for too long, the textbox count with Jibber-Jabber is significantly reduced. It takes 5 frames to clear a textbox, so Jibber Jabber saves 60 frames over the next fastest languages, Italian and Spanish (The introduction with Jim in the hospital is always 6 textboxes regardless of language)
English
French
German
Spanish
Italian
Jibber-Jabber
Intro Textboxes
23
18
20
16
16
5
Credits Textboxes
6
6
5
6
6
5
Total
29
24
25
22
22
10
Key Techniques
Superjump
A standard move in the game which is activated when you crouch and then press A with a neutral stick. Whilst this is an intended move, the developers did not consider how high you can get with this move when protecting the player from going out of bounds or accessing areas early. Instead of going through walls, the way of going out of bounds in this game is jumping over walls, so optimising the height you gain is critical for some sequence breaks to work. The twirl/hover move assists with some of this, allowing Jim to gain 0.042 vertical units per frame for 22 frames, and allowing the ability to travel further, extending the range of how far you can go. This all might seem trivial, but it is all crucial to why this run works
The Credits Trigger
(AKA Hey, lets just “L to Levitate” randomly whilst glitch hunting and hey oh wait, there’s the credits.) Like in most games, triggers in EJ3D are used to define when moments in games are meant to occur, such as cutscene triggers or loading zones. However, unlike a fair amount of games, sometimes there is a random trigger just floating in the air. This is the case with the credits trigger. The credits trigger is a trigger zone 97.7 units off the ground, which is around 4x the height of a super-jump and twirl combo. Whilst this is certainly out of reach in normal gameplay, and certainly would not be something you would stumble upon randomly during gameplay. However, this route seeks to get there somehow…
Route
Intro
Upon booting up the game and cancelling the intro musical cutscene, we can auto-cancel the title demo with any button. The interesting fact about this is that it plays out the action even though you’re cancelling a cutscene (eg. A would make the character start jumping, albeit freeze it very shortly after). The only one which persists is holding Z to pull out Jim’s Blaster. This persists until Jim comes out of the elevator doors in the intro.
After selecting Jibber Jabber as the language (the language chosen does temporarily affect the file icon), we start the file and go through a whole heap of cutscene that takes us to 33s on our TAS timer.
The Climb
Next, we head back to the elevator. Jumping out of a max-speed roll (~0.7 units/frame) gives a 43% initial boost in speed before the speed tends towards 0.7 again. As such, the fastest way of moving horizontally in EJ3D is rolling and short hopping (1-frame-A jumping) to maximise these jump boosts.
We then jump onto a small lip on the elevator frame. There are a lot of surfaces in the game where jumping onto them locks Jim into the jumping animation for a short period of time. This is not a good effect since it delays when we can initiate the next crouch. Being on the elevator frame provides enough height to allow the player to get on the roof of the tunnel to the entrance to “Memory” (The first sub-hub in the game).
The next jump is easily the hardest in this run, as we need to jump from the memory tunnel roof onto the back of a window. Unfortunately, the non-slippery part of the back of this window is too high for us to reach, so we must have the right speed, angle and position to be able to slide up the slippery sloped part of the window. Coming at this with not enough speed or Y Position will not allow you to get high enough, not coming at it from the right angle could easily yield the speed coming in to be converted into speed slighting directly away from the window. However, we get on top of the window and convert some of the speed we have into sliding away from the memory tunnel and nearer to our next destination.
The next jump is not a superjump since the height we need to get there can be achieved with a normal jump. Since a superjump requires you to start from a standstill, if you can jump normally when travelling predominantly horizontally, it’s best to do so. This leaves us on top of an electrical cable section.
Jim then jumps onto the back of a window before jumping off that and around the wall to the top of an electrical cable stub, and then on top of a slightly higher stub. This leaves us at around 140 units off the base ground (6-7x the height of a superjump and twirl combo). Now that we have barely enough height, the only thing left to do to hit the credits trigger is to launch ourselves back to the centre of the room to hit the credits trigger.
The only thing that is left is to clear the rest of the textboxes to allow the credits to flow without any additional inputs. The textbox triggers can be triggered a frame or two sooner by interrupting the “locked” walking with crouching and jumping to the next trigger.
Miscellaneous
A common question when I talk about the Any% TAS is about whether a 100% TAS is in the works. Yes, it is in the works, and was being made until a few months ago where a reroute was discovered that saved a whole bunch of time by drastically changing the level order, which also obsoletes everything past 35s into the run. Progress on the new route will start at some point in the coming months, however here is a WIP of the TAS I was working on
Thank you to Koffingrockz, Markusman64ds & CardinalPickles for assisting with glitch hunting this game. An additional thanks to Isotarge and RingRush from the DK64 community, who have been an inspiration for glitch hunting, TASing and helping promote the idea that learning why the small things work makes the big things come.
feos: While this is a good movie, we can't agree that using the PAL version here was justified. As said in our game version rules, PAL versions are "generally not allowed, unless there are significant technical and/or entertainment merits to using this version". Some examples of notable differences that justify using the European release are provided in the rule body, but here's more examples:
Hogs of War was accepted because it was the original release, gameplay quality wasn't compromised during porting, because it wasn't a port.
PAL Super Mario Bros. was rejected because no notable difference was found that would justify using that version in addition to the NTSC one that already existed.
With this game, gameplay ends up being visibly identical between both version. Also I can't agree on having this version published until an NTSC run is completed: the rules clearly state that it's "generally not allowed", rather than "not preferred" which would've been less strict.
Rejecting and looking forward to an NTSC submission!
[14:15] <feos> WinDOES what DOSn't
12:33:44 PM <Mothrayas> "I got an oof with my game!"
Mothrayas Today at 12:22: <Colin> thank you for supporting noble causes such as my feet
MemoryTAS Today at 11:55 AM: you wouldn't know beauty if it slapped you in the face with a giant fish
[Today at 4:51 PM] Mothrayas: although if you like your own tweets that's the online equivalent of sniffing your own farts and probably tells a lot about you as a person
MemoryTAS Today at 7:01 PM: But I exert big staff energy honestly lol
Samsara Today at 1:20 PM: wouldn't ACE in a real life TAS just stand for Actually Cease Existing
I have a video of a NTSC rough TAS, I do not have the input file anymore. Plus it isn't at an optimisation level I would be happy with since it was made with the intent of demonstrating what Any% would look like with the glitch which was new at the time.
I don't think that we need to reject this solely for being on PAL, but I think it does mean that any attempt to obsolete it should use NTSC.
My vote: Yes. Short movie, very to the point. I liked.
PAL versions of ROMs are generally not allowed, unless there are significant technical and/or entertainment merits to using this version.
It says "generally not allowed", not "generally not preferred". It's stricter than "okay for now, but do it right next time". And with this game, there are no significant merits worth using the PAL version. It's just very slightly different, like SMB PAL.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I posted this in Discord, but moving it to the forums per request.
Frankly, I think the decision to reject this is a mistake.
It has been pretty well established that an NTSC run and PAL run are visually incredibly similar, with a few frames less of gameplay in the NTSC version to go along with ~.8s more of text that is too fast to read. From an entertainment standpoint there is functionally no difference, although you can at least argue PAL is more entertaining since the cutscene difference can theoretically be noticed unlike the gameplay difference. But really, I don't care to argue one side or the other here.
What I do believe is that this decision effectively says having no run is preferable to a run with the "wrong" version, even if they are essentially identical. This is not a question of legitimacy of the run, but rather how strict to be about enforcing rules for the sake of it.
The rejection message tries to sidestep the issue by saying "Looking forward to an NTSC submission". But there is no guarantee one is coming (and based on what Ballaam has said elsewhere, I doubt one will be coming in the near future). The run is up on YouTube, so why would the TASer jump through a hurdle and redo the run just to have an end product that looks identical, when they can spend their time working on other things? This kind of red tape just frustrates people and make them less likely to bother submitting in the future.
If this run was posted with the clarification that future improvements on NTSC could obsolete it, then that seems perfectly reasonable to me given the site's version stance. That makes everyone happy and is consistent with what happens when improvements are known but may not be implemented right away. But the case that the site is in a better place without this run is weak to me, and alienating to others.
I really wanted to submit this as NTSC verison however if i do that, it will be instant rejection because copying someone else's input and submitting it without permission is not allowed in TASVideos.org
I really wanted to submit this as NTSC verison however if i do that, it will be instant rejection because copying someone else's input and submitting it without permission is not allowed in TASVideos.org
This wouldn't work anyway due to a different frame rate. You'd have to recreate the run from scratch if you want it to be optimal.
-----
Considering that the time difference is so minimal, I do believe that this should have been accepted rather than rejected.
What I do believe is that this decision effectively says having no run is preferable to a run with the "wrong" version, even if they are essentially identical. This is not a question of legitimacy of the run, but rather how strict to be about enforcing rules for the sake of it.
The rejection message tries to sidestep the issue by saying "Looking forward to an NTSC submission". But there is no guarantee one is coming (and based on what Ballaam has said elsewhere, I doubt one will be coming in the near future). The run is up on YouTube, so why would the TASer jump through a hurdle and redo the run just to have an end product that looks identical, when they can spend their time working on other things? This kind of red tape just frustrates people and make them less likely to bother submitting in the future.
If this run was posted with the clarification that future improvements on NTSC could obsolete it, then that seems perfectly reasonable to me given the site's version stance. That makes everyone happy and is consistent with what happens when improvements are known but may not be implemented right away. But the case that the site is in a better place without this run is weak to me, and alienating to others.
That would actually be rather arbitrary. It would either mean that we're ready to ignore the PAL rule every time there's no NTSC run yet, or just from time to time. To be less arbitrary we have some discussion about the audience's general preference, to check if it aligns with the rules. I even posted my preliminary stance on this movie, and the author expressed understanding. What was seen in this thread can't be considered general consensus that PAL should be allowed in this case, it was actually the opposite. Having no noticeable gameplay differences between versions plays a role I think. And skipping dialogs doesn't count as such unless the very gameplay is based on that.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I understand the reasoning for the rule, since it would be undesirable to publish a movie that was faster on PAL purely because it saved 2m to text over NTSC but lost 1m50s to 50fps. Unless of course this hypothetical run then saved another 10s for PAL because of some PAL-only glitch, in which case it would provide something unique for PAL.
That I get, and hence I understand why the rule is in place.
My personal disagreement with "because this is on PAL, it should be rejected" is more because that initial disqualifier (losing time to 50fps) is so marginal (0.06s), especially in comparison to the time saved (0.8s).
I get that there has to be a line so that the initial case I mentioned doesn't occur, but I feel like this run is not like that initial case that the rule is trying to prevent and that the line should be somewhere in between this run and that hypothetical run.
Just like the optimisation rule, I know a longer run has more room to breathe in terms of frames lost to suboptimal inputs. However, where is the line drawn in that respect so that the TP Any% TAS which might lose a frame or two overall gets accepted but someone submitting the input file for a "Wouter Goes Bananas"-esque DK64 101% submission ( https://youtu.be/_FBGO6Lm6O8 ) gets rejected.
Personally, I feel like this submission lies on the TP Any% side of things and not the "Wouter Goes Bananas" side.
I understand the reasoning for the rule, since it would be undesirable to publish a movie that was faster on PAL purely because it saved 2m to text over NTSC but lost 1m50s to 50fps. Unless of course this hypothetical run then saved another 10s for PAL because of some PAL-only glitch, in which case it would provide something unique for PAL.
That I get, and hence I understand why the rule is in place.
My personal disagreement with "because this is on PAL, it should be rejected" is more because that initial disqualifier (losing time to 50fps) is so marginal (0.06s), especially in comparison to the time saved (0.8s).
I get that there has to be a line so that the initial case I mentioned doesn't occur, but I feel like this run is not like that initial case that the rule is trying to prevent and that the line should be somewhere in between this run and that hypothetical run.
It doesn't matter which version's run is marginally faster or slower. The PAL version just has to be either different enough or better to be allowed. Here's a good example of general preference: #5749: Chef_Stef's PSX Crash Bandicoot 2: Cortex Strikes Back in 36:06.78. The submission text explains why using the PAL version is reasonable on its own grounds.
Version Choice
I used the PAL (Europe) version because movement in that version is generally 5-20% faster (depending on the circumstances) which leads to a few version-exclusive tricks. It's also the version typically used in the speedrunning community. The PAL version does have longer loading times, including a few in-level loading pauses that aren't in NTSC (for example, at the end of level 4 and throughout levels 22 and 24). But overall the are enough benefits with the PAL version to make it the fastest option.
Note that speedrunners typically run the game on a PS2 Slim with faster load times, so RTA times aren't directly comparable to this TAS. This run on a PS2 Slim would likely be minutes faster.
PAL runs at roughly 50FPS, but the game only renders every other frame. With a few exceptions, the game only reads controller input on render frames. So in the discussion below, whenever I mention "frames" I'm talking about input frames, i.e. 25 per second, not the full PAL rate of 50FPS.
When instead of this, the 2 versions are nearly identical in TASable gameplay, we simply prefer the NTSC version.
theballaam96 wrote:
Just like the optimisation rule, I know a longer run has more room to breathe in terms of frames lost to suboptimal inputs. However, where is the line drawn in that respect so that the TP Any% TAS which might lose a frame or two overall gets accepted but someone submitting the input file for a "Wouter Goes Bananas"-esque DK64 101% submission ( https://youtu.be/_FBGO6Lm6O8 ) gets rejected.
Personally, I feel like this submission lies on the TP Any% side of things and not the "Wouter Goes Bananas" side.
I didn't understand this part at all.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
What I mean is that if one frame or two that could be saved is found by a judge when judging a long TAS, from what I have heard from others, the run is generally accepted even though it's not 100% optimal (unless there is some other factor that comes into play).
However, you would reject a RTA-style submission ("Wouter goes bananas" is just a hilariously bad run that was submitted to SDA) since it is clearly unoptimised, and proves as an example of what the optimisation rule intends to do. From my perspective, that intent is to ensure that runs that are submitted to the site are of high enough quality, but that the bar is at a level that doesn't exclude everything that is not 100% perfect with 0 frames lost in total. This is also highlighted in the judge guidelines ( http://tasvideos.org/JudgeGuidelines.html )
In a similar stance, I believe that the PAL rule definitely wants to rule out scenarios where you get that 2m timesave from text but 90% of that is lost to the 50fps, however I feel like this run isn't a case of what the rule should be getting rid of (see Ringrush's reply). Being strict with the rule gets rid of runs like this, as shown by the current decision, however if the optimisation rule is applied strictly (no frame losses whatsoever), then it would be hard to a 3D game published and would make people less likely to submit.
The TAS gains entertainment due to getting to the actual gameplay faster and loses 2-NTSC-framesworth of time (If a hypothetical NTSC TAS lost just 2 frames, it could be argued that this would be accepted, so what is the difference?)
Being strict with this ruling doesn't benefit any party and everyone loses (The TASer, TASVideos, The Audience).
To add to what RingRush has said, I find it hard to justify in myself to go through another month of TASing on NTSC in the near future just to produce the same run, but 0.74s+ slower because of cutscenes when I have other things to be getting on with (eg. 100%).
Does an NTSC "TAS" exist? Yes, but only in video form because I do not have the input file anymore, and even if I did have the file, I couldn't submit it to TASVideos because it's unoptimal. But I don't think I ever mentioned making another NTSC Any% TAS in the near future unless something gets found that makes NTSC faster
What I mean is that if one frame or two that could be saved is found by a judge when judging a long TAS, from what I have heard from others, the run is generally accepted even though it's not 100% optimal (unless there is some other factor that comes into play).
However, you would reject a RTA-style submission ("Wouter goes bananas" is just a hilariously bad run that was submitted to SDA) since it is clearly unoptimised, and proves as an example of what the optimisation rule intends to do. From my perspective, that intent is to ensure that runs that are submitted to the site are of high enough quality, but that the bar is at a level that doesn't exclude everything that is not 100% perfect with 0 frames lost in total. This is also highlighted in the judge guidelines ( http://tasvideos.org/JudgeGuidelines.html )
In a similar stance, I believe that the PAL rule definitely wants to rule out scenarios where you get that 2m timesave from text but 90% of that is lost to the 50fps, however I feel like this run isn't a case of what the rule should be getting rid of (see Ringrush's reply). Being strict with the rule gets rid of runs like this, as shown by the current decision, however if the optimisation rule is applied strictly (no frame losses whatsoever), then it would be hard to a 3D game published and would make people less likely to submit.
We've never had an optimization rule saying "if we can improve your run it's rejected", it's always been a matter of good enough to look superhuman. The judge role requires TASing experience exactly to allow distinguishing between good enough and not good enough. It still remains a matter of helping the author improve their skills, for example when we see that something is rejectable, we try to give useful hints and test things for the author to rely on.
In fact, the PAL version of the game also needs to be good enough to be acceptable. I think I provided enough examples of acceptable PAL versions in this thread and in the judgment. The problem here is that "good enough" is not the argument pro this version's movie. We kinda all agree that this version is the same in terms of actual gameplay that you get to see in an optimized movie, aside from the dialogs that we don't count. It's the same situation as between NTSC and PAL versions of Super Mario Bros.
The point pro this movie is "even though it's not any better or different than the NTSC version in terms of gameplay, let it be there until an NTSC run is made". One problem with that approach I covered in my previous post, but there's actually more. Since the game engine is very slightly different, how can we reliably compare optimality if there is a published PAL TAS, and an NTSC one gets submitted? Some differences in mechanics will be just a result of the version switch. But to properly obsolete movies we want to be sure new optimization techniques are applied. If we don't demand new optimization techniques, then we can't be sure the new movie is on the same (or higher) level of optimality until we try to reTAS it all. And if we demand new techniques, then we end up preferring the PAL version by default until those techniques are discovered, and they may never be found. Which, again contradicts the meaning of the rule.
theballaam96 wrote:
The TAS gains entertainment due to getting to the actual gameplay faster and loses 2-NTSC-framesworth of time (If a hypothetical NTSC TAS lost just 2 frames, it could be argued that this would be accepted, so what is the difference?)
Just like with PAL SMB, I don't think marginal difference in dialog skipping adds much entertainment value for the general audience, because it's not an automatic thing. There are certaingameplay features people usually expect to be showcased in a run to consider it entertaining. Those features may be different for different people, and of course some people get entertained by marginal timing differences (or even nuances you can't see in the movie at all). Yet the general audience's tastes still look for something more apparent and specific, like visibly creative gameplay. And I think jumping into a wall to end the game does feel rather creative indeed, which is why this movie's feedback was really positive. I just doubt it makes sense to compare entertainment value that comes from a few seconds of dialog skipping.
theballaam96 wrote:
Being strict with this ruling doesn't benefit any party and everyone loses (The TASer, TASVideos, The Audience).
To add to what RingRush has said, I find it hard to justify in myself to go through another month of TASing on NTSC in the near future just to produce the same run, but 0.74s+ slower because of cutscenes when I have other things to be getting on with (eg. 100%).
Does an NTSC "TAS" exist? Yes, but only in video form because I do not have the input file anymore, and even if I did have the file, I couldn't submit it to TASVideos because it's unoptimal. But I don't think I ever mentioned making another NTSC Any% TAS in the near future unless something gets found that makes NTSC faster
I did evaluate the overall opinion of the audience about version usage, and it was mostly against PAL, just like the rules are. We care about the author's motivation as well, but we can't make decisions only based on that if it doesn't align with the site's and the audience's takes. It would make things arbitrary and unpredictable on the long run. For example if we randomly bend or ignore rules, then the overall impression of unexpected outcome would damage the site much more than having to put into practice decisions that look unpleasant to some people. And in the case of those unpleasant decisions we still try to explain all the relevant details so it doesn't feel like arrogance on our part.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I don't buy that faster dialogue is even really an entertainment boost. Things like cutscene-free encodes aren't that uncommon around here, so faster dialogue is like a nothing in my view.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
Awesome TAS, Ballaam! Glad to see you finally submitting some of your work for publication. You get a resounding yes from me.
P.S. If the PAL region does end up getting this run rejected, I hope you are willing to jump through the additional hoops and put in the extra work needed to present this TAS on a slightly suboptimal version that provides no additional entertainment value. Would be a travesty if this TAS is never showed off because of something silly like that.
Just like the optimisation rule, I know a longer run has more room to breathe in terms of frames lost to suboptimal inputs. However, where is the line drawn in that respect so that the TP Any% TAS which might lose a frame or two overall gets accepted but someone submitting the input file for a "Wouter Goes Bananas"-esque DK64 101% submission ( https://youtu.be/_FBGO6Lm6O8 ) gets rejected.
Personally, I feel like this submission lies on the TP Any% side of things and not the "Wouter Goes Bananas" side.
TP runs on 60 Hz on all versions, so the same rule doesn't apply there.
Current project: Gex 3 any%
Paused: Gex 64 any%
There are no N64 emulators. Just SM64 emulators with hacky support for all the other games.
