Editor, Experienced Forum User, Published Author, Active player
(466)
Joined: 5/23/2006
Posts: 361
Location: Washington, United States
feos wrote:
This movie has some blank frames at the end, we usually don't leave those in because they give false impression about input length. While checking this I found that the very last input can end sooner too. Haven't tested earlier ones. Here's the movie.
http://tasvideos.org/userfiles/info/54530816263675334
Chef Stef, what do you think?
If you just want to trim the input I don't see any reason why not. I thought it'd be fine to end on last-hit since the time gap is small, but I don't care much either way. Not sure I care about trying to optimize input length, since it doesn't make a difference for last-hit timing, though I won't complain if you want to adjust things.
jlun2 wrote:
For the submission text, the "(link)" appears to not exist:
Thanks, I've fixed that. Forgot to actually link in the movie files.
Also is it correct to say the reason why some stages had a delayed start (10 for instance) was due to NPCs, or is it some other reason?
If by NPCs you mean the enemies, yeah, that's it. They are in fact the only reason that waiting to launch the ball makes a difference.
Great improvement btw. Are you planning to brute force like this for any other games?
Ferret Warlord wrote:
How tricky would it be to adapt this script to other Arkanoid like games?
No plans but I'm sure this kind of thing is useful on games other than Arkanoid. The main issue is writing the game simulation engine, since that obviously has to be done from scratch for each game. But the brute-forcing concept would certainly work on other things, it'd just take work to generalize it properly.
Can you please elaborate on this? Would be very interested in how the game does the angles.
It's pretty much like moozooh said. Since you asked for it, here's one of the movement tables:
It's essentially a precalculated table saying how the ball should move over multiple frames to simulate a smooth angle that's not one of the 8 basic ones (cardinal directions + diagonals).
Each row corresponds to (what I've been calling) a "speed stage", i.e. how fast the ball is generally moving, where the speed stage increases as blocks are destroyed. (There are deterministic rules for that but I'll skip the discussion here.)
The right section of the row is a set of vy-vx pairs that indicate how many pixels the ball should move that frame. 0, 0 entries are just padding and are unused. You'll notice that some rows have just one pair, while others have a varying sequence.
The four numbers on the left are metadata for the ball movement. The first value is simply the number of vy-vx pairs in the row; it represents the cycle length, or period, of movement the ball goes through. The second value is how many times the ball should move per frame; the game does fast movement this way (rather than just increasing the vy-vx numbers) so that collision detection still works properly, e.g. so the ball can't just completely phase through a block. The third value is how many frames to delay before moving the ball once, and only comes into play if you've slowed the ball with the Slow powerup. The final value is unused (probably just padding for the table).
Editor, Experienced Forum User, Published Author, Active player
(466)
Joined: 5/23/2006
Posts: 361
Location: Washington, United States
Feos, thanks for the comparison encode! Very interesting seeing the two side by side. One trend I noticed was that Baxter's TAS often had to spend a lot of time clearing the last few silver blocks, whereas the bot-generated run tended to get these as it went. Later in the game the silver blocks take a lot of hits and run up the score a lot for even more delays, so it seems the takeaway is to try and clear these sooner rather than later.
The comparison also makes it clear the boss strategy is faster because the ball is moving faster, which is because the bot sends it to the ceiling as soon as possible. The first time the ball hits the ceiling it gets an automatic boost in speed, if it hasn't already sped up from block-breaking.
Answering a few questions from the thread:
Baxter wrote:
Chef Stef wrote:
Note that this strategy is also 98 frames faster than the published warps TAS, which does aim for last-hit timing.
I wonder if I should make this improvement to the existing warps TAS. Or do you think other improvements are possible?
Discounting the demo glitch, the warps TAS is really straightforward so I don't think many other improvements are possible. It basically comes down to whether the warp powerups can be manipulated and collected any faster. The only thing I can think of is manipulating the score in a previous level to get a more favorable powerup manipulation in a later one. But overall things have been pretty well optimized by human TASers already. Then again, I thought the boss level wasn't improvable until I ran the bot on it, so who knows?
GJTASer2018 wrote:
I imagine that Chef Stef's bot could be fairly easily (by anyone well-versed in Lua scripting) tweaked to prioritize getting a warp powerup instead of a multiball. Then once you get through the demo glitch as in the current warps submission, the bot is set running. The task would both be easier (fewer levels to check and less stuff to keep track of in each level) and harder (RNG manipulation to get a warp powerup in the first place) than the warpless run.
It's worth noting that I didn't replicate anything into the game engine except the bare minimum needed to make this TAS, so no title screen, demo, or warp powerup (or any powerup besides 3-ball, for that matter). It wouldn't be that bad to add logic for those things, but it's effort I didn't spend.
Side note, I intend to release the source code for the engine + bot, I just haven't found the time yet to make it happen. It's actually a standalone C++ program, not a Lua script.
nicos wrote:
also i found surprising to learn how much bruteforcing was involved when it's basicaly a big geometry formula for each shot...
Yeah, at the beginning I thought the same, that I could just calculate angles or something and simulate it that way. But there's a lot of annoying stuff in the game to prevent that. For starters, there aren't any subpixels in the game, everything is done with whole pixels and lookup tables to "fake" the angled movement of the ball, so the math immediately breaks down. Then there's rules baked into the game about how the ball snaps to a brick position when it hits it, enemy behavior, bumping the ball with the paddle, timing changes when you collect the powerup on different frames, and so on. In the end simulating it all was the only way to make it happen.
Editor, Experienced Forum User, Published Author, Active player
(466)
Joined: 5/23/2006
Posts: 361
Location: Washington, United States
The attention to detail and focus on entertainment in this TAS is fantastic and I'm extremely impressed new improvements are even still possible at this point. Lots of great moments in the run, but my favorites were 3-3 and the endings of 7-2 and 8-2. Yes vote, and hope to see this in Stars once published.
Looking forward to seeing your next project. Maybe try your hand at some other games too!
Editor, Experienced Forum User, Published Author, Active player
(466)
Joined: 5/23/2006
Posts: 361
Location: Washington, United States
Voting yes, I liked this run a lot! Amazed that there are still new things to be seen in this game (the music bug at the end of 5-2, glitching through the blocks in 8-2). Nice job on entertainment as well, it's one of the key things a TAS can offer over a realtime run. Really great to see new TAS concepts even after this long.
Editor, Experienced Forum User, Published Author, Active player
(466)
Joined: 5/23/2006
Posts: 361
Location: Washington, United States
Speedrunning is definitely a skill, but it can be a different skill compared to playing the game normally. I wonder if that's the point being made. If a game has a lot of skips I could easily see a speedrunner being really good at their run, without being as good at the regular gameplay. Or if the game has multiple modes and you're only speedrunning one (thinking of, say, Splatoon with its single-player campaign, most people would not call that the main game but it's the one that gets speedruns). But usually being skilled in one means being skilled at the other.
Editor, Experienced Forum User, Published Author, Active player
(466)
Joined: 5/23/2006
Posts: 361
Location: Washington, United States
I dug out my Genesis and Aladdin cartridge to give this a shot, sure enough it totally works! I'm going to keep this in my back pocket as a party trick.
Now, as a TASVideos submission... I don't see much hope for publication. The content is trivial to reproduce real-time, and the actual game completion time is super long (input time isn't really the deciding factor for movies here). 100+ minutes of demo scenes isn't exactly entertaining either. I like the concept but don't think it'd make for a good publication. Nice job finding the glitch, though.
Editor, Experienced Forum User, Published Author, Active player
(466)
Joined: 5/23/2006
Posts: 361
Location: Washington, United States
For those who aren't aware, I have submitted the completed TAS.
I have no idea if I'll do anything more with Crash 2 after this, so here's the set of Lua scripts I wrote for the game. I based the initial memory-watch code on Pirohiko's script but implemented a bunch of other useful things like color-coded movement indicators, level hitbox maps, and a brute force script for optimizing slide-spins.
Examples:
A few caveats:
* The UI layouts are tuned for BizHawk's pixel pro mode (which I used to get more screen real estate) so if you're using another mode some tweaking will be needed.
* A few things won't work for the NTSC version since I never got around to finding equivalent memory addresses. I have some TODOs marked in the code for that.
* Running with level maps on will slow the emulator down a lot because I'm drawing so many things to the screen. For frame-advance-TASing this isn't a problem but it'll get in the way during playback and testing. I suspect some optimization is possible but I didn't figure anything out.
Editor, Experienced Forum User, Published Author, Active player
(466)
Joined: 5/23/2006
Posts: 361
Location: Washington, United States
I discovered the tunic glitch in Link's Awakening DX. I'm not aware of it being used in any runs (the setup is too slow) but it's the reason I got into LADX TASing and one of my earliest contributions to the site.
I also discovered the barrel-reuse glitch for boss fights in GBA Mario vs. Donkey Kong. I was pretty happy about that since it saves over a minute throughout the game. Some of the stuff Kiwisauce and I did for Super Scribblenauts was also completely new and pretty neat, like getting a perfect clear in the bingo levels by exploiting object containers.
I've found a bunch of other minor glitches in games but not much that really changes the speedrunning / TASing scene. I tend to find new applications of known glitches rather than discovering new ones myself.
Editor, Experienced Forum User, Published Author, Active player
(466)
Joined: 5/23/2006
Posts: 361
Location: Washington, United States
I like them both, personally.
Warepire had a suggestion earlier in the thread which may be helpful:
Warepire wrote:
We need something Windows icon sized, preferably all the currently supported icon sizes would be good (Windows does terrible scaling). There are however some debate over what it should contain. Personally I think we should go with a theme that makes it clear that it's a debugger (which is what Hourglass really is), and that it has save-state features etc.
Maybe we should start a forum poll once there are enough submissions to vote on?
Editor, Experienced Forum User, Published Author, Active player
(466)
Joined: 5/23/2006
Posts: 361
Location: Washington, United States
Warp room 4 done:
Link to videoBizHawk movie file
Level 16 uses a skip found by Gunnaromg to go out of bounds in the second hot pipe section. This is great because otherwise I'd be forced to use the grates for the last bit. For comparison, here's my best attempt without going out of bounds (new content around 00:28). The skip saves about 4 seconds overall.
I was also very happy with the boss fight, where a combination of the RTA strat and some new tactics of my own led to a lot of time saved. The second-phase strat is very tight even with TAS tools and might be frame perfect. Each phase has a frame rule so I didn't invest a lot of effort in alternate ideas once I found one that worked.
Edit: Replaced with an improved version that saves about 3 seconds in level 16 from hitting the exit trigger sooner after the hang grate section. Original version for reference. Thanks to ferianjay for the new strat.
Editor, Experienced Forum User, Published Author, Active player
(466)
Joined: 5/23/2006
Posts: 361
Location: Washington, United States
You mean at the very end of the death route? There's an invisible wall along that section, so it's not possible. Luckily the gem is still avoidable but yeah, not as clean looking as I'd like.
Editor, Experienced Forum User, Published Author, Active player
(466)
Joined: 5/23/2006
Posts: 361
Location: Washington, United States
New WIP, covering levels 20, 19, and 18 (going through the warp room backwards is the better mask route in this case).
Link to videoBizHawk movie file
In level 18 I also experimented with taking the normal route instead of the "death" route. There are a couple of minor skips I found that make the normal route more competitive in a TAS. Unfortunately it was 22 frames slower so I couldn't include it in the run, but here's what it looks like (new route starts around 00:35):
Link to video
Editor, Experienced Forum User, Published Author, Active player
(466)
Joined: 5/23/2006
Posts: 361
Location: Washington, United States
Arc wrote:
2. A movie that hasn't been published yet; something that would debut at the event.
This is a really interesting idea. What if the TASBlock was entirely new TASes that haven't been shown anywhere yet? People could volunteer runs that are due to be finished within, say, the next two months, elect to delay submission to TASVideos, and show them for the first time at GDQ instead. We get the surprise factor from previous GDQs but with something much more reasonable and representative of typical TASVideos content.
If we don't go for that, I'll propose showing the recent Smash Bros Break the Targets / Board the Platforms run. It's in the same vein as Monkey Ball where it showcases the latest and greatest tricks in one place, taken to the next level with TAS tools.
Editor, Experienced Forum User, Published Author, Active player
(466)
Joined: 5/23/2006
Posts: 361
Location: Washington, United States
jlun2 wrote:
Is there any way to truncate a movie from current frame "easily"?
What about, save a state, toggle off read-only, load the state? That'll truncate without having to mess with the input file. I use this method all the time.
Editor, Experienced Forum User, Published Author, Active player
(466)
Joined: 5/23/2006
Posts: 361
Location: Washington, United States
Nicely done. I was thinking the zip-zagging would get repetitive but level order was actually great at pacing the zip levels against the non-zip levels. It's a good thing Crash 3 has so many gimmick levels - in Crash 2 the glitch would get tedious to watch very fast (one of the reasons I'm avoiding it in my run).
I for one am glad you kept the sound effects on. Some of the zipping levels would have been very boring without effects.
I noticed that in some levels (like 1 and 6) you wait around until the portal goes away, while in others (like 9) you immediately start charging a zip. Do some levels prevent you from starting it early?
Some levels lag a lot while zipping. Is there a difference in in-level load times between PAL and NTSC that could make a difference? Crash 2 PAL is laggier than NTSC, just curious if the same is true for Crash 3.
A few specific things I enjoyed: Bouncing off the cars in level 14 to keep your momentum going, phasing through closed doors in tomb levels, and kill-trading in the flying levels.
Overall a good watch, voting yes!
Editor, Experienced Forum User, Published Author, Active player
(466)
Joined: 5/23/2006
Posts: 361
Location: Washington, United States
I've always thought Mario was an implied mascot. He's in the TASVideos logo and shows up in the title bar on the main site.
Totally agree about TASBot. Very appropriate for the site theme, and already already featured prominently at GDQ events and such.
dwangoAC wrote:
I also like this little 48x48 guy (he's almost a bit too small, but he's cute and was made by endrift):
Editor, Experienced Forum User, Published Author, Active player
(466)
Joined: 5/23/2006
Posts: 361
Location: Washington, United States
That's right, the game is pretty forgiving about what you do at the end of the boss fight. For this boss, starting the victory dance really high in the air loses one frame but everything else starts on the same frame.
A few caveats:
* The UI layouts are tuned for BizHawk's pixel pro mode (which I used to get more screen real estate) so if you're using another mode some tweaking will be needed.
* A few things won't work for the NTSC version since I never got around to finding equivalent memory addresses. I have some TODOs marked in the code for that.
* Running with level maps on will slow the emulator down a lot because I'm drawing so many things to the screen. For frame-advance-TASing this isn't a problem but it'll get in the way during playback and testing. I suspect some optimization is possible but I didn't figure anything out.