Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
I agree my submission text didn't explain this too well, I wrote it mostly for people not intricately familiar with the game's mechanics to understand what's going on, and these details seemed arbitrary and not very helpful in this regard. In retrospect, I should have had more emphasis on how the improvements worked in greater detail and less in explaining the game and this run in general, which of course was no new information for you.
I'm glad we could resolve this debate in the end though, and I'd like to apologize that it got somewhat heated in the middle of it.
Speaking of barely solvable, for this one which was solvable, there were many that weren't. The one annoying me most was the pipe entry in 8-4 after the pipe clip, which is exactly one subpixel short of making it a frame earlier. What makes this especially annoying is that you can make it to the pipe a frame early, but you can't press down to enter it if you do, since you can't press down and right at the same frame while on the ground. You probably knew that, I just wanted to rant about it.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
No, you did not misinterpret the code, most of the final inputs for the precise movement sections of this run were created by it, including the fire flower collection in 1-4. However, the technique necessary to save the frame rule was discovered before that, by hand. You can actually see that in the code, I specifically added constraints to it so that it only considers running jumps (here), since I knew this is what's needed, and an additional contraint on when to start jumping (here). The state space of Mario's movements is quite large and the tools are not that powerful (or my RAM is too small), without figuring these things out first it wouldn't have been possible to compute the final inputs in the first place. You can find these manual restrictions in a lot of places throughout the code, the tools are just way less powerful than you might think.
The same goes for most other movements, also the ones that are no improvements to you previous run. I figured out what to do manually first, before having the tool find the optimal inputs. This is what I was referring to earlier, and I'm sorry for causing confusion here, I didn't mean it to sound like I discovered these ignoring your previous run completely.
Regarding the screen position in 4-4, the magic relative screen position (that's RAM address 0x03ad in-game) to aim for is exactly 0x92 (code), which scrolls the left screen position (RAM address 0x71C) to 0xec before the scroll lock is applied, saving the necessary frame in the ending cutscene. The goal was to move mario as far forward as possible without exceeding that screen scroll number. And the best possible movement was just good enough (as in if couldn't be even a single subpixel worse) to make it work.
Yes, the code contains the entire map for most stages, as it's easier to work with like this, but each calculation only ever uses a small part of it. I used lua scripts to format Mario's state into the format the program understands, so that I could just copy and paste a state into the program and have it work from there, and for that it's important that the position is absolute, so I need the whole level to be represented. Dumping the level data from the rom was fairly straight-forward, using a python script to convert the memory contents into readable maps, so it was easier just to import the whole thing instead of worrying about which parts you actually need.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
I admit I'm not innocent in creating this situation. My main motivation for creating these is discovering how things work and how to exploit them, not beating somebody else's time. These submissions are just a nice closing point to show these discoveries. That's why I'm usually not announcing future runs, I usually don't start out with the intention to submit any particular run. Also, I may just lose interest and abandon it at any point, and I don't want to create pressure for myself to deliver given that I do these for fun and recreation. This is not the first time it brought me into this situation. We couldn't have prevented it here, but we could have worked out something in advance, instead of after my submission.
Also, I'm sorry for creating some drama here, the inaccuracy of HappyLee's claims may have gotten to me a little too much there. I'll try to set the record straight in a more productive way going forward.
HappyLee wrote:
Actually you don't need to figure that out by yourself (in cases like 1-3 floor clip) when the solution is already there, since I've already figured it out back in 2012, and if you imitate or study my inputs or my movements, you get almost the same thing (I'm not saying that's exactly what you did, but it's true and the easy way). You can say that you didn't learn anything from my inputs or my movements, but I don't believe that you can create the same run without the tricks I found in 2012 and before that. The fact is, this run shows no new technical improvement except the fast Fireflower technique in 1-4 and fast jumping in the wall in 4-4 (which are both found through exhaustive search), and I think the way you say you figured most of this run out manually is somewhat an insult to my previous warpless run, as if you pretend it doesn't exist. Again, it doesn't take any imagination at all to replicate what's already done before (judging from the results).
It's entirely true that most sections of the run use techniques that were already used in 2012 by your previous run. And of course I knew about these techniques, and I'm not claiming to have "discovered" them on my own. I did disect how they worked, and whether they can be improved significantly, but most came back negative. This is not what I'm claiming is new and exciting about this run, the actual improvements over the previous run is what's important, in world 1, 4-4, and 6-4. I had mentioned before that the 1-4 technique was in fact not found using the tools, but by hand, just like you apparently found it. So your claim that it's inherently less impressive, or that less creativity or imagination went ito it, doesn't actually apply.
The wall clip technique in 4-4 is a bit more involved than you give it credit for as well. It is not only about clipping through the wall as quickly as possible, this can in fact be done even faster than shown in this submission. It is also about the relative scroll position of the screen, which matters for the ending cutscene, the correct alignment is necessary to save the decisive frame, so you need to balance going as fast as possible with not scrolling the screen too much. While the actual inputs that brought these extra pixels to make it work were computed by the tool, the planning that went into making the improvement work was not, and this is the part you were not seeing.
This is not about whether improvements found by automatic tools are inherently less impressive than those found by humans, I respectfully disagree with your opinion there but that's not the point. You are crediting the tools too much with these discoveries and are ignoring the human effort that went into this, the same effort you spent on your improvements. They are a "helper tool" just like you describe, and I understand that you wouldn't need them for SMB with all the experience you have, but they were useful to me. What they did not do though is finding these improvements by themselves.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
HappyLee wrote:
MrWint wrote:
The grand majority of time is spent on research, reading the game code, understanding how the game works, looking for exploitable mechanics or glitches, routing, trying different options. These are all things done by hand, things that require creativity and are not easily automatable (yet). To be fair, this submission shows very little of this work in the final result just because of how optimized it already was. The only improvement found by me (yes, manually) during this phase was the better mushroom collection route in world 1.
I do respect your work, MrWint, and I've learnt the story of how you've made this run through your submission text. But I don't know if you've read the submission text from my last warpless run in 2012 (I think maybe you should have since that's the run you were trying to obsolete?), there was a huge hint of World 1 new route during the "1-4" section:
HappyLee in 2012 wrote:
I've came up with a crazy idea once, that is to get the mushroom in 1-3 instead of 1-2, and then get the fire flower in 1-4. What really shocked me was that the idea almost saved 21 frames. Although I've tried my best to manage to get that flower in a quickest way, there are still about 3 more frames to go in order to save time. And since this new route would be a bit less entertaining, I still kept the old route.
So combine that knowledge with 1-4 fast getting Fireflower technique, you can easily get the improvement of World 1 new route. The hardest part is actually getting Fireflower in running speed, and you did that through your exhaustive search tools. As I said, improvements found by exhaustive search tools and improvements found by human TASers just don't feel and mean the same. So it actually doesn't take much creativity (except for the creativity to create exhaustive search tools) to discover World 1 new route if you had read my submission text.
Again, this is NOT a criticism of any kind. Just clearing some facts.
I think you still have some misunderstanding on how I created this run and what the tools I used can and can't do. So let me clear some facts for you. In short, what the exhausitve search does is remove the tedium, not the creativity.
For 1-4 for example, you are mixing up the time line here. Yes, you wrote in 2012 that you tried this and it didn't work out for you. But that is by no means the reason I found this improvement. And there was no knowledge about the fast fireflower technique whatsoever, since that was first published only with the "all items" TAS, way after I had already found this by myself (as the commit history shows). And I figured this out on a piece of graph paper, not with the exhausive search tools (which at that point were not capable of navigating a situation that complex yet). In fact I figured most of this run out manually, e.g. using spreadsheets to track Mario's jump heights for the floor clips. All the tools do is find the final inputs which do these moves optimally.
Claiming that it didn't take much creativity to find this just because you wrote a note in your submission text in 2012 is somewhat insulting. If it was so obvious, why didn't anybody else find it? Why didn't you find it back in 2012? I have tried to be accommodating so far, since I'm sorry for the unfortunate collision between this and your future submission. I'd be thrilled to see your submission succeed, but only on its merits. Please stop pushing your narrative of minimizing this run, its entertainment value, and belittling my contributions in it, just to make you and your prospective run look better. I'm looking forward to seeing it, and I have great respect for what you managed to achieve with SMB TASes so far, please refrain from petty tactics like this.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
I dislike the term "robot" to describe the tools I use to create runs like this, as it implies that I have somehow built a robot and told it to create this run for me, leaned back and submitted the result after it was done. This grossly misrepresents what went into the creation of this. The grand majority of time is spent on research, reading the game code, understanding how the game works, looking for exploitable mechanics or glitches, routing, trying different options. These are all things done by hand, things that require creativity and are not easily automatable (yet). To be fair, this submission shows very little of this work in the final result just because of how optimized it already was. The only improvement found by me (yes, manually) during this phase was the better mushroom collection route in world 1. But that didn't mean I took anything from the current run as granted, I looked into everything to see whether it can be improved rather than just copying the existing route (even though you can't really tell from the end result).
The tools only come in for the grunt work of actually figuring out the optimal inputs for individual sections when your route is already defined. And this is not rocket science, e.g. for this run it's a simple exhaustive search over the state space of Mario's movement in a section of a level, using standard search algorithms (IDA*) and data structures (basically Hash Maps). There is no secret sauce, no evil lair where I flip a giant switch and scream "IT LIVES". I enjoy building these tools and optimizing them to produce the results I want, and maybe my submissions revolve around them too much as a result (or maybe it's just an unusual feature of a run and people focus on it because of that), but this is not where the majority of effort is spent in the creation of these runs.
By making it sound like I create some machine overlords who will take all our TASing jobs, you imply that all the other aspects, the effort and creativity that goes into these, don't exist.
Small edit as in re-reading I noticed that is sounds way saltier than I meant it to, it's meant to be a mostly explanatory and humourous take on my perception of this debate.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
In the spirit of easing the tensions, I have removed the "movement optimizations" section from the submission text since, as HappyLee pointed out, it could be interpreted the wrong way. It was not meant to make his previous run look unoptimized (it isn't), but I can see how it can be interpreted this way.
happy_mario wrote:
[...]because many times the work we do is exhausting & testing all possibilities in some key jumps, which is so boring. Why not use tools to complete these limits, and then focus on the entertainment, or better game routes (especially the route that use glitches of the game).
Exactly. These are Tool-Assisted Speedruns, but people don't make enough use of these possibilities. The emulator and its capabilities are just one of the tools available to you, not the only one. You game contains a lot of tedious grinding and trial-and-error? Create a script that solves it for you! Want to know how to optimally play Dragster? Create a spreadsheet! For me, the design and creation of these tools to solve the problem is the actual interesting part in creating TASes, the notes and spreadsheets, deconstructing how the game actually works and exploiting that to the fullest.
HappyLee wrote:
Again, I think MrWint is clearly a genius on making bots, which is something I can't do, but using it on SMB warpless instead of less optimized runs (plenty out there) is confusing to me. It's like using a cannon to kill a pig for bacon.
At the time I thought it was a good idea, because of how optimized it already is, you can better judge how well you're doing. This was entirely new to me and I've tackled a problem like this before, so having a way to measure how good you're doing was very useful. Other aspects of SMB, like the frame rule and its fairly static nature made me wish I chose a different game in the end, but alas it was too late, and it was still great fun creating it. So the genuine answer is "I didn't know any better" I guess.
feos wrote:
So what's your take on the "individual levels" idea, where SMB runs would ignore frame rules and get measured by reaching some "magically agreed upon" level end point optimally, if such point ever existed?
I think that would take too much away from the game and make it boring to watch. To be frank, SMB is not the most appealing game to watch, it's a lot of the same. The best part of it are the crazy setups, like floor clips, vine glitch, etc, which only exist because the frames after the flag pole where you don't have control in are also important, and without it the game would devolve to be about holding right and B as much as possible.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
HappyLee wrote:
"8-4 turn-around pipe entry", obviously you were copying my movements from the "maximum coins" TAS or something.
Just to be clear, every single input in this run is my own, I have not copied anything, and I'm a bit saddened by this accusation. You can find the exact 8-4 inputs used in this run and the program that generates them reproducibly on GitHub.
One of the main points of this run was to look at how well optimized SMB is, and copying inputs would defeat this purpose entirely. The fact that this run in many places looks very similar to yours is a testiment to your skills.
HappyLee wrote:
In short, I didn't make that many mistakes during my last warpless run in 2012, but your submission text made it looks like that I had made plenty of mistakes. It's not fair to compare stylistic choices with maximum horizontal positions search. Nobody really cares for "0.125 frames" or something.
Ok, I'm sorry I have upset you with this, let me try to explain better. I'm not in any way saying that these were mistakes in your 2012 run or that my run is better because I saved a fraction of a frame that doesn't end up mattering. What I'm saying is that these represent potential, potential to make the run more entertaining (by spending the extra distance on entertaining moves), or potential to make the run faster (with possible other improvements in the future). Look at it this way: if it weren't for how the frame rules happen to align, the 4-4 improvement would just be a fractional frame like all the others. But any stage could become the next 4-4 when a new technique is found. Whether or not this potential is worth anything to improve a particular run (speed- or entertainment-wise) depends on your goal.
HappyLee wrote:
As for "2-2 whirlpool alignment", I didn't know it back in 2012, but who really cares? Doesn't save a frame or look like anything else.
Let's take 2-2 as an example: Yes, the whirlpool alignment doesn't save a frame, and likely never will, but it gives you a pixel more wiggle room, which can be used e.g. to shoot an enemy you otherwise couldn't reach, show off some movement that slows Mario down, etc. Or not at all, but in any case you're not losing anything by taking the optimal movement since it looks exactly like yours, otherwise you're just squandering potential that may or may not matter.
HappyLee wrote:
For example, I intentionally slowed down at "1-2 initial speed-up" for hitting the mushroom block (which you don't need to in this movie).
Fair, but fwiw your mushroom collection movement is slow by at least 0.1 frames as well, which may or may not be useful during the rest of the stage.
HappyLee wrote:
I intentionally stayed longer in the pipe during the pipe glitch in 3-1 as a stylistic choice, similarly for the 2-1 pipe clip. The way I do 3-2 floor clip and 7-1 pipe clips is also a stylistic choice.
I'm somewhat doubtful since the time you spend inside the pipes actually affects your relative screen position which is important fo the future enemy interactions, so your freedom is limited here, but I'll grant you that.
HappyLee wrote:
2-3 and 7-3 floor clips has to do with the Cheep-cheep.
Not true, the Cheep-Cheeps are actually fairly predictable and fixed, e.g. my 2-3 Cheep-Cheep is the exact same as yours, it's just about the way you do the clip.
HappyLee wrote:
Maybe you got better "8-2 Bullet Bill luck" but I got clearly more entertaining 8-2 as a whole.
These are not mutually exclusive. When I said "Bullet Bill luck", it is RNG manipulation, and you can theoretically have both.
HappyLee wrote:
"8-4 wall clip pipe entry", I just wanted to slow down before entering the pipe. Why do I have to go full speed before entering a pipe?
Well that's just straight-up false, you didn't slow down at all. Your method was slower because you were jumping, limiting your speed to walking speed. Sorry to say this, but I feel like you're not actually remembering your own run and which decisions you made and just making things up here.
You're very defensive about this, and I can understand that, as it probably feels like I'm "invading" your domain of SMB in some way. All of this is not an attack on you or your runs, and I'm not claiming that my run is better because of 0.1 frames here or there, it is merely a documentation on what's possible, something that can be useful in other runs.
HappyLee wrote:
Everything is already 100% known. There won't be much of a challenge. I can optimize everything precisely in SMB if I want to (don't need exhaustive search robots to do that).
That is a bold claim, especially considering 4-4. In general I feel like you overesitmate how "unbeatable" this new time is, you have spent so much time with this game that you feel you know everything, when it's clearly not the case. Considering both you and me have missed an improvement that the other one found, it's not unreasonable to think that we missed more, and that this is not in fact the end of the line. There's a lot of talking in this thread about what to do now that this category is at its limits, I'm just not 100% convinced it actually is.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
About the optimizations, that is fair criticism, as it is not always clear when a slowdown was because of artistic choice and when it was just sub-optimal play. However, I tried to only include situations in which it is obvious that there was no artistic choice involved, since the optimal movement looks exactly like the current one from the outside, just like you brought up in 4-4. If anything, you are missing out on entertainment value you could have by spending these extra pixels more productively. This is something you actually may want to look at for your TAS, as it may give you more room to provide even more entertaining gameplay.
If you think I miscategorized some of these though or you wonder how I got to these numbers, please let me know, I'm happy to correct the submission text or explain it in more detail.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
HappyLee wrote:
As I said, Mars608 and I had already finished planning and testing almost everything, so what's left to do is simply making every stage as perfectly as possible, which I think is not your strength since you didn't do it in this run. To be honest, I don't find your tools very useful in this project except solving the 4-4 puzzle. Most things you've explained in your submission text was already known back in 2012, and all of it except the 4-4 improvement was known to me and Mars608 by the time we were testing this run while making "all items" TAS. Your tools can be very much useful in other projects like Extra Mario Bros boss fights and Hard Relay Mario, and other games like SMB3, but I think for this project we don't need further use of it as we can do even better through our own imagination and reasoning. We just want to add you in the author's list to show respect, as you've spent lots of time into it. I'm sorry if you don't find it acceptable.
That's fine, thanks for your honesty. I propose you keep on working on your version of the warpless TAS then without me, no need to add me to the author's list, and submit it whenever you're ready. I'm fine with getting my run obsoleted by yours if it's significantly more entertaining in the eyes of the audience. I'm sorry for having made your submission harder with this.
I'm aware my tools and explanations probably weren't really exciting or new to you, but they were to me, and probably a lot of other people. Knowledge around the techniques and mechanics for SMB in particular and TASes in general is not well communicated and hard to come by, so I'm trying to spread the knowledge I gained and discoveries I made as best I can, even though they may have already been known by some.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
HappyLee wrote:
What you didn't mention in the submission text is that the 1-4 route won't save time without the little trick of getting the Fireflower in 25 speed found by Mars608 and first shown in our "all items" TAS. This is small but greatly important, so I can't believe that it's not mentioned in your well-detailed submission text. Actually it was first found in our new warpless project which had already started after I found the first time improvement.
I actually do explain that you need to keep running speed while collecting the fireflower, and I also mentioned you discovered it independently of me (in case you don't believe me, I submitted the exact 1-4 inputs used in this run to GitHub weeks before your submission of the "all items" TAS). I understand how it feels to you like I stole your discovery here, but that's not what happened.
HappyLee wrote:
Technically, we can submit a TAS right now with equal time but A LOT more entertaining, since Mars608 has already finished it in his way a week ago. Where would we be then? Then your work would become mostly an improvement in 4-4, which looks almost exactly like the same movement as my last run. But I don't want that, since we've always had a larger goal in mind.
We understand that your goal is to pursuit for the time limit, but our goal is beyond that, which is to create a perfect run with maximum entertainment. Please seriously consider joining our project if you think our goal makes sense. If you choose not to, we would still respect your decision. Me and Mars608 will probably stick to our original plan in slow pace no matter what happens, and hopefully would make a perfect run someday.
Ok, so I thought about our options a bit more, with some time passed and hopefully some more objectivity.
First of all, I'm happy to join you with your project to create an even better warpless TAS, but only if I actually can be helpful in the creation of whatever is left to do. I have already created the tools necessary to do precise optimizations, and I can apply them in furtherance of your project. It feels disingenuous to just join your project without actually contributing, maybe just to get this my submission out of the way of yours. I don't care too much about my name in the author's list, with my submissions I mostly seek closure, not recognition. The submission and publication is something to work towards at the end of the learning experience that is creating these TASes, but I wouldn't mind too much if they're obsoleted a few weeks or months later.
So here is my proposal on where to go from here: If you want, you give me an overview on where you are in your project, what is left to do, and we make a decision whether my involvement can be of use (ideally not in this thread though, to avoid spoilers for everyone else, maybe send me a PM and we go from there). If we come to the conclusion that I can't really help you in your endeavor, we'll do nothing, this submission is judged and maybe published, you continue to work on yours, take your time, and eventually try to obsolete mine based on superior entertainment value, as people in this thread have pointed out is possible, just unusual. If I can genuinely help your project, I'm of course glad to do so, and we can decide what to do with this submission when we're at this point.
Nach, as you're judging this submission, if you're bothered by the uncertainty around this and potentially wasting your time, let me know.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
HappyLee wrote:
It's a long story. In short, a Firebar in 6-4 can get in your way sometimes and kill 21 frames. It happens if you enter 6-4 a framerule eariler or a framerule later (how coincident is that!), and it's just unavoidable. I'm happy to send you our WIPs and explain our plans and thoughts on SMB warpless project in details if you're really interested.
I see, thanks for the explanation. I got to quickly test it out myself, and you're right, the Firebar is in your way, and the reason it is is because of the Podoboo RNG before that (The vertical speed of the Podoboo when it despawns determines the initial rotation of the firebar, and that Podoboo speed is RNG-dependent in the worst possible way, bound to the same interval timer as the frame rule is). I guess I got lucky there, not realizing that this could even happen.
HappyLee wrote:
If this run gets published, it would definitely sink our project because the unavoidable Firebar in 6-4 forbids us to make further time improvements, unless we find another time improvement, which is highly impossible as it's probably the very limit of SMB warpless TAS.
Improvements before 6-4 do become harder, but improvements after 6-4 are not affected. To be fair, that doesn't leave a lot of options.
HappyLee wrote:
Me and Mars608 would be really happy if you would join our project as a third author, so that our new warpless project would be more perfect even though the time wouldn't be improved due to 6-4 Firebar. Although I'm sorry to say, that your excellent 4-4 improvement might not be included in, unless we figure out an even better entertainment choice than my WIP spoiler. I mean, there could be a better place to waste 21 frames on. This can be discussed later.
Hmm, that is an interesting proposition, but I'm a little conflicted about this. I understand that this is a huge bummer for your project, and I sincerely hoped you would've had some improvements to just beat out my run. The way I imagined it would go after reading the comment in the "all items" TAS where you stated that the project is only progressing slowly, but you hinted at improvements I didn't know about, is that I'll just finish up my submission asap, possibly allowing you to incorporate the 4-4 improvement without too much backtracking, and you submit whenever you'll be ready, everyone it happy. The situation we're now in is really unfortunate, but you also need to look at it from my perspective, I worked on this run for the past year, leading up to this submission, and just backing down and effectively throwing this away for a mention in a run that may have none of my inputs and work I put into it in it, for an unclear benefit to the end product, is hard to accept. I guess I'll need to think about this some more, how we can solve this unfortunate situation in a satisfactory way.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
Amazing work, the precision down to individual CPU cycles necessary to make this work is really impressive. I'm happy a setup to exploit the TFly in Viridian Forest to trigger ACE has finally been found, I remember I looked at that a few years ago. I'm not surprised I didn't find anything, seeing now how it works and how it was discovered.
Congratulations on this run. Seeing this makes me want to return to this game, but I'm rusty and would need to catch up on a lot of things.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
HappyLee wrote:
Wow, this one's totally unexpected. Mars608 just told me that someone broke the 4-4 framerule, and I said "What? I justed tested that a week ago." And I watched 4-4 and just learned that it's possible to jump early in the wall so Mario can land a frame early. Why didn't I think of that? Congratulations on solving the 4-4 puzzle that me and Mars608 didn't solve.
Too bad that the time me and Mars608 were going to submit is exactly the same as yours, 18:37.46. Mars608 has finished everything including the hardest parts like 7-1, getting 7-3 Cheep-cheep and manipulating 8-2 Bullet Bill a week ago. He respected me and let me move on with my slow pace. I told him that I need time to make every stage perfect, to make a perfect warpless TAS as it will probably be the last.
If Mars608 were the project manager, he would most likely submit the same time result even before "all items" TAS but in higher quality. But he respected me with my slow pace. And I couldn't imagine that my slow pace could completely ruin our project which was already 2/3 done. Months of work now ruined because it won't matter with a tied run in time.
Yes, there's one more improvement that you didn't calculated, MrWint. An improvement I thought probably the most incredible improvement in SMB TASing. So why couldn't this time be improved? Damn unavoidable 6-4 Firebar!
I sorry to hear that, I didn't realize quite how far along you were as well. As I mentioned in the submission text, it was just bad timing and I didn't know you were working on it until 2 weeks ago.
But there's something I don't understand, you're saying you would have submitted the same time as this run, but you didn't beat the 4-4 frame rule. Does that mean you have a frame rule improvement in a different level then? And can these be combined to create a run that uses both improvements for another 21 frames saved? If that's the case, I didn't sink your run completely (which would be a relief), but merely threw it back since you need to go back and redo everything from 4-4 onwards, incorporating my improvement into your run.
Also, can you elaborate on what you mean with the 6-4 firebar? It wasn't very memorable to me, so clearly I'm missing something.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
Nach wrote:
It basically is reject immediately unless the submission itself or the audience defend its reasons for publication explaining how it's unique or better for whatever viable reason.
Ok, so if it's better in some valid way it would be enough. How much better is enough will depend on the specific case, so I don't think there's much of a point discussing this without a more concrete example, and I don't intend to hunt for one to dig deeper in the near future.
Thanks for being patient with me, I learned a lot in this discussion about the site's rules and philosophy, and while I don't agree with some details (basically anything involving the Vault tier), they're still reasonable and I don't see a pressing reason to seek any change right now. I'll back out of this discussion, and look for a less controversial next project.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
Nach wrote:
Personally, I am against the Vault tier, and dislike notions of video publications for record keeping. I watch our players' content for entertainment, not because it's some record. If I want to know about some record, then I'd prefer a table of data over a video. I think the Vault ends up containing a bunch of entertaining stuff that doesn't belong there. Also, Warp correctly argues that any speed record is a speed record, and then if Vault is supposed to represent speed records, why are entertaining speed records not in it? When you think about it, speed records should really be getting some kind of badge or trophy or something appearing on the movie publication (which I have no objection to). The tier system has a lot of weird rough edges to it.
Interesting, this seems to contradict the explicit stated purpose of the Vault tier: "The Vault is a new category of movies we have added. Previously we only published movies people found entertaining, now we also publish movies in this category for record-keeping purposes." and "Its focus is exclusively on collecting tool-assisted speedrun records.". I presume your personal dislike is another instance of being in the minority then.
I agree with some of your complaints about using publications for record-keeping, it doesn't seem to be the right format for it the same way it is for other tiers. But it's a problem you could solve, I don't think people are necessarily looking for a publication for all these speed records, they're looking for a place to track them in some way. That table of data you describe doesn't exist (afaik), and people are looking for TASVideos as the place that provides it (see recent-ish topic in the same direction).
I think the root of the problem is that the Vault category is somewhat ill-defined, as "anything that didn't make it into the other Tiers but is still a speed record", which also creates the weird overlap with speed record which are entertaining and potentially eligible for higher tiers.
It's a design flaw in the Vault tier itself, a better system may be to consider speed records a separate dimension orthogonal to the entertainment-focused Moons and Stars rather than a lower tier that exists alongside them. That way published runs that also happen to be speed records can be both (recognized with some kind of badge or trophy if you like), and speed records that don't make it into the Moons tier can still be listed (with no or some light-weight publication).
I understand the reasoning for not accepting just all submissions which go for a speed record, you want to keep some quality standards and even the lightest resonable approval proccess will still need to spend a sizable amount of time verifying each submission even without publication (there would be ways to make it less moderated and more democratized though), but that doesn't explain why e.g. the SMB PAL run was ineligible (this too was not mentioned in the judge's notes), you already did all the work investigating it closely. Just because it's entertaining doesn't mean it can't be Vault (at least according to the current rules). It seems to fit well with the purpose of the Vault tier, even though I agree it's a shame to see it ending up there.
Nach wrote:
For the phrasing itself, I prefer "not allowed" over "not preferred" because it makes things simpler. Don't bother with a PAL game unless you know it's the only or it's substantially different. A weaker wording like "not preferred" will just lead to a lot more submissions that will be rejected, and players will feel they had no warning.
Suppose I submit a PAL TAS (any%) for a game which also has an NTSC version (released first, no prior submissions for either), and they are generally similar with only minor differences (both well made, etc.). I chose PAL because it had a minor neat trick I wanted to show off, I deemed it the more interesting version to TAS, or maybe it was simply faster (by some definition) than the NTSC version. Would you reject it just for being PAL and not substantially different from the NTSC version? I assume the answer is "maybe", depending on which is the "better" version (TASability, quality and such) and how the audience feels about it. I want the rules to reflect that, because currently they sound like a firm "yes, reject immediately" to me.
I get your point about clarity being important, but there has to be a balance between being clear and being overly restrictive.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
Thanks Nach, that was a really insightful. I can see how making decisions on a submission level can make the rules harder to understand and predict.
I still somewhat disagree with combining branches when comparing games (e.g. imo World 2 and World 7 differences are irrelevant for a warped run), and it shouldn't make the rules any harder to understand, you typically know which branch your run will fall into when creating it and which game version typically is used for that. To be fair though, the flexibility you'd gain will rarely be used and may not outweigh the rule verbosity and complexity it adds.
I wasn't aware that by the current guidelines any branch is basically fixed in which game version it uses once the first run is accepted (not counting "compatible" games like in the Pokémon Gen I case). This of course makes all the discussions about comparing different games obsolete, and is a valid way to dodge all the muddiness that would come with it. And it also resolves most of the discussions we had so far, and why I couldn't get the non-existing criteria out of you.
Since we had most of the discussion over this simple misunderstanding, I'd suggest to call this fact out in the movie rules explicitly, because afaics it is not at the moment. Something like "You can only obsolete a movie using the same game version" (with some caveates for compatible games, maybe with an example), or "Submissions using a different version of the game than the currently published movies need to contain significant differences that warrant a separate category, they can not obsolete existing publications".
Nach wrote:
MrWint wrote:
My current best suggestion for cases where it's just too difficult to determine the preferred submission based on defensible criteria is to reconsider putting them into different branches. Given that these cases should be exceedingly rare, it shouldn't create too much bloat in the branches.
My persounal oupinion is tou have it as a different publication. Houwever my judgment was nout based oun my ouwn preferences. I rejected a run that I really liked.
You have mentioned multiple times now that your preferences and the site's rules diverge in some points. Is that because your opinion is in the minority among other people who have a say in this, or because your opinion as the Site Manager and your personal opinion diverge? Rules can have exceptions...
I'd argue that TASVideos is also seen by many as a place of record-keeping, and the existence of the Vault tier reflects that. While not meant for these kinds of runs, it fulfilles all the requirements to be published in the Vault tier, as long as you accept that it looks similar to a run in a different tier. Given the seminal importance of this game, you may be able to spare a branch.
Accepting it for all games, as ais523 suggests, may be too much given the current publishing process. On the other hand, you could have a lighter-weight publication process for these to compensate if you wanted to (or not publish them at all, and use the submissions as the records you keep, just making them more discoverable).
In the end it's a matter of where you want this site to be positioned for record-keeping for TASes. You can take the position that these don't belong here, and maybe another site will pick that up and provide that record-keeping service instead, but I'm not aware of any so far.
From my perspective, most of the confusion is cleared up now. In order for this to not feel like a complete waste of everyone's time, I propose some wording changes to the rules to add some clarity and hopefully avoid similar discussions based on wrong assumptions.
Adding a sentence stating that obsoletion requires the same game version as mentioned above.
Rephrasing the "PAL versions of ROMs are generally not allowed" part, even back to "PAL versions of ROMs are generally not preferred" would probably be good enough.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
I don't want to define preference at a game level, I don't think that's possible. The preference may change over time with new submissions. If an impressive new strategy or glitch is found that only works in some versions, it may change the preference towards that previously inferior version, without necessarily requiring a new branch.
Also, I retracted sales and popularity in a previous post, you were right that audience preference is the actual metric and sales and popularity are only proxies for it.
So the three factors so far are:
audience preference
audiovisual quality
speed (this too may be seen only as a proxy for audience preference, depending on how you want to look at it)
and only audiovisual quality is mostly inherent to the version, not the submission. Audience preference may be bound to the version as well, but individual submissions may sway people.
My main complaint is that I think in the current rules there are other factors that shouldn't be there, specifically factors that inherently prefer NTSC over PAL outside those three factors that would naturally prefer NTSC in cases where it makes sense (aka most cases).
I'm sorry to go on about this, but the SMB PAL submission is the best example I have of this right now. I have read the judge's notes and especially the decision tree again, and I think part of the problem is that it was a two-step process. You considered obsoletion first, brushed it aside as lunacy, and then considered opening up a new branch for it. The result was that it doesn't deserve one (which is understandable), and hence was rejected.
I'm looking at it in opposite order: you first decide that it is too similar to the NTSC version first so they compete with another and you need to pick a favourite out of the two. Then you need to justify which of the two it is, and this is where the criteria I'm trying to formalize come in. They are not sufficently mentioned in the notes (since considering things in the other order made it easy to skip over them), and you have successfully avoided my attempts to get them out of you so far by saying they were not comparable and just different games.
My initial suspicions when reading the judgment hence were that some of these factors played a role in it as well which I'd describe as questionable:
Prefer the currently published run (this is not totally unreasonable actually if the goal is to conserve publishing resources)
Prefer the run done in the original version (as mentioned e.g. here)
I'd be happy to hear that these weren't factors, and which factors were used instead, as an example of how rulings like these are made currently. The fact that the notes didn't spend any time discussing these led to some of the outcry and my bold claim (which I'm still sorry for) that maybe it wasn't actually considered well enough when the decision was made.
I totally admit that the factors I'm mentioning above not necessarily make for consistent rules (e.g. speed is hard to compare between versions, and relying on the audience preference too heavily may be problematic since people tend to like new things, so you may end up unreasonably obsoleting back and forth between versions on new submissions). These are just inherently tricky cases which are hard to judge. At this point I'm trying to understand how these difficult decisions are made right now, and I was hoping the SMB PAL submission would help with that.
My current best suggestion for cases where it's just too difficult to determine the preferred submission based on defensible criteria is to reconsider putting them into different branches. Given that these cases should be exceedingly rare, it shouldn't create too much bloat in the branches.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
I don't think the question is whether it is a different game or not. Suppose it is a different game by that definition, like in the SMB case. How do you decide which gets published now? You decided against publishing both, so you need to decide for one or the other. That decision is what I'm interested in, and the criteria used to decide it.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
In the scenario we're discussing (games which have technical differences but have a very similar look and feel) I think acceptance and obsoletion end up being the same. Since introducing another branch would create unwanted redundancies, the only way it gets accepted is by obsoleting the existing movie (if any). And as mentioned before, I only consider that specific branch, not the game in general (other branches may have different outcomes).
You're not really doing any better in terms of clarity though, regarding comparability, what does it mean? Comparing time? Audience response? Version quality?
Having versions that are not comparable (assuming it means that there's no way to choose a better or worse version out of the two) in the same publication slot is not very satisfying.
In this case, it seems you decided to stick with the currently published version. But does the version that is published first always win? If the currently published version were PAL and the new submission NTSC, would you stick to the published PAL version then?
I think there should be a preferred version in all cases where two runs end up in the same publication slot, and I'm trying to formalize what this decision would be based on. If we absolutely can't find a way, it's a sign they should be separate categories then, to avoid that awkward middle ground.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
Nach wrote:
I'd also point out towards your earlier point, that if speed of games are being considered for audience preference without getting into the particulars of any given run, you need to factor in all branches (such as stuff like walkathon and warpless in your example case). Which increases the amount of technically different factors to consider in determining which is faster, which can make different branches have different outcomes, sometimes non-intuitively.
It sounds like you're implying that the preferred version of a game should be determined independently of the branches. I disagree, I think it's entirely reasonable for different branches to have different preferred versions, so there's no need to factor in all branches when making these decisions. E.g., the SMB warped category I think PAL is a reasonable alternative to NTSC, whereas for warpless you'd lose a lot of entertainment value by cutting out the flag pole glitch setups.
Nach wrote:
MrWint wrote:
Reading the rules in context of our discussions so far, I actually don't think it's unreasonable to state a general preference for NTSC ROMs, but this is only on the basis that they are likely to have a better audience response (because of their popularity), and that PAL ROMs tend to be broken because of the compensation for different clock speeds. Disallowing them in general unless special conditions are met is a step too far in my opinion. I think this could be fixed just by rephrasing the section, explaining that PAL ROMs are in fact allowed, but all the caveats apply so the NTSC version is the better choice in most cases. The current wording sends the wrong signals, and it causes rulings based on rules that should be guidelines.
I think a key point people are missing is that with the way the rules are structured currently, games which have technical differences but have a very similar look and feel will basically always prefer NTSC unless there is something immensely significant altering things in favor of PAL.
I think you hit on the main issue I see with the current rules here. For games which have technical differences but have a very similar look and feel, PAL doesn't need any "immensely significant altering things" in order to be favored, it just needs to be preferred considering all the aspects we discussed already. I don't think that will change the outcomes of most decisions, the NTSC version will be the preferred version for almost all games, but that is not because it is the "default" version, but becasue it wins out against the other versions when comparing the relevant criteria.
In the judge's notes of the SMB PAL TAS, I expected to find such a comparison of the games for this game and this branch specifically, but they completely skipped that and only discussed a separate category as an option, giving the impression (reinforced by the infamous "lunacy" quote) that there was no debate and NTSC is just the default version. I didn't expect the PAL version to win, but I expected it to be considered.
My proposal to remedy this is to avoid statements like "PAL versions of ROMs are generally not allowed" in the Movie Rules, and rather state the aspects that need to be considered, and possible caveats of using PAL versions (most of these things are mentioned already). Since NTSC will be the winner in that comparison for most games and branches, stating a general preference for NTSC is useful to guide people to using the right version without forcing them to do in-depth comparisons, but only as a guideline, not as a rule.
feos wrote:
MrWint wrote:
logic dictates that when you are left with only flawed answers, it's not the question that is flawed but one of the assumptions you made along the way
You can't claim my statement is sophistry without any arguments why is it flawed or why the question doesn't make sense in that context. Questions with only impossible answers are not automatically a sophism. I maintain that this is a perfectly valid proof by contradiction. Our argument itself has been resolved in my eyes though.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
I checked out your analysis, and there are several minor issues with it.
Firstly, your measuerments are off by a frame or two for some of the segments. For some endings (esp. flag pole endings), you count a frame too many, and for NTSC 1-1 seg 2 you counted 2 frame too few (just because the inputs stop doesn't mean the playable time stops).
This may seem irrelevant if you counted them wrong consistently, but it's not because PAL frames and NTSC frames have different lengths, so counting a frame extra for each adds more time to PAL than NTSC.
I've made a copy of your spreadsheet with the corrected times, highlighting the changes: https://docs.google.com/spreadsheets/d/1Ov8yMWwzbS0P0UShMPe6tH84E0tNgYOxgh-zGpoXHJc/edit?usp=sharing
Secondly, your conversion from frames to seconds for PAL used a constant that was slightly off (not only because of rounding). I decided I had enough of rounding discussions, so I replaced them with the exact fractions so the values are guaranteed to be accurate (Well, in theory, not dealing with the messiness of the real world). The spreadsheet still shows them as a rounded decimal, but if you want to get really exact you could calculate the exact difference (as a fraction) between NTSC and PAL.
Thirdly and probably most problematically, the IGT runs you were basing the measurements off are blatantly suboptimal. For example, the PAL 1-1 seg 1 loses 2 frames right away. Also, in NTSC 8-1 and PAL 8-3 you started playing a frame late, losing a frame standing and doing nothing. I noted in the spreadsheet where I for sure know you could save frames, based on existing TASes. There are more spots where I strongly suspect you could save more frames, but I didn't note them to avoid spreading false information.
That said, I don't expect these issues to change the overall conclusion. I could try to create more optimized IGT runs to get more precise numbers if people are interested, but I don't think they'll provide any significant new insights.
As a side note, I don't understand your exclusion of the 1-1 pipes as an alternative calculation. What purpose does it serve? Why not exclude the 8-4 pipes as well then?
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
Nach wrote:
MrWint wrote:
I don't think it matters how large their differences technically are. It may be a 1.0 vs. 1.1 version of the otherwise same title, or it may be a port for a completely different system altogether, with a different underlying engine and everything. The important point is that they have the same goals, use similar means to achieve them, and provide a similar viewing experience
I think how large the differences technically are is the primary crucial point, and is in fact a foundation of TASing philosophy. Please see my above response to Warp and link.
I need to clarify here, I agree that the technical details and differences are very important when making a TAS (I hadn't created the SMB disassembly if I thought the techincal differences are not important). What I was talking about is the way I perceive TASVideos chooses categories and which runs potentially share a slot and compete with each other for publication. If you have a straight SNES remake of a NES game, then iiuc they usually compete for a slot, at most one is published to avoid redundancy. The PAL SMB run was rejected not because it was objectively bad, but because it competed with the existing NTSC publication and lost.
Nach wrote:
Two runs for a single game or two similar games each with their own run? I assume you mean the latter, as the former makes little sense in the context.
This gets into a number of issues regarding quality of the game, TAS itself, popularity, audience response. I think most of the time we should strive for both. If they're too similar and absolutely cannot do both, I'd personally prioritize:
Highest quality game version (most potential for TASability and good audience feedback)
Version preferred by majority of audience
Audiovisual quality of the version
I define TASability as including ability to complete the games in multiple ways, many tradeoffs which require study and planning, much depth that has a near infinite supply of finding new things, ways to perform entertaining action often.
The following suggested criteria I would not consider at all not even one iota:
Fastest time
Version popularity/sales
Which version was published first on TASVideos
Which version was released first to market
I wouldn't consider any of them because fastest time for some run in some branch, most sales, first to publish, and first to market have 0 affect on the game's quality or its overall TAS potential.
Ok, I need to apologize for conflating two concepts into one, comparing two versions of a game and comparing two runs (submissions) of a game (possibly using different versions). Also, I mixed version popularity and preferred by majority of audience, I agree that your nomenclature makes more sense and it reflects what I actually meant when I said version popularity (and adding "sales" as an afterthought didn't make it any better).
However, I want to challenge your statement that fastest time is not a factor at all. When considering the Pokémon Gen1 SRAM movie, which used Red to obsolete Yellow, I'd argue that time was a major factor. The run features no major new tricks, and is admittedly a downgrade visually from GBC to GB, so you could argue it used an inferior version of the game. Of course this run is almost exclusively based on technical details and the entertainment value is limited anyway. The audience response was pretty positive, but that is only because it was faster.
I can see the argument that the fastest time is only a means that as no impact by itself and the audience response is what actually matters (like game sales don't mean anything by themselves but usually drive audience preferences which do matter). On the other hand you promote time as a factor heavily on TASVideos, when I visit the home page of TASVideos, the information I'm presented with for all the listed runs is the name of the game, the category, and the time, so in a way you are promoting time as a driver for audience response.
How time is factored into the judgement is actually besides the point I'm trying to make, so I'll stop rambling about it. I'm interested in how you reconcile your statement that which version was released first to market has no impact with your statements on the originality of NTSC SMB as a reason to prefer it over the PAL version (e.g. here), as well as the Movie Rules which state that PAL ROMs are generally not allowed unless there are significant merits.
Reading the rules in context of our discussions so far, I actually don't think it's unreasonable to state a general preference for NTSC ROMs, but this is only on the basis that they are likely to have a better audience response (because of their popularity), and that PAL ROMs tend to be broken because of the compensation for different clock speeds. Disallowing them in general unless special conditions are met is a step too far in my opinion. I think this could be fixed just by rephrasing the section, explaining that PAL ROMs are in fact allowed, but all the caveats apply so the NTSC version is the better choice in most cases. The current wording sends the wrong signals, and it causes rulings based on rules that should be guidelines.
feos wrote:
MrWint wrote:
I agree that a submission should not focus only on speed if it is to be considered for higher tiers, but that's not the point I'm trying to make. My point is that PAL runs shouldn't be under any higher pressure to deliver that NTSC runs, independent of the tier. Just because the new sumbission happens to be on the PAL version, it shouldn't be held to higher standards or have something expectional in it, a simple improvement (considering all aspects) is good enough. Again, all the usual caveats apply, they should be good versions and provide similar experiences.
Using the case-by-case based approach doesn't add any extra pressure. If the audience and the judges find the PAL version worth a replacement, it is justified. Replacing regardless of people's opinions just because something is faster is questionable exactly because of that: Why are we even doing it that way if it's not what people prefer?
That's not at all what I meant. When I said "improvement", it may not only mean a faster time, but can also mean better audience response, technical excellence, or other things. Just a better run in whichever ways is appropriate for the category and tier, just like an improvement using the same game version would.
feos wrote:
MrWint wrote:
If you wouldn't expect that, it points to the bias for NTSC and original versions that I'm arguing should be dropped. If you would expect it, then you're creating an environment where whatever version got published first has a large advantage, where it's easy to publish improvements on that version but not any different one, regardless of any other factors. This seems arbitrary to me.
You're asking me a Yes or No question and telling me that both answers are flawed? I'd say the question is flawed :P
Actually no, logic dictates that when you are left with only flawed answers, it's not the question that is flawed but one of the assumptions you made along the way. You can see the question as rhetorical, it was a tool to make my point that having a double standard for NTSC and PAL creates these impossible situations, thus showing the premise itself must be flawed.
I'm still somewhat interested in an answer to the question actually, in order to get to the bottom of our disagreement, because either you actually disagree with the premise yourself and this is just a misunderstanding, or you are disagreeing with one of my interpretations of the results I described as flawed, and see this as a preferable outcome instead, which hopefully leads to more insights into the nature of our disagreement. I could have asked the question without giving my interpretation of the answers straight away, but I figured this is the more efficient way of communication given the roundtrip time. If this appeared mocking or demeaning to you, this was not at all my intention.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
feos wrote:
When we switch to PAL where no branch diversity is involved, which means a vaultable branch like any% or 100%, I insist on the superiority requirement, reflecting some or several parts of the PAL release that are better: media, gameplay, difficulty, challenge, glitches, routes, etc. As long as the run goes to Moons despite of being a vaultable branch, these factors should outweigh speed, because we want it to be as impressive as it can be.
I agree that a submission should not focus only on speed if it is to be considered for higher tiers, but that's not the point I'm trying to make. My point is that PAL runs shouldn't be under any higher pressure to deliver that NTSC runs, independent of the tier. Just because the new sumbission happens to be on the PAL version, it shouldn't be held to higher standards or have something expectional in it, a simple improvement (considering all aspects) is good enough. Again, all the usual caveats apply, they should be good versions and provide similar experiences.
Maybe think of it the other way. If there is an already published PAL version, and someone tried to obsolete it with an NTSC version (and the NTSC version happened to be released first), would you expect the same level of strict superiority and strictly better media, gameplay, difficulty, challenge, glitches, routes, etc?
If you wouldn't expect that, it points to the bias for NTSC and original versions that I'm arguing should be dropped. If you would expect it, then you're creating an environment where whatever version got published first has a large advantage, where it's easy to publish improvements on that version but not any different one, regardless of any other factors. This seems arbitrary to me.
I admit that this is hard to see when you don't have an example where this would be applied, maybe there is none and the whole discussion is moot (because all PAL ports are either bad or strictly slower), that's why I tried to present this as part of a submission that illustrates it (and failed). It will likely be a case-by-case decision and maybe it's just not worth discussing this possibility if such a case never occurs, but this is also a chicken-and-egg problem where the current rules discourage it from ever happening.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
Since I in some way feel responsible this mess (I didn't start it, but I would have if HappyLee didn't do it before me), I'd like to explain my reasoning why I thought this was a good idea, why I think the rules should be changed and how.
My line of argument is along the lines of what Alyosha already brought up. I'm not against the policy to keep the number of branches small, the point that I don't agree with is the inherent preference of NTSC over PAL to resolve conflicts for similar runs.
But I think it's useful to step back from NTSC vs. PAL and look at how different versions of a game in general should be (and partly are already) treated. All of this is for runs that aim to get the fastest time, with entertainment value as a secondary goal.
I don't think it matters how large their differences technically are. It may be a 1.0 vs. 1.1 version of the otherwise same title, or it may be a port for a completely different system altogether, with a different underlying engine and everything. The important point is that they have the same goals, use similar means to achieve them, and provide a similar viewing experience, so only one of them can be published according to current guidelines (this explicitly excludes cases where they use significant version-specific glitches and the like, or contain significant version-specific content, and can be considered different categories).
There are of course obvious no-gos where one version is clearly superior to the other, e.g. when one of the versions is broken in a way that compromises the gameplay experience, and we only focus on the cases where both versions are official releases, reasonably well done compared to each other and offer similar gameplay and viewing experiences when trying to achieve their goal.
So assuming we have two runs that conflict with each other in this way, which one should be published?
In my opinion, this consideration should include (in rough order of importance):
- Fastest time (modulo trivial version differences)
- Audience response/Entertainment value (weight depends on publishing tier)
- Audiovisual quality of the version
- Relative version popularity/sales
It specifically should not include:
- Which version was published first on tasvideos.org
- Which version was released first to market (aka the "original")
The current Guidelines (as I understand them) reflect most of this, except for the last point, they prefer originals over later versions. This is something I have discussed with Nach a little already in the SMB thread that started this, I don't think being the original is by itself a reason to prefer one version over the other. It usually comes with one of the reasons that I think are valid reasons, like superior gameplay or higher popularity, but it's not a reason by itself.
The main reason for this practice that was discussed so far (and that I think is flawed, see my reasoning here and in following posts), is that differences in later versions of the games are deviations from the original developer intentions, so the original that stays truer to the developer intentions is to be preferred (please correct me if I'm misrepresenting the argument).
I'm not aware of any other main arguments for this preference so far, but I'm happy to hear them.
My proposal for a rule change is simply to not consider originality as a factor anymore, or at least demote its importance heavily. Applying this to NTSC vs. PAL, it means that (assuming all the conditions mentioned initially are met), PAL and NTSC versions are equivalent and can obsolete each other.
That of course doesn't mean that they always should, there are still all these other factors, just that there is no inherent bias. I think my main mistake was trying to use SMB1 as an example to make this point, I underestimated how much people love their childhood memories with that game which most of them played on the NTSC version, and what seminal role it has on this site to convey a relatable entry to understanding what TASes are about, so people had a hard time even entertaining the thought of obsoleting it for a faster non-NTSC version.
I had no illusions that it would actually be obsoleted (the outcome I anticipated was that it gets published alongside as a special case because of NTSC SMB's special role and history), but it failed to incite the debate I wanted to have and the change I wanted to provoke, and just provoked a lot of angry shouting instead.
I'm happy that we can have this discussion here instead now, in a more abstract and less emotionally heated environment.
Experienced Forum User, Published Author, Skilled player
(1020)
Joined: 7/24/2013
Posts: 175
Nach wrote:
MrWint wrote:
Speaking of trusting my numbers, the table I posted is a straight export of a spreadsheet with only formatting adjustments. The times are rounded to the nearest millisecond. The frequencies used are 60.0988138974405 for NTSC and 50.0069789081886 for PAL. Can you point to one of the inconsistencies you saw?
Sure, for first part of 1-1 NTSC, you have FPS as 60.10125755348685285, for the next part it's 60.09745533297238766, meanwhile 8-2 is 60.09963040334243934. So either I'm not doing my math right, my calculator is broken, or there's some fishy rounding or other issues with the numbers you posted.
I can reassure you your math is correct, I can confirm I get the same results. However, that's just a side affect of rounding the times to the nearest millisecond. If you try to calculate the FPS from the rounded times, you'll get slighly different results depending on whether the time was rounded up or down.
For example, the first part of 1-1 is 6.12324896507937s, rounded down to 6.123s, while the secon part is 1.84695824761905s, rounded up to 1.847s. No fishy business going on. You can calculate the exact numbers yourself using the frames and factors I provided, to check that's it's only rounding errors.
