You are a day too late.
Seriously, though, I have the nagging feeling that raising expectations by making a kind of season-length story arc ("what is in that box?") will only lead to disappointment when what's revealed is something meh. I could perfectly well be wrong (and I hope I will), but I'm not holding my breath.
I just hope they don't repeat the disaster that was season 3 finale. Even a "meh" payoff would be a hundred times better than that.
You can't simply "square both sides". That's not a valid operation (that keeps the equality). You have to multiply both sides by the same number, and you did not do that there.
If you restrict all the reset-button-using and arbitrary-code-executing runs to the paid portion of the site and leave the actually fun runs to the free part, then I'm all for it. You can keep your soft-hacked games for all I care.
Actually the funniest part of all this is that some people really are unsure if this is a joke or not. (Unless they are meta-joking...)
You make good points.
Many people here seem to think that cheat codes are ok if they are executed in a way not intended by the developers, or by abusing a glitch, or even simply in a manner that's "harder" than the intended manner (ie. via a key sequence that has been programmed into the game).
I cannot comprehend the logic behind this. The point is not how easy the cheat code is to execute. The point is what the cheat code does. It doesn't matter how the cheat code is executed.
Abusing cheat codes, or outright "soft-gamesharking" the game via glitches, feels more like circumventing the spirit of the rule, its original purpose. It was interesting the first few times it was achieved, but since it has steadily become more and more frequent as new glitches are being discovered, I have grown a great distaste towards the technique.
This is not to say that we couldn't have them on the site at all. It can be useful to kind of document and archive all the ways that a game can be broken. However, once those start obsoleting the more "genuine" (in a sense) playthroughs, which are then dropped off completely, that's where I personally draw the line. It kills the fun in watching the game being played by a perfect being for me.
It seems that at first Hasbro didn't mind their episodes being distributed, but in the last year or so they have got a lot more protective, for some reason.
Either executive meddling, or they have changed their minds.
In Dragon Quest VII there's a poker mini-game where, when you win something, you can start doubling your winnings. You guess "high" or "low" compared to the previous card, and if you guess right, your winnings are doubled, but if you guess wrong, you lose everything.
The cards come otherwise at random, except that at the beginning of each round the game decides in advance how many times at most you are allowed to guess right. If you get that far, you will lose no matter what you choose (if you choose high, it will deliberately give you a lower card, and vice-versa.)
If the category is "fastest in-game time", then a submission that has a lower in-game time completion ought to obsolete it.
Disallowing some glitches (pause-glitching) while allowing others (arbitrary code execution) is arbitrary, subjective and inconsistent.
(Hey, if it were up to me, both of those would be disallowed. But speaking from a pragmatic point of view, why allow one but not the other?)
You are right in that a lower-level language like C or C++ allows for better space-optimization of data. This kind of optimization is often laborious, difficult or even outright impossible in higher-level languages (with some exceptions, of course.)
While it's not very common (especially nowadays, as speed and RAM has increased and keeps increasing), sometimes it can be beneficial if your data takes as little RAM as possible, ie. it's packed into memory as tightly as is physically possible (even going so far as individual values taking less than one byte of space, ie. you start using bitfields, or "manually" encode your values into less then 8 bits and pack them together into bytes). I have quite a lot of experience at this kind of optimization in C++. Most higher-level languages lack the capacity of this kind of optimization completely (or if it's possible in them, it's often difficult; some exceptions notwithstanding.) Some programming languages are actually horrendously lavish in their memory usage (at least by default.)
(Note, however, that there can be downsides to the tight optimization, and some upsides to the "lavish" approach that many other languages use. The former can often be harder to make work, or be efficient, in a multithreaded program, while the latter often allows for automated multithreading.)
Anyway, my original point still stands: You don't need to know machine code (or even what kind of machine code the compiler is producing) in order to perform these space optimizations.
For some reason many people detest having to write, or see, the "std::" prefix. However, this is a bad instinct. I can tell from extensive experience that once you start religiously using it, your code actually becomes clearer and easier to read at a glance, than when not using it.
For one, the familiar "std::" prefix allows you to see where standard functions/types are being used from a quick glance. It also more easily distinguishes those standard names from your own names (especially if you use some custom prefixing scheme). There isn't even a theoretical downside to this.
Secondly, the "std::" prefix conveys a surprising amount of information that might not be immediately apparent. For example, suppose that you see in some program a line of code like this:
Language: cpp
if(equal(a, b, c))
What does that tell you? Not much, really. It could be anything. It could be a custom function that compares three values to see if they are all equal. This line also doesn't really tell what the type of those values 'a', 'b' and 'c' are. You'll have to look somewhere else to find that out.
However, assume that the line had been like this instead:
Language: cpp
if(std::equal(a, b, c))
Now this is an entirely different story. With the simple addition of the "std::" prefix we now know a whole lot more about that line of code.
For one, we immediately see that it's a standard function, not a custom function. Even if we didn't know or remember what the function does, we know where to look.
Secondly, if we know what std::equal() does, we understand a lot better what that line is doing: It's comparing two iterator ranges. Which in itself is giving us even more information: 'a', 'b' and 'c' are iterators.
Did the code become more illegible with the addition of "std::"? No! The exact opposite!
Btw, this is a good reason why "fastest in-game time" should be removed as a valid branch. Why? Because the "fastest" run would get Samus' health to 0 as fast as possible, and then just use the pause-glitch throughout the run. The run would take ages to complete, but the in-game timer would not advance. Thus it would be a definite word-record... that takes hours and hours to finish.
There are significantly more syllables than in the original song. Also the wrong parts are often stressed. Kind of annoying, really.
Speaking of This Day Aria... http://www.youtube.com/watch?v=v38oWllJj-c
Why are people acting like this TAS being in the Moon tier would be a great injustice and insult that must be corrected as soon as humanly possible?
I'm pretty sure I could find several Mooned TASes that I find ten times more boring than this.