I recently showcased this TAS in the context of the PoPRuns 2023 event.
Link to video
If any admin would be so kind to attach this video link to the movie as 'includes explanation' thingy, that'd be great.
Thanks!
Was it really necessary to wipe the original submission comments? Those can still be useful to other runners/TASers after all, and just because a submission doesn't get published doesn't mean that people might not still watch it in submission form
Ok, adding my review:
* Sync: Yes. Tested on c-square's modified JPC-rr 11.2 with TASScript
Making it sync was a bit of a research task. (EDIT: which would have been much easier, had I read : feos' post, smh) This movie uses a different machine BIOS' than the ones provided in c-square's JPC-rr 11.2 redistributable. You have to download them from the Bochs repository and import them into JPC manually:
https://github.com/ipxe/bochs/blob/master/bios/BIOS-bochs-latest
You need to modify the movie file with this line, if you want it to reproduce with this BIOS:
BIOS 740f01be58103af0996220bdeb7c4d12 -> BIOS 21fa468b969329b6ac3571ead5b181e3
Similarly, a different VGA bios is used (Elpin) to properly display the game's text and prevent a desync.
https://github.com/ipxe/bochs/blob/master/bios/VGABIOS-elpin-2.40
As for the DOS disk, the standard FreeDOS image that comes with JPC-RR works just fine. For the game image, I used GoG's source removing the unnecessary files, according to the submission notes.
* Previous Work: DrD2k9's own previous movie (Movie #4447M) played on a similar setting. This movie improves it by almost 2 seconds.
* General Optimization: I really recommend OneShortEye's documentary on this game's WR history and read previous submission notes to know the level of trickery that goes into beating this game fast. The TAS, of course, takes this to an extreme. The level of optimization is clearly visible and there's nothing I can add to it. I'm mindblown by the new tricks, especially the beanstalk yolo skip.
* Entertainment: Watching this movie at different speeds (see provided encodes) provide totally different experiences. However, as with any TAS, it takes some knowledge to truly appreciate the level of trickery. I would love to watch a TAS-specific documentary to dissect every step of the movie.
Hi DrD2k9,
I've tried to reproduce the movie but ran into a problem. I got the right game and FREEDOS images, but the BIOS, VGABIOS, and version of the emulator I downloaded (JPC-rr 11.2 w/ TASScript 2.01) are incorrect.
I cannot seem to find the one you used anywhere. Can you please give me a pointer as to where to find it? Thanks
Here's my quick review.
* Sync: Yes. Tested on BizHawk 2.9 (Core: NesHawk)
* Previous Work: NhatNM's previous own movie [https://tasvideos.org/2398M|2398M] played on FCEUX 2.2.1. This movie improves it by 10 seconds.
* Boot/Menu Optimization: I could not improve it.
* Routing: The player chooses the pink girl character who seems to be the fastest in movement and attack. This seems to be the optimal routing choice, given The game mixes beat'em up stages (can only advances after you defeat the active enemies) with get-to-the-end-as-fast-as-possible stages. Some other stages include autoscollers and boss fights. Perhaps boss fights might benefit from a stronger fighter, but of course this would lose time in the running stages.
* Gameplay Optimization: I took succinct look at the inputs and their seem very optimized. I played around with it and found that, if you're not careful enough, some lag frames will creep in when some objects (e.g., barrels, dogs) are not dealt with and they start to accumulate. So I can tell special attention to lag management was done in this movie.
* Last Input Optimization: I attempted to improve in the last input but did not succeed.
* Entertainment: The author inserted some cool moves whenever waiting was necessary, which is always nice.
I vote yes.
I've found many minor improvements in this movie that I'm working on. Do you agree to have me as co-author (and let someone else judge it)?
Also, I noticed you let some enemies live for the sake of saving few frames there and there. I think that's a bit counter-intuitive for a movie that aims to complete the challenging stages. Would you mind if I included those missing kills?
Sure, I agree on both aspects. Thanks for your hard work.
Wow, I'm glad to see the skip glitch being used in TAS. Thank you.
I quickly checked your movie, and noticed a few things:
* In battles, you can charge the gauges faster by rapidly pressing R button. And, the kick is a bit stronger than the normal punch. (I uploaded a sample movie)
* After getting the gold cloth, if you fully charge all the gauges, Seiya sometimes wears the gold cloth and his firepower increases. But, due to a bug, if you use the gold cloth once, the next enemy's defence will be increased. You can fix the enemy's defense by calling some ally. (This technique is used in the later Mini4Rider's video)
FYI: Mini4Rider uploads a glitchless TAS video (part1, part2). Unfortunately the movie file seems to be unavailable, but it looks optimized well. For example, it seems to take a faster route in a cave.
Thanks TaoTao, this is all very useful information!
@Nymx: I'm gonna go ahead and produce an improved movie.
I'm gonna go on a limb here and guess that it's a matter of hosting costs. FM3 movies contain a bunch of superfluous extra data (e.g. ,stored intermediate states, a.k.a. green zone) that can make them rather large. They could go as large as Mbytes or more.
On the other hand, FM2 movies are compact and still contain all other people may need (inputs only plus some minimal metadata) to inspect your work.
Hey,
I'm currently TASing this game:
NES
Galaxian (J) (REV0) [!]
SHA1:A2C837C589E0FADEA7626E0245914F1B0C7948FD
MD5:4D2A95F9258DADE4511715DD7C310D38
It seems like the game loops indefinitely without changes in difficulty (as far as I could tell, tho). Only difference for level two onwards I noticed are:
- You can choose where you start the level since you can still move after you beat the first level.
- You can even pre-shoot so you can hit one of the enemies as they spawn
- Score, lifes, and stage indicator (flags) are conserved.
My question: would a fastest-stage-1 submission be an acceptable category? If not, could somebody propose a more adequate ending criterion?
Thanks
-------------------------
Addendum:
For ease of analysis, the following movie solves the first level:
https://tasvideos.org/UserFiles/Info/638246861273711808
And here is a ram map:
https://tasvideos.org/UserFiles/Info/638246862016140343
Wish I knew what was happening in more detail so it could be a bit more interesting. Maybe more detailed author notes would help? However this is obviously a very good (6 minute) improvement over that older submission. This game reminds me of the Godzilla game for NES in a way since they have the two main modes. Meh vote.
Hi CoolHandMike, thanks watching and the feedback. Yeah, given the reception the game had also in Xipo's submission, it was very hard for someone who hadn't watched the anime (or can read japanese) to understand what the game is all about. So now I made an [https://youtu.be/SyORA4TyHh8|explanation video] where I clarify aspects of the lore and the gameplay, if you'd be interested in watching.
Dimon12321 wrote:
One of the few Japanese NES games I've played in my childhood. What a great discovery the bot has found! That screen scroll that immediately takes to the end of a level.
Yes vote.
But I'm still wondering what was the point in decreasing your health during the battles, if you could just take damage. It would drain more cosmo points?
Also that cosmo draining on the last battle. What it necessary?
Thanks for your message!
* But I'm still wondering what was the point in decreasing your health during the battles, if you could just take damage.
Taking damage is bad in two aspects: it takes a long time for the attack to end while it depletes your energy, but more importantly, it affects both your life and cosmos. While we do want to die, we don't want to have our cosmos decreased, as we need it for the battle! So the best solution is to manually set HP to zero and parry the incoming attack. Since we are still in zero HP, we still die, but the attack does not affect our cosmos.
* Also that cosmo draining on the last battle. What it necessary?
Yes, so that our attacks last for fewer frames. This is a seemingly wasteful investmnet, but we still kill Saga in the same amount of attack cycles, and waste less frames at the end of each attack.
There is a Chinese TASer whose work I like and I would very much like to reach out to.
https://gong-lue.com/https://space.bilibili.com/64514
I've been trying many ways to reach him but (a) I cannot message him on Bilibili (the site requires responding some weird questionnaire) and (b) QQ does not allow me to login even though I do have a Chinese phone number (don't ask how).
I would like to ask our Chinese colleagues on tasvideos.org to please help me reach out to this guy. Thanks
I've started to work on a NG2 pacifist movie (I don't guarantee I'll finish it though). During my research I came across this submission from 11 years ago. This movie is beautifully made and, in my opinion, would meet today's standards for publication. I would love to see this re-judged and perhaps ultimately accepted.
As a viewer/player, my only objection about this movie is that it includes "No Damage Taken" as criterion for pacifist%. This is today not clearly a requirement, as we have plenty of pacifist publications where the only requirement is not to damage enemies or items (see: [4812] NES Ninja Gaiden "pacifist" by MESHUGGAH, eien86, feos, Marx, jprofit22 & Scumtron in 11:16.89[5034] NES Castlevania "pacifist, minimalist" by eien86 & Challenger in 10:55.42). It also misses the chance to use Shurikens to beat the first boss, which would be definitely allowed. These are minor comments which wouldn't preclude publication, were I to judge it.
Hey Judges,
I'd like to ask (plea) about the acceptability of a disk set for Apple II's Prince of Persia.
md5sum: ad841fb8aa3753a1f90f078de65370a5 prince of persia side a (san inc crack).dsk
md5sum: ddd3af336482d65521d043eea0283df1 prince of persia side b (san inc crack).dsk
I searched high and low and could not find an original (uncracked) copy of the game. These disks contain a version of the game that overcomes the game's copy protection. Other versions of the game I found out there are also cracked, with the addition of hax0r l33t screens that ruin the experience.
Since this game's protection is only logical, and not an interactive screen like in [5206] DOS Prince of Persia by eien86 in 13:59.15 or [5296] DOS Out of This World by eien86 in 09:56.54, I'd say there's no content lost.
Either an approval that I can go on with these images, or someone finding actual original copies (and a way to overcome their protection via inputs) would unblock me in starting this project.
Thanks!
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
Hello,
I have just added demo/TAS support to my game called Anarch
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.
The re-record (load state, change input, advance state) count of this movie is: 2,529,914,332,046. I'd like to ask for this value be properly represented in the publication. I'll keep the execution logs for a while if someone wants to check them out.
Typically, we don't include botted re-record counts and we just put "Unknown" as the re-record count in such cases. We also have an ongoing topic about tracking re-record counts, where no conclusion was reached thus far. Are you fine with me mentioning an unknown re-record count in this case as well?
Yes, that's ok.
Perhaps it's better to continue the discussion in that thread than here.
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.
