Personman
Other
Joined: 4/20/2008
Posts: 465
1. This idea is awesome. 2. Movies made with these goals probably won't be terribly interesting to the general public. We should decide what should get done with them - reasonable options might be: a) submit them anyway, with the knowledge that they will be gruefood; b) post them in the game's thread; c) make a subforum. b) has the problem that people who don't watch that thread won't hear about them; c) has the problem that they will probably never be popular enough, and a) has the problem that it might feel like spam to people who don't care/they will still show up on the front page under 'recent submissions'. However, I like a) best anyway and think that's what people who make MIP movies should do. 3. I can't wait for when there's a movie that requires some serious trickery to figure out how to be allowed to continue to hold a necessary button until the last frame, thus vindicating Warp's position ^^ 4. Actually, though, I think that counting button presses but not frames held is not as interesting as counting each button/frame. We're talking about minimal input, why should we be incentivizing holding extra unnecessary buttons? 5. It does kind of feel like 'holding right' is less input than tapping right every other frame though, and I think that's why the 'count button presses' metric has caught people's fancy. However, holding start all the way through a movie doesn't feel the same. That makes this kind of hard to formalize. 6. At the risk of making this enterprise utterly bizarre and obtuse looking from the outside (but who are we kidding, it already is) we could define two classes of button: those that dislike changing state, and those that dislike being in the 'pressed' state. Then, for each game, there would be 2^n possible movies to make, where n is the number of buttons on the controller, one for each possible set of assignments of a button-types to buttons. 7. Of course, such a proliferation of goals is terrible, so we want to consolidate them. Luckily, this is easy! We can easily define a comparison function between two movies of the same game made with different button-type assignments: simply evaluate the "unhappiness" of each button in each movie, and pick the one with the lowest total! Thus, choosing a button-type assignment set becomes part of the challenge of making the optimal run! 8. The preceding may have been confusing. Let me illustrate with an example. Let us say we have a simple game with only 2 buttons, A and B. Let us say that the game is always completed in 6 frames, if it is completed at all. Now let us consider two competing runs, one with this input:
Frm      A    B
1:       1    0
2:       1    1
3:       1    0
4:       1    1
5:       1    0
6:       1    1
and the second with this input:
Frm      A    B
1:       1    0
2:       1    1
3:       0    1
4:       0    0
5:       1    1
6:       0    1
The first movie will assign button A to dislike change and B to dislike being pressed. It has a total unhappiness of 5: 2 changes for A, and 3 frames down for B. The second will assign A to dislike being pressed, and either preference to B - both of it's presses come in groups of two frames, which are worth 2 unhappiness points under both preferences schemes. It's total will be 7, so movie 1 will be the victor. It may at first seem kind of unfortunate that the crossover point is at an average of two frames per button activation, but given how most games work, I think it is reasonable. In many games, jumping and shooting only take one frame, and thus those buttons can be profitably assigned the 'dislikes being held down' preference. 9. I've chosen above to treat time before and after the movie as ... existing. And being real. By which I mean, you can't say you've been holding that button forever and will continue to hold it forever after the movie stops. My motivation behind this is that it incentives the thing that originally motivated this entire idea - not holding start the whole way through. If pressing start on frame 1 and holding it all the way through was 0 unhappiness points, but pressing it once on frame 1 and never again was 1, that would do the opposite. As it is, holding it all the way through is 2, which is what I want. 10. While making the example, I had a really silly and off-topic idea, and since you clearly haven't read enough words in this post yet, I thought I'd share. It is a challenge of a wildly impractical nature: I present you with two very different input files of equal unhappiness. You design a game to which they are both MIP movies, and which has consistent/reasonable input semantics than can be learned and played by a human. ... I might actually give that a shot with the two 6-frame inputs I used above. I'll prolly say the game runs at about 1 fps.
A warb degombs the brangy. Your gitch zanks and leils the warb.
Editor, Expert player (2328)
Joined: 5/15/2007
Posts: 3929
Location: Germany
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
Personman wrote:
4. Actually, though, I think that counting button presses but not frames held is not as interesting as counting each button/frame. We're talking about minimal input, why should we be incentivizing holding extra unnecessary buttons?
I'd say that the idea of counting in each frame how many buttons are pressed, and the total "score" of the run being the sum of all those counts is not completely sensible for one reason: It doesn't distinguish between having one button pressed for several frames and alternating button presses on each frame. In other words, suppose we are counting a segment of 10 frames, and during all of those 10 frames the A button is pressed (and nothing else). The total count would thus be 10. However, assume that instead the A and B buttons are alternated on each frame. Again, if we counted like above, we would still get a "score" of 10. However, alternating between A and B 10 times is intuitively a lot more input than just keeping A pressed for 10 frames.
Editor, Expert player (2071)
Joined: 6/15/2005
Posts: 3282
MUGG wrote:
I did a small test movie of SMB 1-1. http://dehacked.2y.net/microstorage.php/info/1874157891/smb1-1minimalinput.fm2
Interesting. Minimal input frames seems a lot better than minimal presses.
Joined: 10/20/2006
Posts: 1248
What if you just add up all button presses * amplifier x (only first frames) + total of held down buttons (over the whole movie)? Or make every first frame a button is pressed count as a maximal value x, the second frame less than the first, the third less than the second, letting it slowly converge to a minimal value y?
TBA
Joined: 4/21/2011
Posts: 7
Location: Germany
MUGG wrote:
I did a small test movie of SMB 1-1. http://dehacked.2y.net/microstorage.php/info/1874157891/smb1-1minimalinput.fm2
You are ~90.31% lazy (meaning ca. 90.31% of all movie frames had no input).
Banned User
Joined: 5/11/2004
Posts: 1049
I think counting all input on all frames is best or makes the most sense to me, ie not dis-counting input if the same was on the previous frame.
"Great spirits have always found violent opposition from mediocrities. The latter cannot understand it when a man does not thoughtlessly submit to hereditary prejudices but honestly and courageously uses his intelligence."
Brandon
He/Him
Editor, Player (191)
Joined: 11/21/2010
Posts: 914
Location: Tennessee
I want to try this idea. I think button input and button presses are two different goals, and I think they should be treated as such. People who want to do minimal input TASes can do as such, and people who want to do minimum presses can do that as well, but let's not try to combine the two. I personally want to try minimum input as I think it would provide the most interesting strategies. Before we do this, however, I think we need a solid Lua script that can display the amount of input up to a particular part of a movie. Although I doubt it helps, here's a simple script that merely counts all the input up to a particular point:
Language: lua

local count = 0 while true do local player = 1 while player < 3 do for index, value in pairs(joypad.getdown(player)) do count = count + 1 end player = player + 1 end gui.text(0, 0, count) emu.frameadvance() end
This will not reset when rerecording, which is a problem from my perspective. Ilari suggested parsing the movie file, but that sounds very inefficient in real time. Also, it would be difficult to adapt to all consoles. Does anyone know any alternatives? If you'd like to also make the script count button presses, by all means, that'd be helpful too, but can we agree that a press is counted on button down? It sounds silly to hold down start for the entire game just so it isn't considered a press, especially considering that you'd eventually have to lift your finger in real life.
All the best, Brandon Evans
ALAKTORN
He/Him
Former player
Joined: 10/19/2009
Posts: 2527
Location: Italy
MUGG wrote:
I did a small test movie of SMB 1-1. http://dehacked.2y.net/microstorage.php/info/1874157891/smb1-1minimalinput.fm2
can someone encode that?
NitroGenesis
He/Him
Editor, Experienced player (556)
Joined: 12/24/2009
Posts: 1873
ALAKTORN wrote:
MUGG wrote:
I did a small test movie of SMB 1-1. http://dehacked.2y.net/microstorage.php/info/1874157891/smb1-1minimalinput.fm2
can someone encode that?
Sure! http://www.mediafire.com/?3110u4icwgrdcd7 It uses andymac's AVI Heads Up Display script, so you can see the button presses. I reccomend watching it with something that supports frame stepping, so you can see the one frame presses.
YoungJ1997lol wrote:
Normally i would say Yes, but thennI thought "its not the same hack" so ill stick with meh.
ALAKTORN
He/Him
Former player
Joined: 10/19/2009
Posts: 2527
Location: Italy
NitroGenesis wrote:
ALAKTORN wrote:
MUGG wrote:
I did a small test movie of SMB 1-1. http://dehacked.2y.net/microstorage.php/info/1874157891/smb1-1minimalinput.fm2
can someone encode that?
Sure! http://www.mediafire.com/?3110u4icwgrdcd7 It uses andymac's AVI Heads Up Display script, so you can see the button presses. I reccomend watching it with something that supports frame stepping, so you can see the one frame presses.
thanks :) I can't download anything atm, but I'm guessing all the inputs are right+jump for 1 frame? then the game keeps momentum with the jump? does it keep momentum with bounces off enemies too? could be a cool concept, not sure yet
Brandon
He/Him
Editor, Player (191)
Joined: 11/21/2010
Posts: 914
Location: Tennessee
I'm not sure what game I'd actually try with this. My primary concern is attempting to make the tools to make the tracking easy. I tried one where I parsed the FM2 file, but it is SUPER laggy, and will not work while recording. Any ideas?
All the best, Brandon Evans
Player (42)
Joined: 12/27/2008
Posts: 873
Location: Germany
To avoid going through the entire movie file every time you want to check presses, you could try to have a presses counter and increment it as the frames are advanced. The only drawback of this method is that whenever a rerecord happens, your values will no longer be correct. To circumvent this, you could store this information when a savestate is saved and retrieve it when one is loaded Since I don't know a way to put data inside a savestate, a good option would be to create an external file that links the savestate to the amount of presses that occured up to it. Use functions savestate.registersave() and savestate.registerload(). Whenever, a savestate is saved, hash it somehow (frame number, buttons pressed, checksum of a memory range) and store it in this file with the amount of presses. When a savestate is loaded, do the same hash function, look for it in the external file and replace your current data with it, if it's not found, make it go through the movie file again to find it and store it in the external file.
Brandon
He/Him
Editor, Player (191)
Joined: 11/21/2010
Posts: 914
Location: Tennessee
p4wn3r wrote:
To avoid going through the entire movie file every time you want to check presses, you could try to have a presses counter and increment it as the frames are advanced. The only drawback of this method is that whenever a rerecord happens, your values will no longer be correct. To circumvent this, you could store this information when a savestate is saved and retrieve it when one is loaded Since I don't know a way to put data inside a savestate, a good option would be to create an external file that links the savestate to the amount of presses that occured up to it. Use functions savestate.registersave() and savestate.registerload(). Whenever, a savestate is saved, hash it somehow (frame number, buttons pressed, checksum of a memory range) and store it in this file with the amount of presses. When a savestate is loaded, do the same hash function, look for it in the external file and replace your current data with it, if it's not found, make it go through the movie file again to find it and store it in the external file.
I'd really rather not create external files for this...the more compressed and simplified this is, the better.
All the best, Brandon Evans
Player (42)
Joined: 12/27/2008
Posts: 873
Location: Germany
You can always have everything saved at the script's tables. The idea of using an external file is that the stored data won't go away after the user closes the emulator.
Brandon
He/Him
Editor, Player (191)
Joined: 11/21/2010
Posts: 914
Location: Tennessee
I think I figured out the best method: a hybrid of both recording real time presses, and parsing the FM2 when necessary. I have coded this, and it seems to work nicely. I have created a page regarding this kind of TASing, and the page includes a link to the script. Could anyone report back letting me know how it works for them? Perhaps this will spawn some WIPs? :) Edit: I've made this a little more efficient...now, instead of reparsing on every state load, it parses the file once in its entirety, caches the data, and references the frame you are loading to. You can find the updated script where the old one was. The problem is, it seems that without writing to the save states, this will seemingly not work with rerecording. adelikat recommends I try to patch FCEUX. I'm not sure why I'd do that if there's any possibility of just including it in the main code (It does sound like a useful feature), but nonetheless, here'd be the game plan if I was able to do this:
  1. When playing in real-time, count normally.
  2. Upon saving, log the data to the save state. Load this data upon loading.
  3. If a save state is loaded without this data, and it is part of a movie, parse the FM2 for the data and log it. If it is not part of a movie, reset everything.
Until I'm given more information on this, I can't really continue on with this...which means I have time to do other things! Woo! <_< Edit 2: It seems like I'm really thinking about this too hard. After all, considering we already have a tool that calculates button presses, we really just need one that tracks them in real time and that allows rerecording. So, here's the new plan:
  1. When the script is run, if a movie is loaded in read only mode, calculate the initial data. If not, begin everything at 0.
  2. When you save a savestate to a slot, record the data at that point.
  3. When you load a state saved while running, load back the data.
This should be enough to conveniently make a minimal input TAS. There's no reason to over think this. Edit 3: Done. It even works on Snes9x, though it only loads initial data if a fm2 file is loaded. I'm sure there's a way to support other emulators, but I'll leave that up to the people who care enough to modify the code for that feature. :) Edit 4: Expanded the page and proposed a scoring system. I will construct a very sloppy MPTAS of SMB as a proof of concept, and afterwards, I might try to obsolete myself. It'd be really cool if someone continued mugg's work on the MHTAS end.
All the best, Brandon Evans
Brandon
He/Him
Editor, Player (191)
Joined: 11/21/2010
Posts: 914
Location: Tennessee
So, I completed my the first Minimum Presses TAS (MPTAS): a horribly sloppy run of SMB in 171 presses. You can find it, as well as a suggested ranking system here (I moved it to a subpage of my account as adelikat has informed me it shouldn't have its own page, at least until other people start adding runs of there own). If I get the chance, I will rerun it and hopefully reduce presses / shorten the movie / both. I'm certain both are possible. If anyone wants to try to obsolete it, by all means, but it'd also be interesting to see a full Minimum Holds TAS (MHTAS).
All the best, Brandon Evans
Editor, Expert player (2071)
Joined: 6/15/2005
Posts: 3282
My post was buried in the thread somewhere, but I had (if I remember correctly) 163 presses once. http://dehacked.2y.net/microstorage.php/info/1372908278/Super%20Mario%20Bros%20%28PRG%200%29%20%28JU%29%20least%20press2.fcm
Editor, Expert player (2328)
Joined: 5/15/2007
Posts: 3929
Location: Germany
Editor, Expert player (2328)
Joined: 5/15/2007
Posts: 3929
Location: Germany
http://dehacked.2y.net/microstorage.php/info/606060007/smb1muggleastpress.fm2 158 presses 0h 5m 35s (20100 frames) What a pity, I expected a greater improvement. Maybe it is possible to cut 2 or 3 button presses by using bullet bill or hammer bro manipulation. As for your wikipage, I suggest using a simple list like this:
NES Super Mario Bros. (JPN/USA PRG0)
  * 158 presses by MUGG in 5:35.00  (2011-7-18)
  * 163 presses by FractalFusion in 5:59.67  (2011-7-17)
  * 171 presses by Brandon in 5:45.90  (2011-7-17)
Your current system looks very confusing to me.
Player (42)
Joined: 12/27/2008
Posts: 873
Location: Germany
PRESSES WARZ!!!!!
Brandon
He/Him
Editor, Player (191)
Joined: 11/21/2010
Posts: 914
Location: Tennessee
I added both of your runs, though I committed Fractal's as a .fm2 so that people can watch it with my script.
MUGG wrote:
As for your wikipage, I suggest using a simple list like this:
NES Super Mario Bros. (JPN/USA PRG0)
  * 158 presses by MUGG in 5:35.00  (2011-7-18)
  * 163 presses by FractalFusion in 5:59.67  (2011-7-17)
  * 171 presses by Brandon in 5:45.90  (2011-7-17)
Your current system looks very confusing to me.
The point of double obsoletion is remove the incentive of initially making your run as fast as possible. When you aim for speed, you will probably use more buttons than you realize you have to. If I could take away your ranking merely by making a faster run and not by reducing the number of presses, then you'd probably spend more time trying to make your run optimal for speed than looking for new places to reduce button presses. Edit: I have found at least one unnecessary press. I'll rerun soon.
All the best, Brandon Evans
Brandon
He/Him
Editor, Player (191)
Joined: 11/21/2010
Posts: 914
Location: Tennessee
SMB in 156 presses. I mostly reused MUGG's work (With his permission), controlling Mario for most of 8-1, all of 8-2 and 8-3, and the ending of 8-4. I removed one press from 8-1 by evading a Koopa (Must be small Mario to do this, which didn't hurt later on) and one press from 8-2 by evading yet another Koopa, although this was not planned and probably resulted in by the new method I had to take to get over the blocks without additional presses as small Mario. Beat that!
All the best, Brandon Evans
Editor, Expert player (2328)
Joined: 5/15/2007
Posts: 3929
Location: Germany
GB Super Mario Land (W) (v1.0) in 289 presses VBA21 I didn't use autoshooting in 2-3 since I didn't realize it was there.
Editor, Expert player (2071)
Joined: 6/15/2005
Posts: 3282
SMB in 148 presses.
MUGG wrote:
GB Super Mario Land (W) (v1.0) in 289 presses VBA21 I didn't use autoshooting in 2-3 since I didn't realize it was there.
That's one ridiculous movie. :D