View Page Source

%%TOC%%

!!! Definition

The point of this metacategory is to host runs that expand the internal gameplay using different sorts of tools and methods: software and hardware, and decide to showcase ideas behind those tools rather than pure gameplay being TASed. When actually implemented, those ideas become concepts, and such runs can thus be called concept demonstrations.

Focusing on those concepts can lead to breaking some rules that make the runs fit into Moons and Vault. If we move all runs that break those rules (but appear to be publication worthy otherwise) to the Demo tier, the overall clarity of the site content won't suffer, and all runs that could be questionable for laymen will be kept in a single area under special rules (and with special notice if needed).

!!! Approach

First of all, we are known to be able to judge runs by multiple factors at once, even by those that can't be precisely measured. That's how we handle hacks and homebrews: we judge the run's technical level, its entertainment value, and the hack/homebrew itself. Hacks should be high quality, notable, suggesting unique content, and so on. You can't measure those the same way you measure speed (just compare the times) or entertainment (just compare the votes and posts that like/hate). You have to do some basic research on the web, ponder different aspects, coordinate with the crowd, listen to your own feelings and experience. That way we come to how we are actually able to have hacks obsolete each other.

The same approach can be used when we set criteria for the Concept Demo metacategory (tier, class, tag, whatever it becomes in the end).

* We can evaluate __entertainment__, and basing on it (among other factors) obsolete/reject things. We can even have starred Concept Demo runs.
* We can evaluate __the technical level__ (so far the part hardest to define, need to figure out what we will have first, so the technical level could have some real examples). 
* We can judge __the concept__ itself, using the aspects I'm going to describe on this page. We know we can, even for unmeasurable stuff, as long as we have the guidelines.

!!! Eligible classes

As was proposed by Nach long ago, at first we should figure out the movie classes that would make a run Demo eligible.

There can be endless amounts of classes, you never know what one's creativity invents. But all of them can then be judged using the guidelines that rely on our overall judging experience, on expectations that haven't been met yet, and on the increased level of technical awareness of our audience. The latter is the case when a not so entertaining movie has some highly supported concept behind it, that people enjoy to the point of wanting to have it published, but no, it is not that entertaining as a movie.

! Total Control runs

The runs with arbitrary code execution that aren't vaultable. If a run isn't vaultable, it means it's not supposed to be any% or 100% completion, so it doesn't aim for fastest time, and is a side goal. We used to accept such runs to Moons if they are entertaining (and even star them). Speed oriented runs that appear to have arbitrary code exploits only use those as one of countless possible ways to trigger the game end, so total control in those is by no means the point, since it will be replaced with whatever strat is faster once such is found.

The point of the run is not how fast it ends, nor how entertaining the part that plays the original game is, the point is the payload itself, as in, what happens after total control over the game is gained. Such runs are judged and compared by the payload quality, obsoleting each other if the payload is conceptually similar.

This class should only fit into Demo, because in the end, such runs can __break the rule of completing the game__. Game end routine can be called, but should not be required, and it can be modified as long as the it looks more entertaining/impressive.

! Cheated runs

Cheat codes have been banned since forever, with some interesting exceptions for internal cheat codes, and no exceptions for external cheats: [MovieRules#ToolsThatManipulateRomOrRamEGGameGenieCodesAreNotAllowed]. But a cheat code is expanding the gameplay, and there can be very impressive results of that, as long as they meet the criteria listed below.

Such runs should only fit into Demo, because they break the above rule.

! Research & Development runs

These present some ingenious background work and/or come up with a elaborate workflow used to demonstrate a novel concept. The tools developed can be software and hardware: bruteforce bots, replay devices, devices that allow combination of a console with another console or a device it could not work with before, lua scripts, internal or external cheats, and so on. There can't be a hard limit on those, since we don't want to limit creativity.

!!! Entertainment requirements

None. Similarly to Vault, we don't ask those runs to be entertaining in a usual way, because not all impressive concepts can afford that. But nothing prevents them from appearing to be entertaining, and even starred.

Entertainment can be used when we are deciding whether we should obsolete runs, among other factors. See below.

!!! Technical requirements

As I said, the hardest part, since you can't guess creativity limits. But we could partially try looking at it as we look at tech quality of playarounds.

* The run shouldn't be or look sloppy or dirty.
* The goals the author sets should be clear and be fulfilled by the run.
* The concept the author decides to showcase should be demonstrated at a highest known level. This can be another factor for obsoletion, see below.

!!! Conceptual requirements

Runs that don't represent a concept, but simply use arbitrary goals, should go to Moons if the feedback is good. The Concept Demo metacategory is not a dumping ground for anything that didn't make it, but is still somewhat nice. Runs that fit into Moons, but got rejected, should be reconsidered for Moons, if needed. And the runs that don't meet the below requirements should not go to Demo.

The concept we want to accept is:

! Solid
* It should not consist of various micro concepts, because it makes it impossible to compare runs.
* It should not be too esoteric. It must be easily comprehensible to the viewers and to the judge.
* It should not be too arbitrary. That can't be measured, so it should be decided with the help of the viewers. However, if the idea feels arbitrary, but is still very impressive, it should have a chance, see below.

''"Make Pokemon display a twitch chat using arbitrary code"'' is a solid concept.

''"TAS SMB with the goal of minimum buttons __and__ add a DDR script to it to make it look better"'' is not a solid concept, since it consists of parts not conceptually necessary to each other. The DDR script can be used anywhere, and the minimum buttons goal is an example of a Moons goal that just wasn't entertaining.

! Justified
* It should not add features to the gameplay that simply make it easier. Instead, it should try to introduce some new mechanics/challenges.
* It should not be used to add features that can be gained the legit way.
* It should not add features just for the sake of having them. They should have a conceptual reason.

''"TAS Super Metroid with a GT code"'' is not justified, because it gives the player unfair advantages without adding a new challenge.

''"Use GT code in Super Metroid to get access to arbitrary code exploit"'' is a justified concept, because it sets its own goal that ends up being very challenging, and the GT code is only a way to achieve it.

''"TAS Mega Man 9 with ability to switch weapons on the fly"'' is not a justified concept, because it is designed the add features that make the gameplay easier. This could be done to make the run more entertaining, but that can be achieved the legit way as well: make a code that pauses the music during weapon switching, so the encodes will have no music interrupts after the pauses are cut away, so the result of pauseless encode will be exactly the same, and also legit. You can look at it the same way Sonic CamHacks are used: they contain elaborate coding to make the camera always catch up with Sonic, it's used to simplify the TASing process, and to present more meaningful encodes to the viewers, but it syncs the same without CamHack, so it's universally legit. Another example is Darkwing Duck's in-game lag counter added by AnS: it helps, but the run syncs without it.

''"TAS SMB with a Portal Gun ability added via lua scripting"'' is a justified concept, because it doesn't simplify the gameplay, it adds features that introduce entirely new mechanics and make gameplay more challenging (optimization wise), and it can also be very entertaining.

! Verifiable

* The end result must be a movie that syncs on an official emulator.
* The concept can't be represented by something that can't be verified, such as an AVI file, or a lua script alone, or the workflow alone. (This makes entirely botted runs a gray area, probably there's an agreement on how to verify that the run was indeed entirely botted.)

''"Make the Final Fantasy TAS sync on console by adjusting input on the fly"'' is verifiable, as long as it has a synced movie.

''""Star Control II made on DOSBox-rerecording"'' is not verifiable, since there's no build of DOSBox-rr that was approved and supported by TASVideos. Also, it's not conceptually different from TASing the usual way.

''"Chrono Cross AVI recording edited to only have the final shot of every segment"'' is not verifiable, even though it has an impressive workflow behind it. We can't publish something we can't replay. And it also can be TASed the standard way now.

! Novel

* The concept should stand out from simply TASing a game the traditional way (as Moons and Vault runs do). 
* The idea the concept is based on should be brought to a new level each time. That helps to compare and obsolete/reject if a concept is already represented.

''"A run created entirely by a bot"'' is a novel concept, because instead of TASing the game the usual way, the author decided to design a bot for him to do it, and this bot is the main idea behind the concept.

''"A run of a number drawing game that draws arbitrary stuff"'' is not conceptually different from a usual playaround. It takes the game and TASes it. The workflow designed for it may be impressive, but it's not a necessary part of it.

! Technically impressive

It's known that some viewers enjoy the technical side of the project: either more than its entertainment side, or just regardless of whatever the entertainment side is. This can only be seen from posts right now, because the poll doesn't suggest a generic question that would work for all the metacategories.

The idea is that people sometimes say: "Did I find this run entertaining? Meh. Did I enjoy it overall, and should it be published? Absolutely!" It's not some obscure insanity, it's the value people see in the runs that is neither speed optimality, nor entertainment. And there's been more and more of the runs that have some technical background and/or impressive workflow designed just for that particular run.

This can also be addressed as Research & Development involved into the run's creation. It can't be measured, but it can just __be there__ and __get enjoyed__.

It still can only be figured out based on the submission comments and thread posts, so its mostly feedback dependent, since the question is: "Is this concept technically impressive for you?"

!!! Obsoletion

All of the above could be used to compare runs, but the idea is that if a run is supposed to obsolete another run:

* Their concepts should be comparable
* While the new run is stronger by some of the factors, it's not weaker by any other.

If a new run is just at the same level as the existing one, and has the same idea behind the concept, it should not obsolete it, which will lead to rejection.