Post subject: Programming TASes
Joined: 3/25/2004
Posts: 459
From IRC: One idea I had was, there should be some TAS tool that allows you to, from a given state, reach a given condition, and then to use genetic algorithms or whatever, to try to find a better solution. On small sections at a time. Room by room in Zelda 1. Or next meaningful action by next meaningful action. Not only should the programming inclined be able to use this tool. It should be as easy for them as selecting from drop downs like, "Don't finish room unless received bomb pickup" Then there should be Relevant and Irrelevant factors. An Irrelevant factor is a RAM address that does not modify the final game state after the playback. Then, if Zelda "conditions" are made, randomly even, and people distribute computational resources to play these manufactured levels with their "conditions" Then in an actual TAS, you can specify the relevant and irrelevant conditions for completing that screen or the next relevant action. Then, for any existing human TAS, this Java TAS could on every screen or next meaningful action Succeed at achieving all the specified Relevant factors With either an equal to or lesser time This could be written as a highly specific program in Java, level by level, room by room, screen by screen. Which would look like what a human TAS maker actually thinks and decides and judges during some subjective decisions through the TAS creation. or something. A new category of TAS can be given. Which is a program to complete the game. I also thought, there should be a further optional principle for TAS creation. That, if an item drop, or something that can be seen to be beneficial, is achievable through luck manipulation, then you should choose the unluckiest route, to not get the pickup, or to get the worst piece in Tetris. Like, not only would that TAS be more like a human playing the game, blind to luck factors... But it would be playing the role of a very unlucky human, who always gets the worst of everything. It's like the Big-O notation of TASes. ... Shouldn't SOME TASes be provably optimal, at the Assembly level? If there is a game where there is an overall goal and subgoals, where the subgoals can be achieved in any order or in a specific order, and where the completion of one subgoal does not effect the required keypresses for completing a future subgoal or a past subgoal, then isn't it the case for such a game, that if each subgoal is provably optimal, then the achievement of the overall goal is also optimal? The only sort of Cartesian demon to thinking there can be a faster time, is if some new glitch is discovered. But I want to prohibit such glitches as against the spirit of the game. But more strongly, I want to say that it should be provable that there are no such glitches, through analysis of the Assembly or open source code. Rightly or wrongly, what conditions need to be met for the day to come that TASers refer to the "first" provably optimal game, (if it hasn't already happened?)? And what conditions need to be met or what possibilities are there, for that judgment to be proven premature? This is a "defeater" to the claim that the TAS was optimal. Can't we, as a community, decide what level the optimality is proven on? For example, if some TASes require exploiting quantum physics, or an NES falling into a blackhole, or something exotic like that... We can specify ahead of time that such exotic physics do not qualify for discrediting the claim of optimality. Rather, optimality is defined in terms of an abstract machine defined in Assembly, rather than on the physical reality of the NES and cartridge. Furthermore, there can be clearly defined axioms of the spirit of the game. Such that, for example, if wall-sliding or double-jumping, or hell even pressing B!, were prohibited, in Mario, maybe that would make it easier toward proving optimality of a goal. Rather than quibbling about what is or should be the goals of TASes, we should more clearly define and justify goals and axioms for any given TAS. Then we should work to scientifically or mathematically proving optimality, in a way that is somehow highly resistant to becoming a discredited claim under some hypothetical future controversy in the TAS community as-of-yet unconsidered. Even if the controversy is successful in getting everyone to switch to favoring a new movie over the discredited one, it should still be noted for historical interest how the first one somehow earned or deserved the title of being optimal. We can't just forget the mistake. We need to specify why the mistake was made. And maybe, rather than considering it as a mistake, if possible, we should just clearly explain that those were the standards or axioms under which the claim of optimality is made, such that, most hopefully, that narrowly-defined optimality is completely immutable from future change.
Post subject: Philosophy
Dragos-san
Other
Joined: 11/4/2019
Posts: 21
Location: Apple Macbook Pro (Early 2015)
This is messed up but so cool. The TAS guidelines tell us to try everything until we find the fastest method for each room. If you have enough computing power, you can tell a computer to go do that as there is a movement limit - the pixel/subpixel. Then you'll have to consider inter-level construction. Does the fastest method for Room A restrict you from getting the Strong Weapon? Do you need the Strong Weapon to make Room B faster? It's just an algorithm of seeing which combo is faster. After this process, you can claim that the result is 'optimal' as you tried every possible choice, and strung the choices together to make the fastest possible route. Outlawing glitches means you don't have to consider stuff like: Does the Strong Weapon allow you to skip Room C? and save a lot of time.
Thank you and have a nice week! :)