It's just that it somehow feels against the spirit of TASing to play on the easiest difficulty level, ie. deliberately using the weakest possible opponent, because that shows absolutely no challenge.
Of course this is a conundrum because the alternative would be to use the highest difficulty level, ie. play against the strongest opponent possible and beat it to a pulp... but making the run a lot longer in the process, with most of the time nothing happening.
I suppose my next question would be: How much longer would this run be if it were on the highest difficulty level?
By default the hardest difficulty should always be chosen in any game, and there ought to be a justified reason to choose anything else. "It makes the run faster" is not usually a valid reason (if it's the only one). Was there a reason in this case?
I don't really understand your question.
Anyway, it's just that I was thinking about an alternative that wouldn't necessarily require as much time and resources for the people making it all happen. This showcase was excellent, but as dwangoAC has said, it took a ginormous amount of time, work and even money.
I think it ought to be possible to be a bit more conservative, while still keeping the awe factor of the TAS block pretty high. It wouldn't also hurt to show actual TASes (running on a real console), rather than demonstrations. I think that showing an existing TAS that's impressive (eg. a glitchfest), with someone explaining what's happening on screen, would be good.
After all, the event is "games done quick", so shouldn't we be showing games being completed quickly?
I have always loved that argument.
You can argue all day long, but "superplay" is a backronym. The term "TAS" existed and was proposed to be used here before anybody came up with that interpretation.
There seems to be this concept that the TAS showcases at the GDQ events need to do something special, something never seen before, something that has never been shown nor attempted before, something that shocks even TASers and regular visitors to tasvideos.org. It's like not getting a standing ovation would be considered a failure.
This year this idea went so far that there actually was not a single actual speedrun showcased, even though it's supposed to be a "tool-assisted speedrun".
Personally I don't see why that has to be some kind of necessity. Just plain regular old TASes, run on a real console, are awesome enough, when the game and the TAS are chosen appropriately. Just take eg. a glitchfest TAS (like the Megaman one), and it ought to be awesome to watch. Not every viewer has seen TASes before. Especially not run on a real console.
Of course I don't know if the event organizers will accept just a "regular TAS" for the event. But if that's a concern, why not just ask them? Make a case that 1) it's actually the very idea of TASing, and 2) a cool-enough existing TAS that does crazy things ought to be awesome to watch all in itself.
That's not to say there can't be any never-seen-before things at all, but perhaps it would be easier, and even better, if the TAS block doesn't consist solely of those.
I'm not a hardware expert and thus don't know what kind of work, and how much, it would entail, but perhaps the TASbot could be developed in the direction of being more reliable and less affected by external interference.
That's actually a very good point. The presenters did indeed seem to just assume that all viewers know what a "TAS" is, or what the little robot is doing.
Explaining in detail may be boring to those who already know that stuff, but it's informative to those who don't.
The first two seasons were very enjoyable to watch. The two next seasons were more hit-and-miss, with some episodes being ok, others not so much. It especially didn't help that the finales decided to erode (implicitly) established canon in very annoying ways, ruining the next season. (Ok, it's too early to say that season 4's finale ruined season 5, but...) It makes it especially cringeworthy when the eroding of the canon was clearly done to simply sell more new toys.
One thing I don't find particularly good in the entire series is that there's little continuity between episodes. Only very few things are carried over from one episode to the rest of the subsequent series; for the most part the reset button is always hit hard at the end of the episode. For example, the life lessons learned in an episode are typically completely forgotten, and nothing has been learned. (For example, the aesop of an episode might be that you should trust your friends and take them seriously even if they seem to be acting silly. Then a few episodes later one of the main characters is acting silly and nobody else in the group takes her seriously. Argh.)
It's very possible to make a very episodic series that nevertheless has continuity. Having watched the entirety of South Park recently, it's a good example of this. Even though each episode is very independent, things still carry from one episode to the rest of the series, and usually things are not simply forgotten for no apparent reason. (There are some exceptions, of course, especially in those episodes that are more like "alternate what-if universe" episodes. However, things that happen in the "main universe" episodes, so to speak, carry over into the continuity of the subsequent episodes.)
When you submitted those runs, did you read the part of the submission page that says "By pressing "Save/Edit" you agree to publish this content under the Creative Commons Attribution 2.0 license."
Said license says:
You have no legal stance. You could bully someone into not streaming your TASes, but you would be quite a dick in doing so.
Unity is a good solution. It can build for numerous different platforms, including html5.
You will, however, be basically limited to either javascript or C#. I would definitely recommend the latter, as it's more versatile and efficient, and not all that different from C++. It doesn't have everything that C++ has, but on the other hand it has some things that C++ doesn't, but they are very similar. If you are an experienced C++ programmer, you'll know how to program in C# with extremely little effort (but unfortunately not in the other direction.)
You can write plugins for Unity with other languages such as C++ (which is great if you need some subroutine that's absolutely optimized for speed and/or memory usage), but I'm not sure how well they integrate (compared to the native C# support). Also, I think that being able to write plugins with other languages requires the pro version of Unity.
The thing is, javascript can be run with a browser, and easily display something on screen. And this requires nothing more than a text editor. Everything else is already in basically every single computer in existence (regardless of OS).
C++ is certainly more powerful and versatile, but the initial setup you need to get anything on screen is quite large, especially for someone who has never done that nor doesn't have any kind of environment for it set up already. Also, the result you get is an executable binary which will run only on one system, needs to be downloaded and run, and like all native applications, has slight security risks involved (catastrophic bugs, viruses...) Javascript running on a modern browser is almost as safe as you get (barring some browser bugs). It's really slow, of course, but safe.
I have been programming for years games for iOS as my payjob, so I have some experience on that front. (I absolutely love being able to use C++ for this, as it's my favorite programming language. However, I recognize the hurdles that a beginner will meet the first time. They are quite big.)
My suggestion is that for next time at least one of the exhibitions should be just a TAS of a game, as others have suggested. Of course the run can be really wild and extraordinary, eg. extremely glitchy. I'm thinking of Megaman-levels of glitchiness. (In fact, Megaman might be a good game to show off.) I think this ought to elicit some awe in those who have never seen such a thing.
Another idea for another demonstration: Perform arbitrary code execution, and then upload and run some kind of demo. I'm talking about a demoscene style demo. Something that's awesome-looking and pushes the hardware to its absolute limits, and seems to do things that look impossible for that hardware to do.
If Doom is ever fully TASed inside a DOS emulator, it ought to definitely be the original Doom, not any of the newer wad-compatible engines. (In a sense those could be categorized as mods, not the original game.)
Did the original Doom even support the mouse? I can't remember. Even if it did, it was something that not many people even used back then. (Of course using the mouse would do wonders to a TAS because of almost infinite turn speed, while keyboard turning would feel extremely sluggish in comparison.)
In principle we don't accept runs of modified games, which rules out games that have been modified for tool-assisted speedrunning. Also (unless this policy has been changed) we don't generally accept runs in the form of a game's own replay system (for various reasons, but often because those can be tampered with in a manner that breaks the other rules).
All the input must come "from the outside" so to speak, not from anything inside the game. This means, effectively, that we only accept runs of original unmodified games run in emulators (or, in a few cases, original games running on an actual console, with the key inputs being fed directly to the controller port).
Thus basically the only way of accepting a Doom TAS would be to run it on an emulator (which in practice means DOSBox). However, AFAIK there are some emulation difficulties in this (or at least there had been in the past; I haven't been following the DOSBox TASing status recently).
Anyway, if you are interested in making a Doom TAS, you ought to look in that direction, ie. see if you can use DOSBox for this.
On Mac OS X, with Firefox Samus blinks both on 360p and 720p. I don't understand why it works differently in Windows.
With Chrome the sprite blinks in 360p in the same way, and in 720p60 it blinks significantly faster, and all movement is visibly smoother (which isn't surprising; in other words, the 60Hz version is working as it should).
I'm wondering if the optimizer is blurring the images for better compression. When you compress more with JPEG you don't usually get more blurriness, you just get more visible artifacts. Blurring the image a bit before compressing can allow more compression with less artifacts, but only works with photographs, not drawings or pixel art / older computer graphics.
The Super Metroid video works a bit strangely for me.
I'm testing with Firefox on Windows right at this moment, and using the html5 youtube player. In 360p Samus is solid, while in 720p (not 60fps) Samus blinks. I don't really understand why.
I'd like to add (although it might be self-evident) that it doesn't necessarily have to be obvious to someone who has never seen the game nor knows anything about it, but ought to be obvious to someone who knows at least a bit about the game.
For example for someone who has never seen nor knows anything about Castlevania II, it may not be apparent that enemies are not supposed to always drop hearts, and thus the luck manipulation may not be obvious to such a person. However, the luck manipulation is pretty obvious to anybody who knows that enemies drop hearts only occasionally.
Using that subsampling mode indeed increases quality (because it retains more color information). Note, however, that it will probably be useful mostly if the source image is lossless. Re-compressing a 4:2:2 jpeg to a 4:4:4 one is probably not going to increase the quality (because the original color information has already been lost.)