I dunno; in the specific example mentioned, I don't really see how that's different from using a save game in a game that doesn't save exact stats.
But it does still feel kinda weird.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I find it laughable that when you make up a list of top TASers, I somehow end up at the top despite having TASed a grand total of about 75% of one level of a NES game. :) Also, I'm from Spain, apparently.
The overall concept seems sound, even though I could pick nits with the specific implementation (e.g. encouraging people to TAS never-before-TASed games could get a lot of crap games on the workbench; not all games are equivalently easy to TAS, etc.). The main goal, of getting more people to make TASes, is definitely something I can agree with.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Idly, would SMB/SMB2J work well for a dual run? Given the simplicity in controls, it becomes harder to pull the tricks that let you "desynchronize" the controls like is frequently done in the other multirun TASes (e.g. pressing L/R while going through a door, hitting down vs. left/right when paused), which would make it more obvious that the player really is controlling two games simultaneously.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
If I recall correctly, Tails can damage things by hitting them from below when he's flying.
Otherwise there's a boss in Sonic 3 that he'd be totally unable to defeat.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Thanks for the encode, Nineko!
Looks very solid to me. And you didn't fly over all that many levels...except for all of Marble Garden and most of Spring Yard...um. Anyway, nice work.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
You can prove software correctness. It's such a pain to do that normally nobody bothers, but it's a requirement for some government programs. For example, the software that ran the Space Shuttle back in the day was proven to be correct.
Similarly, you could in theory prove the maximal speed of a TAS without having to brute-force every combination of inputs. Given that the latter would require 2^8^N repetitions (I think) to generate N frames of input for a controller with 8 buttons, I doubt we'll be brute-forcing entire movies anytime soon. :)
For comparison purposes, 3 frames of this would be
134078079299425970995740249982058461274793
658205923933777235614437217640300735469768
018742981669034276900318581864860508537538
82811946569946433649006084096
repetitions. That's 1.34 * 10^154!
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
There are noticeable amounts of TASing in SMB, but the gains are slight; each thing that a viewer might recognize as "hunh, that's kinda weird" is gaining only a couple dozen frames at the very most. Compare that to the gains in Mario 64 where a level portal is bypassed, humanly impossible paths are used through many levels, and so on, and the difference that TASing makes is quite clear.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
There's a difference, though, between "An improvement was found mid-run that would require redoing a lot of work" and "I know there's a faster way to do this but I'm not going to use it because I don't want to tip my hand." Many of the possible improvements in this run are of the latter type, which is what's causing most of the argument (the remainder stems from Saturn's use of absolutes and superlatives when discussing his work).
As for not moving around vs. Mother Brain, I assume you're talking about the bit where Samus is crouching and kinda breathing heavily while the Metroid eats Mother Brain's cranium? That's a cutscene. You can't move during it unless you employ glitches that require more gear than he has.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
So, what, he should have gone and bothered a moderator just because he thought your behavior was inappropriate? There's degrees of chastising, and moderators, for ill or good, can only really bring out the big guns -- either they ban you outright, or they have to tell you that your behavior's inappropriate, which is as good as a threat of banning. There's no "Okay, you get a time-out for ten minutes to think about what you said."
If you're free to belittle Warp, and he's free to insult you, then blahmoomoo is free to call fie on you both. A little social censure won't kill you.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
In short, if you're happy with the OS you have, why should you upgrade? Until you see a feature that makes you go "Oh, hey, I want that" enough to be worth the cost of a) buying the new system, and b) undergoing the effort of upgrading (with the concommittant risk of breaking things), there is quite literally no reason to upgrade.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
RSS feeds basically are ways to get updates without having to visit the site in question. So for example, you could subscribe to all of the feeds for all of the sites you are interested in, go to your feed aggregation page, and see all of the updates for all of those sites in one place.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Sorry, FatRatKnight; you do exist! However, it's nontrivial for me to watch WIPs on my Mac here, so I tend to just pass on them, leaving me nothing to do but comment on what other people have said. And I don't have the in-depth knowledge of the game to be able to judge your suggestions for possible evolutionary paths.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I don't see the caveman morph as adding anything particularly significant to the run, especially since the vast majority of the game would be the same. In fact, I'd say it's more entertaining that Gaea's partner-for-eternity is an angry little rodent.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I'd like to point out two things:
* For option 1, another downside is that Bisqwit has to take a more hands-on approach to watching the workbench/newly-published movies. Much of the point of adding moderators was for them to be able to handle the day-to-day running of the site without his involvement. In general, depending on a single person to handle something that could change regularly is asking for stagnation.
* For option 2, you now need to get many more "blessed" people involved with studying the movie than currently. What happens if you can only find two of the star-selectors willing to take the time to watch the movie? Do you stage another election? What if you'd just run one?
So here's my suggestion: let the moderators (+Bisqwit) decide amongst themselves about stars. Maybe add in a few "regular people" who are well-known and trusted to be impartial to this group; selection into the group would be by informal nomination. One of them nominates a movie to be starred, they all watch it at some point, and decide via informal debate if it should be starred or not.
The important differences between this and Moozooh's #2 are:
* Starring is explicitly done orthogonally to normal publishing. Moozooh may have intended this to be the case in his suggestion as well; I'm just making it clear. Publishing a movie should not be gated on getting the star-selectors together to discuss a movie.
* Not every published movie needs the star-selectors' input. It's assumed that the people in that group are, between them, able to watch every movie that goes by and decide on which ones are worthy of discussion, without having to have every individual member involved on a daily basis.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Perhaps some sort of mechanism to allow users to stack-rank the currently-starred items would be helpful? That would give us an easy way to say "this incoming starred video should displace this other currently-starred video", but I'm leery of any system that involves users voting since they tend to get hairy and provoke all kinds of controversy.
Petrie: well-knownness isn't itself a good reason to star something. The movie has to be really impressively done in some way -- highly entertaining, very obviously tightly optimized, or something along those lines. Just "we should have more than one 3D starred game, and this one is popular" isn't what I'd personally consider adequate justification.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I don't think the glitched Super Metroid movie should be moved, any more than the glitched Zelda 2 movie should be, or basically any of the movies in Alden's "doesn't play the game" movie list. Just because it doesn't remotely resemble real gameplay doesn't mean it should only go in the concept demos page.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
The obvious answer is to put dungeons on opposite sides of the map from each other, so the player spends as much time walking across the overworld as possible. I assume we aren't allowed to change where items are or the layouts of dungeons? Otherwise I'd put the Whistle and the Armband in dungeon 9. Since that's presumably not allowed, we want to hide the Whistle behind as many barriers as possible, which I believe means putting it on an island. We also secondarily want to put dungeons as far from secret passages (i.e. bracelet powers) as possible, though most of the bracelet warp locations are inconvenient.
Here's the dungeon dependencies for the first quest, as near as I can recall:
Dungeon 1: You can do this at any time before dungeons 6/8 (Gohmas require the bow).
Dungeon 2: arbitrary
Dungeon 3: Before dungeon on island
Dungeon 4: Before dungeons 5 and 7 (? -- I can't remember if the streams in 7 must be crossed)
Dungeon 5: Before dungeon 7 (there's a sub boss that requires the flute)
Dungeon 6: After 1
Dungeon 7: After 5
Dungeon 8: After 1
So here's my suggested placement:
3: Where level 8 normally is (requires getting a candle first)
4: Upper-right corner (100 rupee giveaway)
5: On the eastern island (heart/red potion giveaway)
1: Bottom-left corner (directions for the Lost Woods)
6: Coastal shop
8: Cheap shield store in the middle of the map
7: Right next to 1 (30 rupee secret)
2: Where level 5 is normally
9: Money making game just south of the upper right corner
Then it's just a matter of hiding all the candle stores and the good secrets so the player has to spend a longish time collecting Rupees and getting to the stores. I'd put all the stores on Death Mountain and all the good money secrets along the northern edge.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Great, that should be more visible, as should its counterpart in entertainment.
I think if you read down the list that you will probably agree that most of these movies are going to be hard to improve upon timewise. It will certainly happen, but it will probably not be trivial. So I think that the tech rating is nice.
I'm not arguing that it isn't -- far be it from me to tell people how they should appreciate a movie -- just that it shouldn't be folded into the overall score. I'd vastly prefer a system that shows both numbers side-by-side (with an aggregated number as well if you must).
quote]Oh, and having tech rating combine with entertainment to form the "real" rating is good because it skews the more optimized movies upwards.[/quote]I'd argue that the right way to handle this is to have more mechanisms for finding high-technical movies -- like that list you posted. :)
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
You're not addressing my main point, Warp, which is that given the existence of people who do not care about technical ratings, forcing the technical rating into the only visible rating (which thereby obscures the entertainment rating) is a mistake.
If someone is scrolling through the movie listings looking for an entertaining movie, what are they supposed to do, click through on every one to get to the "discuss this movie" page so they can see the split-out numbers? Hell, if someone's scrolling through the movies looking for a technically strong movie, they're similarly out of luck.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
You must surely concede that the technical rating has no inherent bearing on entertainment for some subset of the population. And I argue that newbies have less interest in technical perfection than veterans do, especially given the already high technical bar that must be passed for a video to get accepted at all. So if we accept that the ratings should be useful to newbies, and we accept that newbies in general are uninterested in technical perfection, then the ratings should not take technical perfection into account (or at the very least should split it out).
I'm not trying to take your interest in technical perfection away from you. I'm just saying that you have a perspective that is not shared by newcomers to the art of TASing.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
It's not beyond me. A newcomer to the site is looking for entertaining runs, and could care less about technical perfection except insomuch as it affects how entertaining the video is. It's reasonable to assume that something that most people find entertaining will also be entertaining to a newcomer; yes, there are specific exceptions, and yes, because we're experts on the subject, our tastes are different, but there is at least a correlation.
But then you throw that "technical quality" into the mix, and suddenly you have a number that bears much less correlation to entertainment. You can vary a movie's overall rating by 3 points just because a terrible game was TASed with a high degree of precision or a highly entertaining game was sloppily-run. This makes it nigh-impossible for a newcomer to use the ratings to find entertaining runs.
I'd be fine with splitting out the listed ratings on the movie display so that technical quality is distinct from entertainment.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
