Experienced Forum User, Judge, Published Author, Active player
(495)
Joined: 7/8/2021
Posts: 98
feos wrote:
ViGadeomes wrote:
I took my time to think about it and used as a basis the definition that we can find in french here.
This is my proposition to define a game mode :
game modes are the different ways the user can choose to play from the menu before starting to play.
Depending on the context, it can designate the number of simultaneous players or the type of gameplay sought (when the game offers a choice).
This fix the problem of fighting games but can maybe also add the difficulty choice problem in the discussion... This is only a WIP and this needs some discussions and feedback.
Difficulty, as well as all sorts of options like game speed, colors, audio. What if some option allows a high number of variants of the same stat? Do we allow every variant? On top of every other variant of every other option?
I think this problem ultimately solves itself because it has to be justified in video submissions. As in "you can submit whatever you want, just be prepared to explain it and make it interesting for judges".
Experienced Forum User, Judge, Published Author, Active player
(495)
Joined: 7/8/2021
Posts: 98
Radiant wrote:
So, being not all that familiar with Super Mario 64
Now about 16 stars, though. I doubt most people find it entertaining to have 121 separate movies, one for each quantity of stars. So that begs the question: why not 15 stars or 17 stars? And I don't know.
The category is 16 stars because you need to collect 15 stars to spawn MIPS and you need to collect Board Bowser's Sub in Dire Dire Docks to make DDD entry go further back in the hallway and grant you access to Bowser in the Fire Sea. You need access to BitFS to get the key to upstairs, which is required to beat the game.
Radiant wrote:
Apparently the stars in the Bowser stage don't count, so the category actually is "collect 16 stars before the Bowser stage". But there's a 30-star door before that stage. So the category actually is "collect 16 stars before the Bowser stage, and skip the 30-star door with the MIPS glitch but not another glitch, and do not use this MIPS glitch in other places".
You cannot use MIPS clip anywhere else because you cannot move MIPS upstairs. Upstairs is not loaded until Mario has the 2nd key and opens the door, and the door animation triggers a loading zone. Said loading zone resets objects and unloads MIPS. It is _impossible_ to use MIPS for any door upstairs, since you can't bring it from base level and there's no MIPS (or any grabbable object for that matter) upstairs.
Now, if you ask "why don't you use MIPS directly to get upstairs" the problem is that the action that triggers the loading zone behind the door is Mario actually opening it. You can make it past the door, but there's just a dummy room that looks like the spiral staircase to keep the illusion of a single connected castle. And the only way to force Mario up the door is to enter the opening door animation, which can only happen if Mario has the second key. This is why 1 Key is as low as Mario 64 will ever get in terms of completion.
You could argue that the only purpose of 16 stars as a route was to show MIPS clip, and yes, I agree. And I think that's good! Several runs exist with the explicit purpose of showcasing stuff that would otherwise not be seen. My own Iconoclasts submission exists so I can show you things like a fully sequence broken Tower, a Black battle that took me almost a week to optimize on its own, and the powerful Quantum Leaps that don't get used anywhere else in the run!
And, ultimately, regarding SM64, if anything, I'd like input from the SM64 TASing community. Doesn't it strike people as odd that SM64 TASers, one of the largest TASing communities, which holds competitions and activities yearly to this day, has minimal overlap with this community? Isn't it strange that one of the largest active TASing collectives is not here to say this themselves and people who literally have only one submission have to say it? Shouldn't that be read as a failure of this website?
Experienced Forum User, Judge, Published Author, Active player
(495)
Joined: 7/8/2021
Posts: 98
CasualPokePlayer wrote:
ikuyo wrote:
In a completely unrelated point:
I think TASVideos should introduce a proper process for movie _depublication_ (or retraction). For depublication, I mean the action of delisting a currently published movie and potentially retracting its acceptance.
If we expect the webiste to grow and receive an influx of new movies in the future, we need to account for the fact that the current review system is not infalible. Movies that fail to comply with rules or Codes of Conduct (which, tbh, maybe we should look into adopting as well) but manage to make it past the review process should be able to be delisted and removed from publication, at discretion from Staff. I understand this is not really feasible given the current codebase, but since soon this website will have a better technical backbone, I'd hope such a process can be established.
There was already a lot of debate about it, http://tasvideos.org/forum/viewtopic.php?p=472406
You end up with "oh oopies some emulator inaccuracy (probably most common way for movies to be "invalid") means we're removing your movie" which is not a very fun concept to deal with, especially when the authors can't exactly anticipate that hey some years later we found out your movie is invalid because some glitch you used relied on bad emulator.
Also other problems listed in that thread, but that's a big reason why we shouldn't allow unpublications due to breaking movie rules.
(Also, obsoletion gives the wanted effect anyways and is what's typically used for "invalid" movies)
OK, this is fair, so I think I'll have to be a bit more specific.
As you correctly point out, an issue such as a movie relying on an emulation error can and is easily fixable by obsoletion. However, and this is why I believe delisting is important, not all issues can be solved by obsoletion. Allow me to present a couple examples.
Let's say, just as a theoretical example, that a movie gets submitted by author X and accepted, but during publication process we find out that the movie was plagiarized and belongs to someone else. This is a clear violation of our movie rules that require proper crediting. From what I've gathered, what would happen here if the movie was already published is that it would be modified to credit its proper author. However, that implicitly assumes that said author consents to their movie, which they did not submit, to be in this website. And said author could have completely legitimate reasons to not want their movie published. Do we just go against the author's wishes, probably guaranteeing that they won't even want to submit to the site again? This would certainly be a problem, because we clearly like what they do (we accepted a movie made by them, after all). The proper solution, if the author does not want the movie to be published, is to delist it. Maybe the author themself will end up submitting something else, or an improvement to this one, but if we fail to have a solution for this case, we might push away an author that under other circumstances would be featured in the site.
For another, completely random case, let's assume that a published movie contains a racial slur as part of its gameplay input. Note that I here say gameplay input and not dialogue or cutscenes, so let's assume this was a deliberate part of input in a movie that otherwise would not have such words. Obviously, such a movie would probably not get accepted, but if for some reason it does, a way to remove it should exist. And even if another submission existed for the same game that removes that word from the input, it doesn't solve the problem: the problem is not that the movie is not entertaining or suboptimal, the problem is that it contains language that should not exist in our site and that actively pushes people away. It is an ethical problem, and cannot be solved by technical solutions such as obsoleting the movie.
Of course, you know very well that the second case exists. I don't even need to tell you which movie it is.
Obsoletion is a fine solution for technical problems with submissions, but not all problems with submissions are technical, and those who are not cannot be solved by obsoletion. This is where a proper delisting system is needed, to solve what our current systems cannot solve.
Experienced Forum User, Judge, Published Author, Active player
(495)
Joined: 7/8/2021
Posts: 98
In a completely unrelated point:
I think TASVideos should introduce a proper process for movie _depublication_ (or retraction). For depublication, I mean the action of delisting a currently published movie and potentially retracting its acceptance.
If we expect the webiste to grow and receive an influx of new movies in the future, we need to account for the fact that the current review system is not infalible. Movies that fail to comply with rules or Codes of Conduct (which, tbh, maybe we should look into adopting as well) but manage to make it past the review process should be able to be delisted and removed from publication, at discretion from Staff. I understand this is not really feasible given the current codebase, but since soon this website will have a better technical backbone, I'd hope such a process can be established.
Experienced Forum User, Judge, Published Author, Active player
(495)
Joined: 7/8/2021
Posts: 98
Radiant wrote:
ikuyo wrote:
* Any method of skipping the 30 star door other than MIPS clip is banned.
Well I'm not highly familiar with this game, but this restriction strikes me as arbitrary. "No skipping the door" or "no using X glitch" seem reasonable, but "you can skip the door with Glitch X but not with Glitch Y" or "you can use Glitch X but not to skip this door" not so much. It sounds rather like "you can warp from world 1 to world 4, but not from world 4 to world 8".
I mean, I'm sure there's history behind it, but it doesn't seem like a clear-cut way to distinguish two separate branches.
This is a difficult thing, because if the route allowed any other method of skipping those doors, then you don't need MIPS. And if you don't need MIPS... then you don't need to collect 15 stars and spawn MIPS in the first place. Just BLJ directly to the door as the 1 Star/0 Star routes do.
If we remove the limitation that causes the run to be 16 star, then it is not 16 star anymore. And while sure, at this moment it would make zero sense to have it as the route, hen the route as first conceived they didn't have current knowledge.
I agree with you that yes, it is arbitrary. But I believe that to some degree _all_ routes and categories are arbitrary, be it RTA or TAS. I think there is no really a rule that allows us to clearly define with no ambiguity what is possible or not acceptable as a route for a movie submission in terms that won't clash with something that already exists or might exist in the future. As such, I think trying to rule that is pointless. If anything, we have seen increases of more and more arbitrary challenges rising to be some of the most well known types of playthroughs or Tool Assisted runs of certain games (from Pokémon solo run challenges to the SM64 ABC, probably the currently most well known TAS challenge of any videogame).
What we have to rule here is how we should rule, and build a framework that allows us to take decisions over cases in the future. We can't make a one size fits all ruleset, but we can establish a proper framework to evaluate submissions that we can apply to them.
------------
In unrelated points, something that got brought up during our discussion last Tuesday was to change the rule about beating all existing WRs to only account for WRs claimed at the time of submission. TASing specific games can take a lot of time, and sometimes stuff gets discovered during development of TASes that can cause RTA runs to follow a TAS submission to be faster. RTA can usually make changes much faster (all it takes is some free time and someone willing to grind) hile TASes might require a lot more work due to the need to resync RNG, adjust routing and such. I feel this rule also could encourage TASers that get caught up in such a situation to still submit and also to improve their own submissions later, accounting for any new discovery that has led to a newer record.
Experienced Forum User, Judge, Published Author, Active player
(495)
Joined: 7/8/2021
Posts: 98
Fortranm wrote:
feos wrote:
I took the goal definition from the RTA rules, and I don't know the game myself.
Me either but I think it is important to ask two questions in this specific case: What are the other techniques/glitches that can be used to skip that door? Are they consistently forgone throughout the run?
If the answer to the second question is yes, then I agree it's a well defined category because as arbitrary as the selection of things to forbid can be, they are at least consistently enforced in the entire run.
Going by the SRC SM64 16 Star Ruleset:
* SBLJ is banned
* Any method of skipping the 30 star door other than MIPS clip is banned.
Source
Experienced Forum User, Judge, Published Author, Active player
(495)
Joined: 7/8/2021
Posts: 98
During a discussion about this run that happened earlier today on the Discord server, some people asked me for further details on the route and its major skips, Airswim, and the new skip found during submission. So, here it comes!
<h3>Airswim</h3>
Airswim was found quite early in the life of Iconoclasts, and it's already explained in my submission text. Robin only transitions from in water to out of water by hitting the surface of a water body, but because there are several collision quirks in the game, it is possible to force Robin out of water without hitting a water surface. Once we do so, we can swim in midair.
This state is particularly broken because while several checks are done for OoB movement when not swimming, the movement for swimming is much more free form. Several colission checks don't even work properly when airswimming, which allows for massive skips.
For reference, the provided any% TAS by Serena is above in this thread.
<h3>No Airswim</h3>
Airswim was, pretty much since the beginning, the single fastest route for the game. It also lasts like 30 minutes and renders several other neat techniques the game has obsolete. As such, a No OoB via Airswim route was proposed pretty quickly within the RTA community, and this would later be properly defined as No Airswim.
The route for No Airswim is, in broad terms:
- Get out of Initial Loop (Blockrock + Settlement 17).
- Make it thru Shard Wastelands, collect bomb. Bombs are required to enter and beat Kibuka, beating Kibuka gives access to Isilugar, Isilugar contains the Parkour Schematic.
- Collect Parkour Schematic and craft Dodger tweak (required for quantum leaps). This, in turns, requires us to collect specific materials.
- Get Electric Wrench (a wrench upgrade is required to beat the Nightmares). We can do this by completing the Soldier Raid, which in turn requires beating Inti and completing the White section.
- Reach Impact Zone.
The fastest way to reach Impact Zone is by triggering an end-game state, which can be done by reaching Rocket Platform, getting to the spaceship and completing Midway. Without Airswim, however, the only way to quickly reach Rocket Platform is by using a quantum leap into the One Concern West fast travel area, which requires completing One Concern West. Additionally, reaching the fast travel at One Concern West requires usage of the Usurper Shot, which is found... at One Concern West. Most of the route is therefore informed by this chain of dependencies.
<h3>The Zip</h3>
The new major skip glitch was found by Serena the day after this submission was completed.
By carrying the key meant to unlock a material in Settlement 17 to the top section of the room, you can enter the tunnel towards Kerthunk room while carrying it. However, sections of this tunner are shorter than Robin when carrying a key (she carries objects over her head, OoT Link style). The game therefore does as it does in any zip situation and pushes Robin upwards until she gets out of bounds. In most circumstances this would trigger an OoB room transition, but the game detects that no room can exist above because this area is only 1 room tall. As such, the game does the failsafe explained in Quantum leaps and warps Robin to her last grounded position, back where she first zipped. However, due to the type of zip performed, Robin is put in an awkward state which allows her to move during door transitions. Therefore, by using the door to the church, Robin can force another failsafe trigger and cause the game to spawn Robin out of bounds.
Iconoclasts has all its rooms physically connected in the same map for convenience, so several rooms are hidden next to each other. The room that Robin spawns at when this is done happens to be above an entryway to Rocket Platform, which we can then reach and proceed.
A demonstration of this can be found here:
Link to video
Experienced Forum User, Judge, Published Author, Active player
(495)
Joined: 7/8/2021
Posts: 98
As someone who primarily works (or intends to work) with Linux games, I think it's also important to improve the rules to account for the fact that Linuxgames are now acceptable. And this involves reworking some rules or adding better clarifications:
* What is the preferred update/patch number for Linux and DOS games? Is latest available preferred always? can we accept an earlier full release (v1.0+ or after launch date) if it produces faster movies?
* What is the stance of TASVideos about games tied to DRM (such as Steam or EGS) that might eventually be lost due to this DRM issue?
* Are early access games and episodic games acceptable? For episodic games, does a movie released later that includes more episodes automatically obsolete a movie with less content?
* For games with variable graphical settings that can affect performance (such as RE games or the Towerfall 1000fps movie), is there a preferred setting? Is it explicitly the responsibility of the runner to state the environment? (environment rules such as fps are set in libTAS atm, but it's not a bad idea to futureproof)
Those are the questions that I can come up with right now, and I would expect more questions to come up as the rules get revisited.
Experienced Forum User, Judge, Published Author, Active player
(495)
Joined: 7/8/2021
Posts: 98
I've decided to uncancel the TAS and let it have its fair shot.
While the skip found shortly after submission causes this movie to no longer be the fastest route that forgoes the Airswim glitch, I can now see the potential for this run as a "No Major Skips" route. Given that the RTA community is small and hasn't arrived at a consensus about how to handle this now outdated (but important) route, and given the overall positive feedback the movie received upon submission, I think it's best for this community to figure out that question.
Experienced Forum User, Judge, Published Author, Active player
(495)
Joined: 7/8/2021
Posts: 98
PracticalTAS wrote:
I'm curious about the end credits softlock. Is a no airswim route faster than a route which uses airswim but detours and stops airswimming to set the end credits flag, then resumes airswimming? If the answer is "No", then that other route would be the fastest completion possible and therefore qualify for publication. I believe this route is eligible either way though.
No, definitely not. any% with airswim has a TAS for a much faster ~27 minutes, and a detour that activates end credits would add 5 minutes at most.
(any% TAS by Serena here for reference, she's working on a submission document as we speak)
Link to video
Experienced Forum User, Judge, Published Author, Active player
(495)
Joined: 7/8/2021
Posts: 98
Since it never hurts, here's some documentation about speedrunning/TAS techniques for the game
<h2>General movement mechanics</h3>
Robin has a max running speed of 470 units per frame, assuming no modifications (this will come up later). She takes 6 frames to reach max speed from idle when on ground, and 7 when in midair. As such, accelerating from ground is best for speed. Robin's running speed is preserved when transitioning from air to ground or visa versa assuming no horizontal collision, and the cap is enforced in both ground and midair so we can reach max speed in any of them.
<h2>Boosts</h3>
The way Iconoclasts enforces movement speed caps only applies when Robin has less than her max allowed speed and is accelerating. This means that if Robin somehow were to obtain speeds greater than her max movement speed, the cap would not be enforced. There are two known ways to preserve speed and exploit this:
<h3>Slopeboosts</h3>
Robin can perform an stomp by pressing jump+down while in midair. After some frames of animation, she will plummet to the ground. This can be used to destroy blocks and kill enemies.
When Robin lands from an stomp, she performs an animation and then proceeds to return to idle. If Robin lands in an steep slope (usually steeper than 45°), she will instead start sliding down the slope. We can then press jump to cancel out of the slide and keep the slope speed into our regullar running/jumping speed. Pressing jump for just one frame causes us to cancel into run, while holding the button cancels into jump. This gives us 700 speed and it's the best way of obtaining long term speed.
<h3>Gunboosts</h3>
Releasing a charge shot from Robin's gun gives her recoil in the opposite direction of 600. By inputting opposite direction when releasing the shot, we can preserve this speed boost and carry it with us in any horizontal direction as long as we don't turn or stop. However, it's worth noticing that guns have a cooldown after releasing a charged shot during which no shots can be fired or charged at all, so we have to manage the gun resource carefully for boosts. Additionally, we can use the gun boost to boost up (for an extra midair jump) or down (for a fast fall). While this method is more versatile than slopeboosting (since it requires no slopes and we have our gun available at almost all times), we need to be mindful to use it when we do not need our gun otherwise.
<h3>F*** up shots</h3>
For gunboosts, the game determines the direction the shot is released at using the direction Robin's facing and if any up/down input is being held. If those are being held, they take priority over the facing direction. However, the game only determines the direction for recoil the frame the shoot button is released. This means that with a frame perfect input, we can basically redirect our gunboost independently from the direction we shoot at. RTA runs use this trick once, but a TAS setting can abuse it in many more places.
<h2>Kill Jumps</h2>
Killing an enemy induces 4 frames of lag. We can release and press jump during those frames to obtain a midair jump, which acts consistently with regular grounded jumps. The run abuses this to quickly ascend vertical sections or reach points without having to climb ledges.
Experienced Forum User, Judge, Published Author, Active player
(495)
Joined: 7/8/2021
Posts: 98
For a PC game, can a settings file be provided for an option that is permanently set on first startup, not modifiable from within the game, and not tied to save data?
Iconoclasts has a flag in its data directory called settings, which contains a flag to know if this is the first time you've opened the game. This is used to allow players to skip an intro cutscene before the title screen that is unskippable otherwise, guaranteeing that the player will see it during their first time booting the game. Once the player has selected New Game, and enters a game, this flag is permanently set. Since iconoclasts uses manual saving otherwise, you don't need to save your new game at all (you can essentially close the game right away and generate no save data while still keeping the first_time flag).
Experienced Forum User, Judge, Published Author, Active player
(495)
Joined: 7/8/2021
Posts: 98
Link to video
Iconoclasts is a Metroidvania-styled indie game released in 2018, available for PC, PS Vita, PS4 and Switch. The game is known for being the passion project of a single developer for almost a decade, its gorgeous animation and some surprisingly heavy themes.
It also has a native Linux port and plays nice with libTAS 1.4+!
As of this writing, I'm already working on a No Airswim TAS. I explicitly chose No Airswim because I want the first TAS of the game to convey as much of the game as possible while also making it accessible to me as this is essentially my first major TAS project ever.
By carrying the key meant to unlock a material in Settlement 17 to the top section of the room, you can enter the tunnel towards Kerthunk room while carrying it. However, sections of this tunner are shorter than Robin when carrying a key (she carries objects over her head, OoT Link style). The game therefore does as it does in any zip situation and pushes Robin upwards until she gets out of bounds. In most circumstances this would trigger an OoB room transition, but the game detects that no room can exist above because this area is only 1 room tall. As such, the game does the failsafe explained in Quantum leaps and warps Robin to her last grounded position, back where she first zipped. However, due to the type of zip performed, Robin is put in an awkward state which allows her to move during door transitions. Therefore, by using the door to the church, Robin can force another failsafe trigger and cause the game to spawn Robin out of bounds.
Iconoclasts has all its rooms physically connected in the same map for convenience, so several rooms are hidden next to each other. The room that Robin spawns at when this is done happens to be above an entryway to Rocket Platform, which we can then reach and proceed.
A demonstration of this can be found here:
Link to video