Streemerz (as known as SUPERSTRENGTHEMERGENCYSQUAD-ZETA) is a flash game made for the "ACTION 53 OWNS" competition by Arthur Lee, later Faux Game Co. ported it to NES. You can download the lastest ROM from their website.
This speedrun completes the game's "Superb Joe mode" which contains a series of "hard" levels and must be completed within 5 minutes. The world record is 55.34 sec EDIT:(Only found video for 1 minute 2~5 secs runs... "what a coincidence"). which can be seen here by ineb_tfm aka Alan. This run completes it in 45.89 seconds thanks to extreme positioning and abusing the rules/physics of the game.
The game is pretty basic: You can shoot a grappling hook or go left and right (A, L, R). Some blocks grappable, some don't. 1 hit and die.
Game objectives
Emulator used: FCEUX 2.2.0, uses palflag 0 (NTSC)
Aims for fastest possible in-game time
Entertains without losing a frame
Some comments, screen by screen, some of them is used everywhere
[S1)For whatever reason, the sound of grappling hook doesn't works.
[S1)Not afraid of fire
[S1)Grappling for 1 frame and cancelling it gives a huge vertical boost (look at those incredible corner boosts)
[S2)Removing lag frames by targeting different spots with grappling hook
[S2)This route is faster than going left
[S3)Starting the crazy grapplings
[S4)Try to not blink
[S5)Grappling the lower one removes a lag frame
[S6)Close call?
[S7)One of the most impossible part of the run, I doubt that anyone could reproduce it in real time because of turning 2 frames right and delaying the 1 of the grappling with 1 frame while tossing out every possible grapplings.
[S8)no blinking
[S9)The second impossible part, nearly the same complexity as the earlier mentioned. Crazy grapplings anyone?
[S10)Third impossible part. At least this can be "nearly" achieved the same way in real time but not that fast.
[S11)Fourth impossible in the terms of making it in a realtime. Just holding a grapp for 1 frame longer and you get 3-4 lagframes.
[S12)no blinking still
[S13)nothing
Miscellaneous
Thanks for Mr. Podunkian for creating the flash game and Faux Game for porting it to NES. See you until my next TAS =)
Thank you RGamma for the encode =)
I recommend to watch the fastest unassisted run to understand the comments I wrote if anyone interested in those impossible parts:
Link to video
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
......wait, someone made a good game based on action52? what.
this is good. I'll vote yes.
My first language is not English, so please excuse myself if I write something wrong. I'll do my best do write as cleary as I can, so cope with me here =)
(ﾉಥ益ಥ）ﾉ
I'm honored that you used my video for comparison. :) I hope to see a main game TAS soon!
Also, Ineb_tfm has a 55.34 in-game time for this: http://vvcap.net/db/-MzL4V8JzXBQvCz5rjk-.png
He's probably the most technical player at the moment.
An interesting homebrew, although I definitely didn't expect this TAS to take 32975 rerecords. Don't know about this game, but if I ever found myself spending 33K rerecords for a 54-second movie, I would consider such action far more obsessive than I could ever have imagined.
Also, shouldn't the game title be "Streemerz: Super Strength Emergency Squad Zeta" instead of just "Streemerz"?
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
FractalFusion: see other MESHUGGAH's submissions' rerecords. He's a geek.
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.
That was a really sweet run! Crazy fast. I thought my 55 was good HEH. Some of those tricks aren't impossible for RTA though, just can't do them quite as fast. Here's the link to it for reference: http://www.twitch.tv/ineb_tfm/c/1948901 (beware pugs everywhere)
I'm honored that you used my video for comparison. :) I hope to see a main game TAS soon!
Also, Ineb_tfm has a 55.34 in-game time for this: http://vvcap.net/db/-MzL4V8JzXBQvCz5rjk-.png
He's probably the most technical player at the moment.
Thanks for the informations, I couldn't see any proof of his record. I think I should change the submission text...
FractalFusion wrote:
didn't expect this TAS to take 32975 rerecords...
I've made 76 fm3s and fm2s file through out making this TAS. Notice that I "drawed" the whole TAS in TASEditor. The reason I did this because the game has a "5 frame" rule (00, 01, 02, 03, 04, LAG) and I had to use markers to see the difference between positions that I really improved a frame. Also these markers had to be placed on specific frames because the game uses a simply "player on the screen" position that depends on cam offset. Even the crazy grapplins is dependent on this position. So just because I'm faster somewhere, it won't mean I can delete 1 frame. And it was easier to draw them instantly instead making some wizardry hex editing.
Also I think there was 5 spots total where I had to be slower to make the game faster. All in all, most of the rerecords comes from drawing by hand and finding improvements/routechecks so many times. If I had to make a raw guess, I would say it's completed in 20 hours (through 6 days). The "time attack" mode would be completed in the same time (because now I know all the glitches) but want to wait the results of this submission.
ineb_tfm: I'm emberassed. When did you upload that video? Thanks for linking and sorry for writing my sentence in the submission text sounding like... you know... by the way, 0:57 in your video: I HAD THE VERY SAME REACTION =D
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
An interesting homebrew, although I definitely didn't expect this TAS to take 32975 rerecords. Don't know about this game, but if I ever found myself spending 33K rerecords for a 54-second movie, I would consider such action far more obsessive than I could ever have imagined.
You didn't really check TAS Editor, did you?
33K rerecords sounds like a lot of work in traditional TASing, but in the nonlinear TASing it's not as painful, and in the semiautomatic TASing it's like a breeze. The whole pace of TASing is much faster here, so you can make more tests within any given minute, without noticing how you actually made hundreds of rerecords.
Also, TAS Editor only counts "real rerecords" (and doesn't increment the rerecord counter when e.g. you rewind or load a savestate containing the same movie data).
Old rerecording emulators usually count both "real" rerecords and "technical" loads of savestates (even if the movie data didn't change in the process of loading the savestate), so in the traditional TASing you always have a bit of fake rerecords added to the total number (e.g. if your finger slips and presses a single loadstate hotkey twice in a row, you'll get 2 rerecords in traditional TASing but 1 rerecord in TAS Editor).
MESHUGGAH wrote:
All in all, most of the rerecords comes from drawing by hand and finding improvements/routechecks so many times.
Drawing Input by hand actually decreases the expenditure of rerecords, i.e. to achieve the same result you would spend more rerecords (and much more work hours) in the traditional method.
So, all the rerecords in the movie come from finding improvements/routechecks so many times. You've really tested the hell out of this game, and the run shows. I voted Yes.
MESHUGGAH wrote:
I've made 76 fm3s and fm2s file through out making this TAS.
All in all, most of the rerecords comes from drawing by hand and finding improvements/routechecks so many times.
Drawing Input by hand actually decreases the expenditure of rerecords, i.e. to achieve the same result you would spend more rerecords (and much more work hours) in the traditional method.
So, all the rerecords in the movie come from finding improvements/routechecks so many times. You've really tested the hell out of this game, and the run shows. I voted Yes.
I think I didn't explained it well. This time I TASed the game somewhat differently: I made the "basics" of a route and optimize it everytime I could, and when I had to make an improvement that will only "shows up" later (for example grappling at a frame and see it will catch the wall) I made simultaneous use of frame advancing and drawing the input in the same time. This means, that I get as many rerecords as I gave input to it. This basiaclly means that some rerecords were'nt actually rerecords but "records". And the "consecutive rerecording" thing is checked. But I really made a lot of rerecords for sure.
AnS wrote:
76 fm3s? What for? Isn't 1 fm3 enough?
I have to admit, that I'm still didn't check the branching thing, mostly because I'm not 100% sure that it won't get corrupted. I had 3 random bugs during this run, and didn't wanted to miss an improvement (every frame is important for me =) ).
One of the random bug is actually because of this technique I used (holding the spacebar (bound to frame advance) while holding mouse1 to draw in TASEdtor) and for whatever reason (couldn't replicate it), FCEUX tried to frame advance while I was in "windows resize" mode on FCEUX. What I saw was intense blinking and couldn't do anything with it (force close).
The second one is maybe has something to do with the ~300MB files, is sometimes corrupts at saving the FM3 (non-compact). When this happens, I just hex edit the part until the end of the input section.
The third one is maybe ROM dependent and maybe has something to do with greenzones. I first TASed the streemerz v01 and when I replaced the ROM header (dialog came up in TASEditor) and saved it (non-compact), the greenzones were not updated. For example, I watch the run for the first 500 frames, but if I just click on the first few frames, it will erronously loads up an invalid memory state (I think it just starts from the beginning, like I was inputted a reset which I didn't included or available in the input file).
So the reason of multiple files is 1. check the difference (advancing through a level faster doesn't means I get an improvement overally). 2. make sure to have my records.
Oh, and the games name is STREEMERZ. I'm pretty sure about that, but I wanted to avoid all caps..... MESHUGGAH'S STREEMERZ would look a bit strange.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
I think I didn't explained it well. This time I TASed the game somewhat differently: I made the "basics" of a route and optimize it everytime I could, and when I had to make an improvement that will only "shows up" later (for example grappling at a frame and see it will catch the wall) I made simultaneous use of frame advancing and drawing the input in the same time.
I'm not sure I understand this method... Could you record a video capture with an example how you do it? You can record desktop using CamStudio. Maybe you've seen how feos recorded his TASing sessions.
MESHUGGAH wrote:
This means, that I get as many rerecords as I gave input to it. This basiaclly means that some rerecords were'nt actually rerecords but "records".
This is not possible. Let's see.
"Rerecording" is when you first watch a future event and then change the Input that leads to this event (this doesn't necessarily change the event itself, but still attempts to change the known future).
So, for example, if you frame advanced (emulated the game, greenzoned the Piano Roll) up to the frame 000200 and then change Input of the frame 000199, the rerecord counter will increase by 1, and the state of the frame 000200 may be different now. But if you advanced up to the frame 000200 and you change Input at the frame 000200 (or 000201-etc), then rerecord counter does not increase, because you haven't seen the state of the game after the frame 000200, so you've edited the Input blindly, and this is a "recording".
So, it does not matter if you're using Frame Advance simultaneously with drawing or you're using "Auto-restore last position" or any other way of advancing the game emulation. What matters is, are you drawing the Input inside the Greenzone or outside it. If you're frame advancing and drawing the Input above the Playback cursor then you're effectively rerecording (and in the traditional TASing you would need to load an old savestate in order to access the frame above the current frame). But if you're frame advancing and drawing the Input at the Playback cursor (or below it) then you're recording, and the rerecords counter will not increase - no wrong statistics!
MESHUGGAH wrote:
And the "consecutive rerecording" thing is checked.
You mean the "Combine consecutive Recordings/Draws" option? It doesn't affect rerecords counter, it only makes History log less bloated.
MESHUGGAH wrote:
I have to admit, that I'm still didn't check the branching thing, mostly because I'm not 100% sure that it won't get corrupted. I had 3 random bugs during this run, and didn't wanted to miss an improvement (every frame is important for me =) ).
You mean, in case of emulator crash? Then just configure the autosave feature in the Config menu! Being afraid to use advanced features you're losing more time than you would lose in case of a potential crash.
Built-in branching is more convenient than having dozens of project files. You switch between branches instantly, and you get nice graph of relations between all branches, etc.
MESHUGGAH wrote:
One of the random bug is actually because of this technique I used (holding the spacebar (bound to frame advance) while holding mouse1 to draw in TASEdtor) and for whatever reason (couldn't replicate it), FCEUX tried to frame advance while I was in "windows resize" mode on FCEUX. What I saw was intense blinking and couldn't do anything with it (force close).
If it's what I think it is, then this bug was fixed recently. Use the latest SVN build: http://fceux.com/zipMESHUGGAH wrote:
The second one is maybe has something to do with the ~300MB files, is sometimes corrupts at saving the FM3 (non-compact). When this happens, I just hex edit the part until the end of the input section.
Oh yes, the bug with project saving while unpaused... fixed 2 months ago, see 2.2.1-interim.
MESHUGGAH wrote:
The third one is maybe ROM dependent and maybe has something to do with greenzones. I first TASed the streemerz v01 and when I replaced the ROM header (dialog came up in TASEditor) and saved it (non-compact), the greenzones were not updated. For example, I watch the run for the first 500 frames, but if I just click on the first few frames, it will erronously loads up an invalid memory state (I think it just starts from the beginning, like I was inputted a reset which I didn't included or available in the input file).
This is not quite a bug. Since you've essentially changed the game (not just the name of the ROM), you should have created a new fm3 project (File->New, and check the "Copy current Input/Markers" checkbox) instead of just fixing the ROM name and trying to apply the old fm3 to the new ROM.
MESHUGGAH wrote:
So the reason of multiple files is 1. check the difference (advancing through a level faster doesn't means I get an improvement overally).
This is exactly what Branches are made for! You create a playthrough for a level, save it into Bookmark 1, then make another playthrough and save into Bookmark 2, and now you can switch between two movies instantly, instead of reloading two FM3s. To check the difference, sometimes it's not enough to just compare frame number (maybe in the first playthrough the frame number is less, but subpixels are worse), so you'll need to switch between the two playthroughs several times (back and forth) - this is when you understand the power of Branches.
And I'm not even speaking about more complex situations, where some branches may have sub-branches and stuff.
MESHUGGAH wrote:
holding the spacebar (bound to frame advance) while holding mouse1 to draw in TASEdtor
I see, you're using one hand for editing and another hand for replaying. This is so 2011-ish! :D Try to use the mouse wheel (while holding the right mouse button) to frame advance, so you'll be editing and replaying the movie with one hand.
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'm not sure I understand this method... Could you record a video capture with an example how you do it? You can record desktop using CamStudio. Maybe you've seen how feos recorded his TASing sessions.
I uploaded here: http://videobam.com/imvIO. Microphone was muted by accident. Some comments: this uses the latest subversion 2853. Frame advance binded for space. I get a random bug regarding the follow cursor @ ~0:41. If it wasn't clearly visible, I will make another version with microphone and maybe doing it a little bit slowly to understand better. edit: and better encode and find a better video hosting site that doesn't gives random ads and errors.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Hey, that's rather awesome demonstration of the nonlinear TASing method! Feos' videos mostly showcase the semiautomatic method, which I consider to be more limited, but more fast-paced (result-oriented, so to say), but you seem to handle nonlinear as quickly, so I'm glad to see that nonlinear method can be fast too.
On topic of rerecords, yes, here you're editing frames after they were emulated, so you're essentially rerecording (in the traditional TASing you would need to load a savestate in order to edit previous frame, so rerecord counter would increment).
Even in cases when there was no previous buttonpresses (and by holding FrameAdvance you emulated blank frames), this is still considered an Input (all buttons released), so when you begin filling the blank space with new buttonpresses, the rerecords counter increments, because you've already seen what happens in the game when all buttons are released, and now you're changing this outcome (rerecording).
MESHUGGAH wrote:
I get a random bug regarding the follow cursor @ ~0:41.
That's not a bug, but a new behavior of the "Follow cursor" checkbox. Now the Piano Roll doesn't follow Playback while it is seeking. If you don't like this innovation in TASEditor 1.01, we should discuss it thoroughly (better in PM, not in this topic).
MESHUGGAH wrote:
If it wasn't clearly visible, I will make another version with microphone and maybe doing it a little bit slowly to understand better. edit: and better encode and find a better video hosting site that doesn't gives random ads and errors.
If you have time, please record such a video, not just for me, but for newbie TASers too. But better upload it to Youtube. Microphone comments would be great addition as well!
ineb_tfm: I'm emberassed. When did you upload that video? Thanks for linking and sorry for writing my sentence in the submission text sounding like... you know... by the way, 0:57 in your video: I HAD THE VERY SAME REACTION =D
I got that time on the 18th, but hadn't highlighted it until last night. And yeah, I was so happy. Was probably like 60-90 min of resets before I got it lol
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
MESHUGGAH, break the line after quote, lol. It's hard to read.
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.
And I'm not even speaking about more complex situations, where some branches may have sub-branches and stuff.
