First of all, congratulations on yet another improvement to an already super tight game.
A few concerns I'd like to raise:
* Didn't Pankaj contribute to the boss strategy? [https://tasvideos.org/UserFiles/Info/638212840920688175] or had you discovered these improvements independently? If the first, I think they deserve co authorship.
* I take issue with the choice of emulator. Fceux is known for being less faithful. But even worse, you are still using a very old version of it. Insisting with this choice in 2023 seems lazy, at best. This discourages potential challengers to improve the movie in the future.
I would strongly request a resync to a more accurate emu (Bizhawk 2.9.1). I know this is possible and can be done without much effort.
* Please do make an encode when you submit a movie and write a more informative sub notes. What you wrote is fine but doesn't go much in depth as to why you got better kills. Again, the more info you can provide, the better for potential challengers
I like the idea behind this game. Especially it's open source, which allows more in-depth analysis (especially for guys like me that likes botting stuff). This looks like a great shooter and truly hope Doom experts get to TAS it and submit a run. Almostmatt1? Zeromaster?
From my side I am not crazy about the whole anti-capitalist philosophy behind it, but who cares. I'll download it and give it a (casual) go. Thanks for your efforts and letting us know about it.
My impression is that [Round 23] is score-limited rather than block-limited: 3943M breaks a few more blocks early and then takes time to clean up the rest, but that extra time is mostly "free" because it has to wait for the score to catch up anyway; whereas this submission starts slower and then breaks a large burst at the end, so less of the score tally runs concurrently with gameplay.
Here's a picture of what I mean. I wrote a Lua script to record, for each frame, the number of blocks remaining (called remainingBlocks in jaffarPlus, blue in the graph), as well as the 6-element array at 0x037c..0x0381 that represents the score increment; i.e., that points that are waiting to be tallied into the player's score (orange in the graph). Even though 3943M takes longer to break all the blocks, it is overall slightly faster. By breaking blocks at a slower, but more consistent rate, it keeps the score increment more under control. The maximum score increment in Round 23 in 3943M is 13010; here in 8315S it is 33040.
The way scoring works is, when you earn points, they don't go directly into your score (the 6-element array at 0x0370..0x0375). Instead the points go into the score increment, and from there they move into your score, a little each frame. Here's an excerpt of the CSV log from 3943M to show how the transfer works:
frame
round
remaining_blocks
p1_score
score_increment
2006
2
63
007820
000470
2007
2
63
007830
000460
2008
2
63
007840
000450
2009
2
63
007850
000440
2010
2
63
007860
000430
2011
2
63
007870
000420
2012
2
63
007880
000410
2013
2
63
007890
000400
2014
2
63
007990
000300
2015
2
63
008090
000200
2016
2
63
008190
000100
2017
2
63
008290
000000
The score increment counts down by tens as long as the tens digit is nonzero, then it counts down by hundreds until the whole thing is zero. So, for example, an increment of 1350 takes 13 + 5 = 18 frames to tally into the player's score. A side effect of this method is that sometimes earning points can decrease the amount of time it takes to tally the score increment. For example, an increment of 250 takes 7 frames to tally, whereas an increment of 300 takes only 3 frames.
I don't know the internals of jaffarPlus, but would it make sense to add something like scoreIncrement/100 + scoreIncrement/10%10; into the reward in getStateReward, to make the bot take score increment tally delay into account?
Wow, thanks so much for doing this research. I didn't know this tally mechanism existed and is what caused the delay at the end of the stage (and for some egregiously so).
I'll try to factor this into the reward function next time. Hopefully that will push the bot to pursue solutions that, albeit slower in the destruction of blocks, leads to an earlier tally finish.
I feel like the early game could have been done faster by manipulating money drops in the second race instead of trying to maximize turbos. There's a couple races where you're getting 9 turbos while having 90+ in your inventory, but your car isn't fully upgraded. You said tires/shocks matter, but it takes until the 8th or so race to get to maximize those. Fun movie, great bot, but it seems like based on your submission text, the early game had potential to be better.
You're totally right, there is a ton of space for improvements still, including and especially the ones you mentioned.
Hi Nymx and Spikestuff,
Apologies for submitting this at this point in the process, but I realized a faster boss kill was possible. This movie here contains a ~13 frames faster solution. Please do replace the current submission with it
https://tasvideos.org/UserFiles/Info/638214640676891518
I love movies with happy endings =D
Now for the "hindsight is 20/20" comment: my tip is to setup Bizhawk to do regular saves and backups. And not only that, but work on a GoogleDrive/OneDrive folder, such that every single change you make gets insta-uploaded into the cloud with versioning and all. This should cover you in case your whole computer or SSD goes kaputt. Finally, also make regular uploads of your WIPs into TASVideos.org userfiles.
It's been a billion years, and it looks like it's finally time - the Maniac Mansion TAS is improvable!
https://www.speedrun.com/maniac_mansion_nes/run/m7202xez The WR in RTA timing is 5m29s. Arc's TAS by the same timing would be a 6m15s or so.
Amazing -- he works out with one kid, and the other gets the gains! I wish I could pay someone to go to the gym for me!
Wow....you are turning these BOTed games out like crazy! Are you sure you aren't using a BOT to simulate your presence in front of your monstrous machine? :)
I guess we can recruit ChatGPT to replace the human part of my work -- that'd be the end of TASing as we know it ;)
For anybody reading this: we're joking. Even though it's partly automated, TASing with bots requires ungodly amounts of human effort in reverse engineering, scripting, calibrating, etc for each game. I am personally spending a couple dozen of hours a week to this as of late.
Fully parallelizable emulators exist and I've been using them for a while with high-level of parallelism (128 cores in my threadripper computer)
See: [https://tasvideos.org/Forum/Topics/24058]
Take a look at my movies to see what can be done with a fully parallelized bot: [https://tasvideos.org/Movies-Author11245]
Some emus are non-parallelizable yes, but just because they employ global variables. This is an easily fixable problem, and I indeed did solve it for a bunch of platforms in JaffarPlus. Beyond that, GPUs are nothing but vector processors, ideal for workloads like linear algebra where the same instruction is applied to many data elelments. Console emulation is literally the worst possible workload for a GPU, because you need every different instance of the game to emulate a different console opcode.
Thanks for all your comments! Very appreciated!
The submission summary says re-record count missing, but in fact I manually modified the bk2 file to include the real number: 204150846438. This number comes from the bot's logs, and represents how many load_state/advance_step cycles it tried. I've seen other movies using similar lua script bots being published with similar astronomical re-record counts so I argue there's no reason to not do that for this movie as well.
Hello. I am Linkister and i am new to the whole "TASING" community. I was just wondering how to make SMW tases. Becuse i have been serching, but can not find answers. P.S. I whould love to work and make tases with someone if anyone are interested. - Linkister 2023
Hi Linkister and welcome!
In general, it is not recommended for beginners in TASing to tackle such monumentally researched games (i.e., any game starts with Super or Mario). Instead, you'll have a much fun slide into this hobby by tackling a more basic game that you might be fond of.
To start TASing in general, there are a lot of resources. If I were you, I'd start perusing the article library in this site, especially the Tasing Guide
If you are nevertheless insisting on tackling this game then I, no joke, would read every single post in this very thread. There is a rich history that you just cannot ignore. Then take a look, reproduce, and analyze published movies. Finally, take a look at the knowledge others have curated in the game's resources
TASing has a steep learning curve, but it's incredibly rewarding. Looking forward to watching your movies in the future!
*Correct me if I'm wrong*. I suspect such a movie would be much like the normal mode, since the only thing that changes is enemy behavior which is largely inconsequential to begin with.
There is enough evidence and feedback from the community and judges to deem this and the Tengen version as one and the same game. I agree with that, and since the Tengen one is shorter, I'm cancelling this one. Thanks all for their feedback!
https://tasvideos.org/UserFiles/Info/638189969203933938
I tried a bit more to get a good Kraid fight. I ended up about 5 seconds ahead of the published run leaving Kraid's lair. Currently the run desyncs due to an extra enemy spawning that I don't know how to fix. If anyone can fix it feel free to continue the run.
I could try to help. I had setup the bot to run NES Metroid but quickly gave up doing the entire game due to frustration. If this is a particular situation that a bot can untangle, I'd be happy to take a look. HMU if interested
Does this movie sync with the Tengen version as well? Because it sounds like the only difference is the forced delayed start that causes the RNG to desync from [5231] NES Pac-Man (Tengen) by eien86 in 12:02.86.
Are they really different games?
Hi, the solution desyncs even if you account for the delay. I couldn't say whether this is specifically an RNG effect or some other elements in the game mechanics are also affected.
As to whether to consider these different games, I'll leave that to the community to decide. If the consensus says they are, then I'll go ahead and cancel it
Was excited to see a winning eleven submission. I
used to play the hell out of this game with my friends in my high school years and I know it has a huge potential for a funny glitch showcase.
This submission (or, at least, the encode) however, is not a TAS. It is but a recorded casual playthrough to showcase the mod. It's cool, but I don't think this is the right venue.
Just letting you know that you can trigger an error when logging in, if you change the value of "RememberMe" after clicking "log in". This sends both values which triggers an error. This happened to me on Android+Chrome
What's concerning to me, though, is that the form returns with all credentials as plain text. This means the pass went to the server and back without any type of obfuscation. Pretty sure this isn't too safe.
I love this game and it's awesome to see a TAS for a fighting game that aims for shortest movie (and not just playaround, which are great in their own right). However, these questions remain:
Noxxa wrote:
Is it possible to manipulate what opponents/stage you get? Wondering if it might be theoretically possible to avoid the Raging Inferno stage with its time-slowing stage transition, or avoiding the Juggernaut/Zangief team.
Is Ryu really one of the lowest health characters in the game? I'd have expected it to be someone like Cammy or Magneto (shame you can't pick another Akuma). Is there a character health chart anywhere for this game?
In particular, the possibility of manipulating opponents -- is this deterministic based on your own choice or RNG-based that could be manipulated by delaying button presses? If opponent health determines the number of tatsu cycles requires to defeat them, then this is a crucial issue. This movie might be already be optimal, but we won't know until these questions are answered.
If the same tricks work in both versions, I think having the more complete one is enough (especially if optimal input in the same levels is identical). If there are differences, having both versions means someone will be interested in TASing the shorter one to see how much quicker it gets, and therefore it makes sense to have it. But if you can automatically know how long the quicker one is by simply subtracting a constant value, or copying inputs and then cutting out one level, I'm not sure what value it has, and for whom.
I don't know if I buy the argument that an identical game with more material should supersede the original one. I'll use an imaginary case: "Nintendo launches NES SMB Deluxe in a bundle with a new game to promote sales. The Deluxe version is exactly the same as the original, but contains two more world after the last one -- where you rescue the Princess lost jewels or something." If we used the superset approach, we should adopt the Deluxe version as the main game, converting the current any% into a subcategory lke originalAny%. Here are my my counter-arguments to that:
* Pedigree: Even if the new game is a superset of the first one, it does not carry the same history and nostalgia as the original. Gamers will associate the old one to their memories and emotions and will probably reject as extraneous a game that is longer -- in the same way I reject some self-proclaimed sequels for many series and movies. NES SMB any% carries so much more weight than anything that could be deemed NES SMB Deluxe Version OriginalAny%.
* Backward References: NES SMB any% is the way the most popular category is called. It may become confusing if years and years of using this name would now refer to a different game and different category.
* Multiple Supersets: This is purely mathematical argument, but infinite supersets may exist of any set s != U. Nintendo may choose to release yet another Deluxe version with different worlds. Now we would have to discuss to which deluxe version does the original SMB belong to?