The problem with ending input early is this: If the input ends, the game will exit. That is why it is necessary to keep recording input after the final shot.
Hm, so it's a software limitation of the movie playback code in the game? Maybe the TAS timing calculations could be modified for Doom movies to ignore all null inputs after the last non-null input?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Regarding the cyber kill, it's very likely the better option to start with a plasma gun because that does a lot more damage to cybers.
Well, you would fire the same amount of rockets, switch weapons, and finish by firing your cells.
I'm not certain how that would make much of a difference, since he'd still be firing the same number of shots.
The implication is that you can start firing rockets sooner than you can start firing the plasma, assuming you can get the rockets to land, because you may be able to manipulate the Cyberdemon into walking into them. I.e. you fire from a location where you cannot even see the Cyberdemon (and thus probably can't use plasma because its faster travel time means it'd almost certainly miss), and then while the rocket is in flight the Cyberdemon walks into the firing path.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
That Lua script has broken the page width. :(
Looks interesting though. I look forward to seeing an encode...though somehow I expect it'll be nearly impossible to follow what's going on.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Does it need to be console verified to show at a *GDQ, though? Or I guess more specifically, is console verification a personal preference for the presenters or is it actually a requirement set by *GDQ officials? I'd love to see this played at a *GDQ but given how spotty console verification is even for the systems where it works well...
Console verification is a great way of saying "TASes actually aren't playing a different game", and thus they make a great sort of "community outreach" project. And of course they're also helpful for verifying that our emulators are accurate.
For *GDQ, though, console-verifying introduces a lot of risk to presentations, as dwangoAC well knows. It's all too easy for something to disrupt the verification process, and you don't want your audience to be watching as you try things over and over again while saying "Hm, this has never happened before."
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
But console verifying a later generation would be amazing to the viewers. :o
Load times for disc-based consoles are fundamentally nondeterministic, unfortunately. I suppose it's possible that some games might still be verifiable if you had some kind of feedback loop (i.e. the input mechanism includes some way of checking the current state of the game so that inputs happen at the right time after loading), but a) that assumes that nothing significant happens while loading, in particular stuff like advancing RNGs, b) it would be horrifically complicated to implement, and of course c) it'd be specific to the game you implemented it for, not a generalizable solution.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
This was pretty fantastic. The amount of "teamwork" on display here was great. And yeah, I'd have no objection to the TAS taking the time to input their initials at the end; the competition here is for score, not time, so the time taken for that input is not a factor.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
The only way to TAS this game was frame-by-frame trial and error
Well first of all, congratulations on proving sonic is slow as phuck, but I don't understand the quoted sentence (you already know the distance you can travel each frame) nor the problem behind the "impossible turns" (example is an L turn at a corner?). So what did you do when you can't turn "instantly"?
The turn is impossible because you input "L" to head left, the character travels 12 spaces, and you overshoot your turn opportunity before you get the next chance to provide input.
I don't know what specifically makes the game trial-and-error, though.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Nice work! That's pretty impressive.
What was the reason for re-incarnating yourself at save points, when you didn't switch materials? You seemed to do it regularly with the glass ball.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
One person in the YouTube comments wonders why you didn't shoot down the fifth boss right away (from 7:07 to 7:26 in the YT encode):
Hexley the Platypus (danylopez123) on YouTube wrote:
May someone answer me what happen from 7:07 to 7:26, why did he made a stop?
If you look at the RAM watch in the bottom-center, it shows the boss HP, which is continually counting down for this boss fight with no input from the user except right at the end. I don't know exactly how that works, though.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
What do the various talisman do? One of them lets you attack while as a monkey but what about the rest? This question is just an in general question, not specifically targeting the TAS.
They all basically just give you (extra) attack options when transformed.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Shooters used to get rejected if the run was boring, e.g. because the author made no special attempt to be entertaining. But now we have the Vault category, so even a boringly-played shooter can be accepted as long as it's optimal.
But I think a decent Recca TAS would easily make the "moons" category, which means it gets accepted on the basis of its entertainment. I do strongly recommend playing the Zanki Attack mode for added insanity though. The WIPs I did earlier in the thread managed to make it through the first two stages without missing any kills, but I'm not certain that's possible for the rest of the game. I'd love to be proved wrong though! And I made no special effort to avoid lag, I must admit.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Because TASVideos has a long history of only ever doing what we've done in the past. :)
As feos obliquely notes, the technical process of submitting a new movie format is a bit tricky, but from what I understand, the mods can accept any file they like as a new submission, right? So, y'know, if you can get the mods on-board with your unique format, then there shouldn't be a problem.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I can't speak in any official capacity, but in my opinion such a movie would be fine to submit. There'd be some technical issues -- the file format of the submission wouldn't be recognized by the website code, and generating encodes might be difficult -- but as long as the game syncs for other players and the quality of the run is high, I don't see why the game couldn't be accepted.
It does help that the developer of the game has signed off on these modifications, though. That's important to help make it clear that the run is done on an official version of the game.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
ehhh, thats a lot of numbersWhat I am asking is if that means games run on PAL60 play faster than NTSC as a result, as previously mentioned, the framerate might not make a difference depending on if the hardware is framerate-agnostic or not.
Software, not hardware, so yes, it could be game-specific.
Dolphin shmolphin; I believe the original question was about doing speedruns on actual hardware, yes?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I'll rephrase my question.
Does PAL60 having a higher framerate (60.02 compared to 59.94) mean it is generally better for speedrunning?
That depends entirely on implementation details of the game in question. A properly-written PC game ought to be framerate-agnostic, as it can't know what kind of hardware it will be run on and needs to be able to run at the correct speed regardless. This generally involves performing physics at fixed "ticks" (e.g. 10x per second) and filling the rest of the unused time with extra display updates (interpolating between the physics updates) so that the framerate is as smooth as possible. As long as your hardware is able to do each physics update on time, the game will run at the correct speed, regardless of anything else.
But on a console, you do (in theory) know what kind of hardware you run on, so maybe you're just running a physics update every 5th frame or something. In that case, having a higher framerate would actually make the game run faster -- again, assuming that the hardware was able to do the updates that quickly.
I would expect modern console games to be implemented "properly", if only to make porting to PC easier. But I can't say for certain.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Would it be possible to take the right side of the final building, manipulating the debris away, in order to grab the helicopter sooner? Or is that after ending input anyway? (watched Spikestuff's encode, which doesn't show when input ends.)
I assume input ends at the top of the tower.
And man, this game looks unfair. Could be interesting to see a controller input overlay, assuming the controls are as painful to work with as dwangoAC described.
That climbing sound effect could make a good basis for a chiptune soundtrack.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
