Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
I do like the game, but I don't like the rapid blinking at all, unfortunately, so I couldn't make it through the encode. Might be good to have a warning for that.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
I read through this discussion a while ago, and I just today came across a submission that appears to have been rejected purely because the sound effects couldn't be captured properly in the encode: #5317: ThunderAxe31's Windows Unknown Game in 00:59.42. I'm not sure if that was due to an issue with how Hourglass encodes, or if Hourglass just didn't support the sound effects for this game.
But I'm sort of unhappy if runs like this can't be accepted, although I guess that might be a separate discussion of where we draw the line for emulation accuracy.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
This game exists and was created in 2023? Wild.
The TAS is slow in parts, but the explanations for the slowdowns make sense. Definitely a fun short watch.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
With losviken's permission, I've recreated his movie from this video and resynced it to 2.9.1.
Movies: recreation (BizHawk 1.11.7), recreation resync (BizHawk 2.9.1)
I created this for time comparison. My first WIP lost time, but my current WIP is notably ahead in each level. Some of the levels were accidentally outdated, but in a few cases, losviken's strategies inspired me and showed me possibilities that would have been difficult to find otherwise.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
My WIP movie(s): WIP 001 (8 June 2023, 24:18.07), WIP 002 (1 July 2023, 21:28.50), #8442: RetroEdit's GBA Shrek 2 in 21:15.53 (17 July 2023)
I recently resurrected this project I started in 2020. My current WIP is several minutes faster than the real time any% world record of 28:42 (leaderboard).
With my WIP 002, this is pretty close to complete, but I still have a few seconds of potential time save (maybe less than a second) Turns out it was more than 12 seconds. See an up-to-date video at the submission link.
Here's a time breakdown of WIP 002. InLevel measures starting with the first dialogue-skip Start press in the level and ending with the final dialogue-skip Start press. Unfortunately, I recently discovered that mGBA is about 17.9 seconds faster than real console, primarily due to having notably less lag in some levels, so I'm going to investigate it a bit. The Retimed column shows an estimate of what the time spent within each level would be on real console.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Update: I updated this post on 8 June, 2023. I've indicated additions using the word 'Update' underlined, and deletions using strikethroughIntro
I have uploaded two new movie files now: User movie #638214192658269839 and User movie #638214192973773572. The first one reaches 1000 points, while the second one additionally completes parachute after reaching 1000 points; for individual optimization, they diverge slightly. Either way, a clear improvement over the submission of at least 00:25.66. Earlier I mentioned I improved it by 00:33.06, but that is based on a misunderstanding of game mechanics and is only comparing when 1000pts was reached.
Difficulty variables
I was looking at the difficulty variables Fortranm found (0x0F0FC4, 0x0F188C, 0x0F188D; each 1 byte values in Main RAM), and I wanted to document how their values correlated with the score, since it's relevant for determining when this movie is complete:
Goal choice revisitedUpdate: The differences between ending with parachute and ending at 1000 points are somewhat rendered moot by Fortranm's latest movie, which ends the movie at parachute and reaches 1000 points just as the parachute section ends.
At the risk of overexplaining or repeating myself, I'd like to briefly elaborate on why I personally prefer the 1000 point milestone as the movie's endpoint. From the relevant rules:
Movie Rules wrote:
If there's no clear ending, end after completing the first full game loop. However you may play further and end after any of the following:
[...]
The loop with the hardest in-game difficulty (enemy speed, AI, etc.) is completed.
For me, I see the game looping in difficulty every 100 points, gradually speeding up until the next multiple of 100 is reached, and then advancing to a slightly more difficult loop. Under this interpretation, the game would have its most difficult loop between 900 and 1000 points, and reaching 1000 points would be the end of that loop. I like this because it fits naturally within the logic of most Game & Watch games that I'm aware of.
There is some precedent we can look at: #7340: Fortranm's DSi Game & Watch: Donkey Kong Jr. in 03:49.80 specifically the "Ending" section of the judgement. In this movie, a final round of fully unlocking all four parts Donkey Kong's cage was completed as the endpoint of the movie.
feos wrote:
It is correct that when aiming for maxing out the difficulty in a game without an ending, one has to actually complete the most difficulty loop. We don't really care about how the score is displayed at that time, especially when the internal counter keeps going after the visible counter has looped back to 0. How one decides to time the ending of the movie is probably not critical, especially when the exact point when the loop is considered beaten has to be defined by humans.
I can understand the other argument. This game does clearly alternate between octopus and parachute in distinct cycles. Fortranm's movie goes into parachute an extra time to complete the parachute component after the difficulty variables have theoretically reached their respective maximums.
However, the thing is, each parachute round is not necessarily more and more difficult, because when the round occurs doesn't align with score milestones (it is indirectly affected by the score, but I don't entirely understand the alternation mechanic). Each interval of 100 points is more difficult, based on those difficulty variables.
Game mechanics
I also thought there were a few other things that would be useful to know.
Here are the scoring mechanics to my understanding:
- 1 point from catching parachuters
- 1-2 points from grabbing treasure (not sure how the game decides which to award: sometimes it seems to alternate between 1 and 2?)
- 3 points for reemerging from octopus into parachute
- Update: 10 points per parachute after the first round (doled out one every 8 frames), as long as you've grabbed a sufficient number of treasure in the prior octopus round. With the quick grab, we always manage to grab enough. My guess is that a minimum of 15 treasure is required to reach +10.
- At the beginning of each parachute section, there is a possibility for bonus points. After the first parachuter is caught, the game awards 1 extra bonus point every 8 frames for the amount of times octopus treasure was grabbed since the last time the player was on the surface.Update: My understanding was inaccurate due to an oversight on my part; it's some kind of multiplier for number of parachuters caught. So I want to catch more parachutes, which is the exact opposite of what I was doing (intentionally despawning them).
Given these mechanics, my basic strategy was as follows: finish parachute sections quickly and try to avoid too many stragglers. Because every time you go up to the surface, the octopus bonus point counter will reset, meaning you're going to be penalized later on. At least in my testing, the three bonus points, especially late into an octopus section, do not seem to outweigh the loss of future points, even in cases where going to the surface wouldn't lose any time because tentacles block the treasure chest.Update: In Fortranm's latest movie, parachutes are maximized as far as is possible without automated RNG manipulation, which seems to be the optimal strategy, since each parachute after the first round gives 10 points.
There's definitely potential future improvements with more game knowledge. I even found a way to score a single extra point using the +3 bonus mechanic earlier in the movie, but it would require redoing the whole movie from scratch, and this is not really appealing to me at the moment without better tools for automating the process.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Okay, I spent a few hours and decided to finish my proof-of-concept: updated movie. I saved at least 00:33.06. Not quite as significant as the theoretical 1/3 reduction I claimed earlier, because the gains started to slow down in the second half of the movie. There were some frustratingly close missed cycles that I might look into.
It follows the same ruleset as this movie, though it also subverts it somewhat. The movie technically ends with a final "cycle" of parachute, but the cycle is trivial (no parachutes fall) and merely serves to give the final +3 bonus to reach 1000 points before eventually forcing the player back into Octopus.Unfortunately, I just realized this doesn't quite follow the same goal. It enters parachute at the end, but it's really during the buffer zone where parachute is still accessible after entering octopus.
I did not include unnecessary rhythmic and high-speed movement movements because it made it more straightforward for me to construct the movie. They could certainly be added, but I did not think the entertainment gain was significant compared to the time it would take me to add them.
There are a few improvements I'll probably look into over the next few days: probably mainly the +3(?) bonus points after emerging from Octopus, but also possibly the initial RNG. As for the parachute spawn manipulation, I think I've basically figured out how it works: often parachutes will not spawn where the boat is positioned, so strategically eliminating or altering certain parachutes (intentionally or unintentionally) can speed up or slow down a cycle. Parachutes can be forced to spawn if there are too few of them on-screen.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Review: I noticed ViGadeomes has claimed this, but I thought I might have some useful insight, so I decided to do a review.
Background
I've spent a significant amount of time playing around with and TASing games in the Game & Watch series, and I'm rather fond of the unique puzzles they present. I'm particularly knowledgeable about the games in the first Game & Watch Gallery, which include Octopus. One of the most relevant features of most Game & Watch games is how the score affects game speed: game speed will increase as the score approaches a multiple of 100, and then reset to a new minimum when that multiple is reached, usually higher than the previous cycle's starting point.
Game & goal choice
The game choice here is good, as a game unique to this collection. The Game & Watch Collection games have no overall progression or connection between subgames, in contrast with the Game & Watch Gallery series.
I'm a bit uncertain whether an additional cycle of Parachute is necessary after this milestone is reached. I would personally be inclined to default to the 1000-point threshold as the more natural endpoint as the point where the difficulty stops increasing. I can understand the argument that this game has discrete loops of parachute and octopus, and the rules do say "[you may end after] the loop with the hardest in-game difficulty (enemy speed, AI, etc.) is completed", but the score-based loops are a more intuitive ending point to me.
Optimization
For clarity, I am referencing the updated movie file in the forum post above mine. On the surface, this movie seemed pretty good to me. I was surprised at how short the video is; Game & Watch games vary in length, and some take much longer to reach 1000 points.
However, when I began looking at the Octopus sections, I found significant optimization flaws. Specifically, this submission is missing the fastest treasure grabbing technique, which is to cancel the treasure grabbing animation early by moving left and then back right to initiate a new treasure grab; this is not always possible because of tentacle positioning, but it is often possible. This is not even a TAS-only strategy either; it's very viable in real-time, though you have to adjust when you move based on the game's current speed, which is in turn based on the score.
To understand this technique better, I made a proof-of-concept movie that reached 200 points. Comparing this movie to the submission:
At frame 3826 -- original score: 74, new score: 100
At frame 4065 -- original score: 100, new score: 133
At frame 4920 -- original score: 138, new score: 200
These sorts of comparisons aren't always useful with marginal score differences in Game & Watch games, but this difference is fairly significant, and it seems intuitive to me that this time save would continue to accumulate over the course of 1000 points. Based on the trend and the game's mechanics, I think an improved movie would be shorter than 2/3 the length of this submission. My proof-of-concept is not optimized, but it should effectively illustrate the basic technique and provide a basic comparison benchmark.
There are other optimizations. Varied movement (and maybe other inputs?) will affect when parachuters spawn and where they spawn. I just copied the starting parachute inputs from this movie in my proof-of-concept, but it definitely affects the speed. As far as I understand, the octopus tentacles are cycle-based, not RNG-based (though the starting positions are probably randomized), but there could potentially be sophisticated planning around the cycles. There are also some general nuances of point-scoring that I don't fully understand, such as certain extra points and missing points in places.
Summary
Overall, the lack of animation-canceling makes me think this movie is not quite in an acceptable state for publication; I think the submission should be revised to implement this technique.
Also, as I mentioned in my game & goal choice section, I think the extra round of Parachute at the end of the movie may not be necessary for full completion.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Review: It's about time I flexed my reviewing muscles again to help with the site's backlog. This post ended up being very long; strap in!
Overview
This game's developer, Vicarious Visions, is a familiar sight that I've encountered in several other licensed GBA platformers, including Shrek 2 and Madagascar: Operation Penguin. As such, the basic mechanics and game engine are somewhat familiar to me, although each game has its own unique twists on the formula.
The game does suffer from some unfortunate design choices that disrupt the action, including halting character acceleration after the jump button is pressed, requiring a delay to push pushable objects, requiring a noticeable 2-second delay to get back onto Mystery after dismounting, and some poor enemy and platform cycles that require waiting to progress. However, the TAS is interspersed with moments of excitement and tricks, including the super fast glides and spatula duplications.
As far as general routing within levels and game knowledge goes, the TAS seems pretty good. The TAS saves about five minutes over the current real time record on Speedrun.com (1m 13s 110ms at time of writing, held by this TAS's author), and about three minutes over the sum of ILs on the leaderboard (59:19.020 by my calculation).
Improvements
I decided to play around with the game a bit looking at some slow moments in the TAS. Some of them were easily improvable, while others were cycle-dependent and could not be improved. I didn't look at every level, and I didn't completely optimize my movement.
My improvements (updated movie file) totaled a time save of 00:23.99; the new movie length is 56:16.79. Here's a breakdown:
00:07.65 throughout from advancing through menus and level transitions faster.
00:02.24 in 1-3 from tighter pathing to collect spatulas and less air time.
00:03.23 in 1-6 from better glide flow (fewer landings) and better enemy handling (less waiting for cycles)
00:00.44 in boss 1 ("Attack of the Steel Squirrel") from immediately stomping on the boss each time the boss's invincibility times out. I didn't look at the start of the boss.
00:02.85 in 2-2 from better ladder jumps, faster falling, loading floating platform in earlier, and generally tighter movement around platforms.
00:00.42 in 2-5 from tighter movement with Mystery and when generally navigating the level.
00:00.45 in 2-6 from falling faster in two parts.
00:01.46 in 3-1 from tighter early movement and advancing through the dialogue faster. Ideally, the dialogue would be avoided entirely and Mr. Krabs would have a better (leftwards) position when you do the double-jump with Mystery. I didn't experiment too much to figure out why Mr. Krabs is positioned poorly; if you can affect his position, I imagine you can save an additional 10-20 frames by avoiding the dialogue entirely. The real-time IL (link) doesn't appear to have this issue, but it does also reach Mr. Krabs more slowly.
00:01.24 in 3-2 from gliding a bit sooner early in the level and tighter movement around the ladder sections. This level has one of the most significant waits of the run: there's a platform that moves in a clockwise square that the character barely misses, and it takes 10 seconds for the platform to move back into an accessible position. Unfortunately, the platform movement appears to be based on the character's proximity, so I don't think this wait can be avoided; half of the time I saved was from just prior to this platform, and it didn't appear to affect the platform's relative position.
00:00.07 in 3-3 from jumping out of a crawl at the end of the level. I originally looked at this level because the bubbling on the left side looked slow, but you have to wait for the enemy to advance rightwards towards you to fall on the button and open the gate.
00:00.17 in 3-5 from avoiding a triple bot bonk near the end.
00:01.02 in 4-4 from falling sooner after pushing the fan down. The fall still looks a bit suboptimal.
00:02.49 in 4-5 from handling ladders better (jumping on the first possible frame). This is a very basic proof-of-concept; there's maybe a few seconds of other optimizations I can imagine.
There are almost certainly other movement microoptimizations in other portions of the run, since the TAS appeared to be largely done using slowdown instead of frame-by-frame inputs. In the author's movie, certain inputs were frame-adjusted to be pressed on the first possible frame, but there were also many segments where small amounts of time were lost from not jumping on the first possible frame, or moving a bit too far when moving around tight passages. I also learned certain mechanics while I was improving levels, so the improvements have varying levels of quality.
There's also some specific game physics knowledge that came in handy for my improvements. Partway through, I figured out how to locate the RAM address for the character's coordinates (although, it is nontrivial and varies from screen-to-screen, so I will not describe the procedure I used here). Generally, you want to minimize time spent in the air, since walking is faster. There are situations where gliding off a platform can be the same speed as walking, but jumping is always slower because the character completely stops for 5-6 frames to wind up the jump. Sometimes it is better to hold jump for height, and sometimes you want to shorten jumps by gliding early in the jump.
I will note this game is fairly sync-friendly, and later levels do not appear to depend on earlier levels. I didn't resync this movie to 2.9.1 for the sake of comparable time spent on screen transitions, but it probably wouldn't be that difficult.
Synopsis
For an hour-long movie, the level of optimization isn't too bad in my opinion. This movie isn't perfect, but I think it's nearly publishable. I would be happy to see this TAS published, especially with a few more improvements that I'm sure I missed from my one watch-through, although I also have a personal investment now since I spent several hours improving the movie.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Thanks for sharing! I personally have no plans currently to TAS Zelda, but having a 170-star movie will be extremely useful for comparison with a 170-star TAS (one of my long-term goals).
In my personal ideal world, we would be able to use multiplayer and achieve the full 220-star completion (maybe, multiplayer could also save time in the 170-star goal). But, GBA multiplayer is not supported by BizHawk and TASing is not currently supported by mGBA upstream. Also, encoding would be nicer without multiplayer, because only a relatively small portion of the movie actually requires multiplayer. Maybe the encoder can take that into account or maybe I can self-encode!
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Signing up with a team of (in alphabetical order):
- CasualPokePlayer
- InputEvelution
- psx
- RetroEdit (myself)
My other team members will probably make posts confirming this at some point.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
As some have noticed, I've been gone for the past few months. During mostly late 2020, I made [url=
https://github.com/TASVideos/BizHawk/commits?author=RetroEdit]some contributions to BizHawk[/url] and became heavily involved in BizHawk's IRC channel and other places where BizHawk's development was discussed.
It's been fun and I wish the project well. I'm moving on, though.
Since I am unlikely to contribute to BizHawk in the near future, I have removed myself as a collaborator (thus removing direct commit access, though I can still make pull requests). I generally trust the security of my GitHub account, but I'm not a security expert, and removing commit access when I don't need it seems like a sensible extra precaution.
I have also unassigned myself from the two open issues I previously assigned to myself and unsubscribed from all BizHawk issues I was previously subscribed to.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
BizHawk's C# external tools interface is probably the direction to pursue.
Also, some of those Lua issues should be fixed in the upcoming release. The desyncs, I'm not so sure, because I'm not sure where those would come from.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Alyosha wrote:
Hopefully this can get fixed in Gambatte too, it's one of the only really obvious flaws it has. This is not some rare edge case so it probably impacts other games too.
This doesn't appear to be filed on Gambatte-Speedrun's issue tracker. I'm sure they would appreciate it if you filed the issue.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
PikachuMan wrote:
TAStudio doesn't work if the frame buffer is > 8GB. I might be doing it wrong. I want to know how the algorithms work.
Regarding TAStudio not handling certain large allocations well, it might be related to this: ticket #2306PikachuMan wrote:
And the New feature doesn't work either...
What New feature? Like creating a movie starting from a savestate or SaveRAM? Those worked the last time I tested them, but it's conceivable they broke recently or they're broken in more subtle ways than I caught on.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
feos wrote:
RetroEdit wrote:
I will do an exhaustive search for late menu/map/screen transition presses and get back to you on that.
Edit 2020-09-11: Still working on this, by the way.
How is it going?
With juggling BizHawk dev things, DTC9, and other unreleated stuff, I haven't gotten to resolving this in the timely manner I was hoping to.
My goal is to post something later today (yes, I know I said that before, but bear with me). I'll say this: if I don't post anything by 00:00 UTC Thursday, than I'm probably not posting anything until Saturday. I do strongly intend to post something today so as not to waste more of your time.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
feos wrote:
But for Vault, it has to be clear and absolute. If different routing in some levels is now considered a different game, then how many prototypes will need to be published as separate "games" because they happen to fit such a loose definition? Also where do we even draw the line and tell the users "okay yeah now this is actually too similar to be considered two different games"?
That seems like a fair point from an officiality perspective, as unfortunate as it may be.
At the end of the day, I'm more personally concerned with the construction of the TAS than necessarily the "official recognition" of what is the real game. I think Pinocchio presents distinct challenges that would be interesting to TAS independently of Ottifanten regardless of all similarities. But as a philosophy for discerning what can be published, that can clash hard with filtering out games. Does a Mario hack where Mario runs a few subpixels faster and jumping has been replaced with Castlevania physics then count as a separate game? There are probably endless permutations that can be justified under that loose criteria of being unique enough to be an interesting TAS with different challenges.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
feos wrote:
RetroEdit wrote:
A far more objective criteria in my mind would to compare how the relative tactics can be transposed from one game to the other. If it's just a matter of adding blank space between inputs, than the differences are trivial. If however, it actually requires different navigation, then considering them separate may be better. For instance: dodging enemies is clearly different, and I also think Pinocchio is able to jump farther and therefore navigate around the platforms in different arrangements. I would imagine there are very few levels if any where the movement could just be slowed down and exactly copied and be optimal for both games.
It's not objective by definition, because it depends on what the TASer may or may not discover and pull off. Right now they look like different routing is required, even though it's not by design, but rather by an oversight that has been patched. If tomorrow someone discovers a way to move diagonally in Otto at the same speed as in Pinocchio, then the TAS strats will be similar. If it can change over time depending on luck and skill, it's not objective.
Fundamentally, this particular line of argument seems unfair. It's saying because we could hypothetically discover a way to move diagonally in the future, then the current difference doesn't matter, therefore the current difference doesn't matter. This line of argument could be arbitrarily applied offhand to anything.
A better standard would be to reevaluate at future time if such a difference was discovered; we can only operate on the information we know presently and shouldn't be bound to a completely theoretical circumstance. That is my understanding of how branch obsoletion sometimes works: we don't necessarily know all the details of whether two branches that originally appear to be distinct will eventually converge in all cases, so we operate on what we currently know.
(To be clear, this standard is not one-sided for this situation: what we currently know could support either case).
Also, I want to clarify I see the diagonal movement as one difference to be considered among others. The speed I've referred to is not simply a matter of Pinocchio being better because it's faster or something basic like that. It's more a matter of Pinocchio's agility having tangible impacts on how levels can be navigated and which jumps are possible to make, to my understanding.
Editor, Experienced Forum User, Reviewer, Player
(166)
Joined: 8/8/2019
Posts: 131
Alyosha wrote:
I updated GBHawk's interrupt processing to pass all of gambatte's interrupt precedence tests (except HDMA ones.) This is also brings behavior on Gensan 2 inline with Gambatte.
As always please let me know if this breaks anything. There is still a bit of room for error here as the test coverage isn't 100%. I tested against there console verified runs I have and everything seems to still work as expected.
So now GBHawk and Gambatte behave the same for this game? What does that mean for console-verification, I guess the run needs to be modified for the new emulation to see if it will verify on console, or are there still clear emulation problems that will prevent console-verification?
Also, is the list of console-verified games publicly available anywhere? I'm aware it's possible to filter submission by which ones have the console-verified flag, but I'm not sure if you have something different.
