Posts for FatRatKnight

Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
My own personal view is that null input is still input. Fact is, even if you drop the controller, you are still feeding empty input to the game. I'm decidedly for the idea of getting to the ending faster. Despite this, I still ended input early for R.C. Pro-Am, as it ended the run humorously. My April Fools' Guardian Legend TAS took default input state in a different direction, by having a button on auto-hold rather than having it affected by the movie file. If we're waiting for null input, that will never happen, but the game ending does take place anyway. Unsurprisingly, the TAS was rejected (and misses the Vault criteria in at least two ways), but I feel the statement has some merit regardless. As an aside, the Dream Team Contest #6 could have a different winner depending on "ends input early" vs. "fastest game ending." My team won, but if it was ruled for fastest ending, our setup to get the boss to kill itself on our permanent damage box would have been worthless, and we would have been in second place (based on some memory of calculating things a while back). Looking back on this, with my outlook, I do feel like we deserve the #2 spot, but it still provided a nice demonstration of a glitch in the end, so I feel positive overall. I thought a bit of my history may add a little perspective. It's mostly been author's choice from what I understand. Input length is easier to measure, as it's practically automatic with the size of the file, but time to ending doesn't care about semantics of what input is.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
I'm guessing there's no crazy pause tricks or Super Mario World style pixel-perfect wall landings. Just thought I'd bring up these ideas and see if these random ones have any impact. Assuming we do get the Energy Balancer, what parts of the stage do we have access to where we can get an energy refill? That would limit which addresses we can corrupt. Then again, those addresses still need to be analyzed anyway. And I suppose leaving the stage without fighting Tomahawkman is also a possibility? There's definitely a lot of questions to resolve before it becomes feasible to try. Starting to think some analysis on Mega Man's state may be desirable.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
I decided to run the Trace Logger again, and on some instance of a pick-up, $0001 is whatever $0057 is, after a potential carry from an addition involving $0056. The two addresses looks distinctly like some type of screen position tracker. Mind, I'm still blindly stumbling around code, having yet to create a context on what it all means, but if this calculation is always done before the refill function, then we have some consistency on the effect. Except we did have something happen to the visual screen position at $06A7, which is 0x1F away from $0688, and $0057 is 0x14 at the time. ... Actually, what is $069C or $069D, anyway? "Position of Left Table objects," the RAM Map says... okay? The biggest problem with stale values is that it's hard to know exactly what was the last thing to affect it. I'm seeing $0001 match up with $0057 in the few times I've seen it, and it would make sense if it's trying to ask for position before deciding the refill is yours to take. In any case, setting a breakpoint for reads on the Energy Balancer at $0696, then watching for how $0000 and $0001 lines up with $0056 and $0057 would be a good way to see if this has any consistency. And if... if that really is all there is to it, then we'll know the range we've got, and distance into the stage is all we'll need to know.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
If I remember my asm right, $0688,Y would mean we can affect values from $0688 to $0787. At least, we can go past the page boundary, right? A brief look at the RAM has given me the impression that sound related stuff is over in $0700 and above. Messing with that doesn't sound like it'll be helpful, unless glitching the sound engine gives us useful glitchy execution? I've also seen things like screen position not that far after the weapon energy/status, which explains the strange screen scrolling in one part of the video. Got any RAM maps before I try to work one up? Actually, ROM maps might be nice, too. Since weapon refills respect the maximums, we're not modifying any addresses which already have a large enough value. I suppose the last thing to figure out is what process the game goes through prior to the refill functions. The trace logger showed that the game's probably doing some bank swapping (STA to $8000?), so I'm guessing it's running a handler that gets the tasks going.
Post subject: Broke down one ASM function.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
I'll bite. I've been in a disassemble crud mood. It's Mega Man. I've poked about one game's RNG, I guess I may as well look at this Energy Balancer. For now, until I start crunching on code, my wild guess is that the game gets a count of weapons, then starts iterating through them until there are no more weapons. It would assume there's at least one weapon, so it would loop once, do a decrement, then see if it hit zero. If it was already zero, it would decrement the zero to 255, and find out it's not zero after all. Presumably, unintended memory is used after that. But that's just a wild guess. EDIT:
;Location 1D:949C
        LDA $0699       ;Weapon selection?
        STA $05C8,X     ;Target weapon
        BNE _94C9       ;If it isn't zero, then escape function
        LDA $0696       ;Energy Balancer
        BEQ _94C9
        LDA #$FF
        STA $0000       ;Set temp with 255 -- Lowest ammo we found so far
        LDY #$09        ;Set up loop for weapons
_94AF   LDA $0688,Y     ;Weapon
        CMP #$80
        BEQ _94C1
        CLC             ;If we're here, we have the weapon.
        ADC #$01        ;Take weapon's ammo + 1. For some reason.
        CMP $0000       ;See if this weapon's the lowest one so far.
        BCS _94C1
        STA $0000       ;If so, this is our new ammo count
        STY $0001       ;And this is our new target weapon
_94C1   DEY             ;Continue weapon loop
        BNE _94AF
        LDA $0001       ;Weapon with lowest ammo
        STA $05C8,X     ;Target weapon
_94C9   RTS
I did a breakpoint check for 0696, which apparently is the Energy Balancer. The above function is called from location 1D:9486, and I didn't look through there as yet. I also haven't analyzed what X is coming into this function. Anyway, I can already tell there's a problem with detection here. Address $0001 is used to identify the weapon, but if we have none of the eight weapons or Beat, then $0001 was never updated with a weapon ID. Therefore, the function returns a stale value, whatever the last thing the game was doing with that address. And that will be tricky to analyze. And most likely, stuff after 0688 appears to be at great risk of being modified by this glitch. Anyway, that's what I found so far. My wild guess wasn't on point.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
NES Overlord. Even Vault rejects it. Its aim is fastest completion, but the triviality rule came into effect. I do not object, with the only question against triviality being the short piece at the very end. Anyone here with the patience to dig through rejected submissions for their reasons of rejection?
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
I have a case of a TAS I once worked on: HyperZone. Hyperzone is basically a rail shooter of sorts. There is a strictly finite quantity of enemies to shoot, so if all of them were shot down, that would be a way to define 100% completion, correct? The part I stopped at basically had the game flood you with enemies, and it is easily possible some of them fail to spawn because there aren't enough empty enemy slots. If they don't spawn, they aren't a scoring possibility. Based on the troubles I've been having trying to TAS that next part, it may be impossible to get 100% kills, so 100% kills is invalid due to impossibility, and maximum kills is not a valid 100% Vault completion goal, so my TASing goal fails to comply with this. There is something the game awards you for reaching score thresholds, new machines to fly with better capabilities. There is a finite quantity to this, and once you get the final machine, there are no further rewards in score. If you want to tie this "hard, known maximum" as a 100% completion thing, I will tell you that meeting this score threshold in an any% goal is trivial in TAS conditions, with the only questionable detail being the machine swapping animation. Therefore, by triviality, that "final machine" goal is not a significant change from any%, and is not to be accepted as having appreciably different content. The absolute last fallback of allowing maximum score to differentiate from any% would at last catch my TASing goal. But if the "final machine" goal takes priority as a measurement of completion, then I will submit there doesn't exist a meaningful Vault 100% goal to be viably submitted. As a result, score is still an unacceptable goal in Vault conditions, despite the supposed fallback. This is the line of thinking I'm dealing with at this point. A bit confrontational. Please tell me otherwise. For that matter, I still don't want to read and analyze the discussions that took place, as now these thoughts have taken hold and driven my emotions again in the wrong direction. I just don't want to deal with the subject, but now for a different reason.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
CoolHandMike wrote:
Also normal driving techniques like cutting corners does not seem to be used properly. But this is a video game so maybe you could explain why?
The first Top Gear game didn't have such complexity like "proper driving lines." Think of it as a perfectly straight road, which occasionally pushes you to the left or right, and steering merely adjusts your position left or right without affecting forward motion. I don't care what the graphics say about how curvy the road is, it's still a perfectly straight piece that, again, occasionally adjusts your position. At least, that's the pattern I noticed when it comes to these types of false 3D perspective 2D racing games. I know Rad Racer did, and the first Top Gear game also did. The one last detail to confirm, then, involves the fact Top Gear 2 isn't Top Gear, so did it change things in the transition to the sequel?
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
I'm not thinking straight enough to answer. Wrong mood to try and analyze the discussion. Reread my second to last post before this one, erase anything after the "I can answer one facet" part of that paragraph, and see if anything else I say stands. I prefer to focus my time elsewhere until I'm ready to form a new answer.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Perhaps, but it still doesn't explain denying score metrics when a time metric for a different "full completion" is available. I had also forgotten about the discussion, but it's still just one facet I pointed out. The other facets of the phobia isn't clear to me at the moment. Still good to have pointed out my mistake there. Currently dealing with a defeatist mood, though. I hope you can understand why thinking about the direction this thread is in.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
The time metric is unclear in whether we truly did the game as fast as possible. A fair quantity of TASes are obsoleted as proof that the time isn't done to the fullest extent. We are fine as it is generally an easy quantity to measure by the length of out input file, and speedrunning as a whole is practically defined by the time it took to clear the game. A "soft maximum" score is also unclear about whether the top was reached. So, why the phobia of a score metric? Generally the whole idea I was pushing in this thread is to allow for the possibility of obsoleting another TAS by a higher score. I can answer one facet of the mentioned phobia already -- How to handle the possibility of some new-discovered "Endless Scoring" technique that break the "Soft Maximum" environment? I see TASVideos more as a speedrun site than a score run site (with the occasional but lovely entertainment-based TASes with time not as a primary goal), so if it can be turned into a time metric where possible, it is done, and if not, a score metric is the absolute last resort, if no other form of full completion is available. Targeting $1,000,000 is not a score measure, it is a time measure, further cementing my view on what this site's goals are. As such, I've already accepted my personal ideals do not fit here. A bit defeatist, but I do not desire to disrupt a working system too much. Anyway, you know my stance. I may disagree with the policy, but my goals aren't the same as the intent behind the policy. That's what I'm getting from this discussion.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
I did some light testing, at least. I just took my TAS, slammed out 8 bullets, avoid killing that nearby turret, and have the 8th existing bullet be the trigger for the warp. Failure. I did watch the cycle count between "hit detected" and "interrupt happened" decrease from 3678 to 589. Maybe a simultaneous hit can push it over? Maybe spawn another enemy? The successful movie spams my script output (the script is sloppy, though). I see 109 cycles between hit detected and interrupt happening, and I think that's close to the low end we're aiming for. At least, I hope it's all about the interrupts. Download SJ_CycleCount_FCEUX.lua
Language: lua

local R1u= memory.readbyte local Hits= {} --***************************************************************************** local function Hit_Check() --***************************************************************************** if R1u(0x8858) ~= 0xBD then return end --Bank check --Sloppy target check (like, real sloppy) local Reg_X= memory.getregister("x") if (Reg_X < 0x17) or (Reg_X >= 0x1F) then return end table.insert(Hits,debugger.getcyclescount(()) --Add entry end memory.registerexec(0x8858, Hit_Check) --***************************************************************************** local function NMI_Check() --***************************************************************************** local Cycles= debugger.getcyclescount() debugger.resetcyclescount() --A reset function! Convenient. local hit= table.remove(Hits,1) while hit do print(string.format("Frame=%d - %d/%d(%d) Target hit.", emu.framecount(), hit, Cycles, Cycles-hit )) hit= table.remove(Hits,1) end end memory.registerexec(0xFFE3,NMI_Check)
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Let's take Banjo-Kazooie. You can get the bonus scenes by having 100 jiggies. The game does track other sorts of completion such as honeycomb pieces for max health, but the ending doesn't care for that. Therefore, getting the extra scenes is not equal to collecting everything. In the same stretch in this case, you don't have to score everything in Tin Star to get the best ending. Unless someone can convince me Tin Star is an "Endless Scoring" environment (therefore making any finite score a "Targeted Scoring" goal) rather than a "Soft Maximum" environment, I will be saying that meeting the $1,000,000 threshold is simply picking and choosing which "sort-of-100%-ish" thing to get instead of simply all of them possible. Tetris is an example of an "Endless Scoring" environment, and capping the score doesn't prevent the scoring actions from continuing, but it's an entertaining target to hit the cap quickly, so I have no problems as the TAS isn't in Vault. As "Endless Scoring" implies you can continue collecting score (if you hack the score back down from the cap), collecting all scoring actions possible would be an infinitely long run. In any case, my desire for getting those high score TASes accepted are in direct conflict with the line of thinking that the ending target overwrites the score target. That is where the disagreement lies -- In that desire. I leave it to the TASVideos community whether that desire is appropriate.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
feos wrote:
Best ending is a good variation of full completion, and in this case it happens to be score oriented as well. Playing further would make the goal arbitrary indeed.
I disagree. Well, okay. We have an ending available based on having sufficient score. That I don't disagree with. As far as targeting best endings go, we're going for fastest completion of reaching this score threshold then the ending. We're no longer measuring this goal as a score metric, we're measuring it as a time metric, as targeting the ending means it's impossible to obsolete it with a longer time, but higher score. I have a personal disagreement that a score threshold ending takes priority as "full completion" over maximum score.
Post subject: Random plans for low money in later planets.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Alright, guesses. I'm going to guess that when the interrupt happens, it happens during the all-important collision function, and it wants to try that function back from the start. So, it retries the same bullet-target hitbox check and runs it again. Except the function was fully complete, had successfully spawned the object in its entirety, and the spawner code then looks for the next open slot as it didn't un-create the thing. If that's the case, then I'm going to hate trying to find the magic combination of sprites to busy the hit detection function by exactly enough. I will leave that to someone else to work out. I am willing, however, to generate a script that can tell you precisely when the important collision happened relative to the interrupt, but not willing to do the ground work to make it happen. Regardless, I have my question. Let's see if it's the right question to ask. Hah! Interrupt during handling the effect of the collision! But what is the consequence of this? Well, when the double hit occurred, the first hit had enough time to read $00BA, use it as an index to stats in the $500s ($052D,Y, $0547,Y, $0561,Y, $057B,Y), and copy the X,Y position of the shot object into those spots, then store the value 20 into $0513,Y. It also increments $00BA. Then it jumps to $8922 where it asks about $0374,X, with X still referencing the shot object, and it not being #$FF, it'll then go on to various management, which I haven't carefully looked at. The interrupt happens here, cutting off the management, and apparently never comes back to it. As a result, the bullet and shot object are still free to interact normally. The stuff over in the 500s are things for the game to spawn later. We didn't stuff just one portal in there, but stuffed two there thanks to a well-timed interrupt. So that the game thinks that it should generate the two a few frames later. Anyway, I still haven't cracked heavily into code analysis, but judging from the timing of the interrupt, and what the interrupt apparently does when it comes to the hit detection code, I'm around 80% certain it's based on the code being unstable around interrupts. Which is why the bullet spam is needed, I guess. ... Anyone need a script? EDIT: If this is successful, we're starting planet 8 with the starter 1000 cash. We'll then warp to 13, then start pushing through 12. The Sports Jetpod is really far out of reach with this route, so we'll no longer swing wormholes for fun and profit. No carrying them to items, no using them for breaking the 3.0 speed limit, none of that is possible. We can buy one Double-Strength Thruster or one Anti-Gravity for Planets 8 and 13, and we can buy two more after the singular challenge room prior to Planet 12. From what I remember, we'll still want to self-destruct in Planet 12, as while I do cart a wormhole all the way to that last fuel unit (in the published run), there is another wormhole a short distance further ahead. Due to menu time, we're highly discouraged from picking up a Double-Strength Thruster on Planet 8, then a second one on Planet 12. Anti-Gravity is very quick into the menu, so we can pick one up early and another later without loss. Therefore, we should only have one Double-Strength if we need it for Planet 13, but we can have one or two if we use Anti-Gravity instead. So, two Anti-Gravities and one Double-Strength Thruster, or two Double-Strength Thrusters and one Anti-Gravity? And which one for Planet 13? And when making the sacrifice at Planet 12, it looks likely we'll want both flavors for the first half, considering we're carting around a lot of fuel. We're doing a lot less carting around after the sacrifice, so one item should work fine. But it is possible to route in just one item on the first half so we'll have both for the final run, if that somehow saves more time. So many potential routes with the Double-Strength Thrusters and Anti-Gravity... P13 DST -> P12 DST+AG / AG P13 DST -> P12 AG / DST+AG P13 AG -> P12 DST+AG / DST P13 AG -> P12 DST+AG / AG P13 AG -> P12 DST / DST+AG P13 AG -> P12 AG / DTS+AG
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
So, at the published run displayed on YouTube, there's a comment or two.
Daniel Holmes wrote:
Would it save time to do the key underrun glitch?
Guggensulli wrote:
Yep with getting KeyFlow glitch in start of room 22. It would likely save at least 5 seconds overall. It could possibly go for it somewhere earlier too.
What is this and how do I do it? You are free to ask why I would randomly review my old TASes at times. Don't expect a satisfactory answer. Probably ego or something.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
My own personal preference is time to reach ending -- After all, null input is still input. But that's my philosophy. It's generally easier to measure "end of input" than it is to measure "time to credits", simply because we can very quickly identify the length of the movie file, but not when that movie file hits the ending. For logistical reasons, "end of input" is probably better for contest conditions.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
The team that provides the movie file that completes the game from power-on to credits (input end) wins.
Just for clarification, pick one: * Shortest time to credits (or otherwise a clear ending condition) * Shortest input file that, leaving the game on "auto-pilot" with null input, eventually reaches said credits I'm looking at the Frozen Laser ending of DTC6, in which the winning team reached the credits later than the runner-up team, but won because the input length was shorter. This has been a point of discussion a few times from what I can recall.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Memory wrote:
Watch you somehow get assigned to a team and still win
Only if that team saved frames on "name entry." And have no team name as a result. One contest even had a correlation between the length of a movie and the length of the team's name!
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Oh, I know! I can sign up, be technically part of a team, then basically disappear off the face of the contest, never to be seen during it! That'll fill a spot! Of course, I already said I'm basically disinterested at this point, so I might be surprisingly true to the above paragraph. Do not take this as a serious sign-up and a change of mind. On a more serious note, if you're not there for your team during the first week, it gets much, much harder to find motivation on the following weeks. Everyone else has already built a knowledge base, and you're starting from scratch.
Post subject: Debuggery. It's not solved, but I'm fetching more info.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Okay, okay. If I'm going to figure out much, I might need to track down how the game determines a hit. The Trace Logger and the Code/Data Logger together on FCEUX does amazing things. Set the Code/Data Logger, run the game on things leading up to, but not including the collision, then tell the Trace Logger to log only the newly mapped code the Code/Data Logger hasn't passed over yet. Sure enough, I find the code that works out how the bullets collide with enemies and other stuff they can collide with. The routine starts at 02:8272. I don't entirely understand how to tell bank, but I'm pretty sure that 02 has something to do with what bits of code is paged in. That's not too important anyway. What is noted is that I set a breakpoint on $8858, and it only triggers whenever bullets smack into something. Okay, it also triggers on loading a planet or something, but the breakpoint I set wasn't smart enough to care about what page it's on (it wasn't bank 02). So, what counts as a bullet hit? The routine at $8272 checks for a number of collisions, but I'm going to skip ahead to the part where it handles player bullets. Many, many bytes later, I'm looking at $8434. I see LDY #$03, and I know player bullets are IDs 03 to 0A. It scans until it finds a valid player bullet, then does a bunch of processing. I'm running my published TAS, and set a break for when I shot the warp. The Trace Log reports that a successfully detected bullet (ID 04) had stat 0317 (with ID 04, address 031B) == 08, which was not zero, which was not less than 7, and address 000D was equal to zero. After these conditions were checked, it then did LDX #$17, where enemies and other shootable things fill IDs 17 to 1E, and then starts checking stat 0317 of those things. Skip ahead to when it checks ID #$19, the object ID which spawns a warp portal when shot. 0317,X (== B8) wasn't zero, wasn't less than 6, and 0374,X (== 9D) wasn't FF. Without looking too deep, I also spot stats 0200 and 021F of both the bullet and the target being mathed together, then the same for 025D and 027C. Hitbox position checks. So... bullet existed, target existed and apparently accepting hits, and the two intersect. Call function. Let's open the movie that got our Warp to 8. Breakpoint on function $8858, and see what I get. Frame 2596: Object ID 1C (== B8) was hit by bullet ID 09, and got our first warp spawner. Frame 2597: Object ID 1C was hit again, by apparently the same bullet ID 09 as before. One frame apart? Normally the game does things every two frames. Also, the same function was called by the same offending bullet and target. I'm starting to think some interrupt acrobatics is taking place.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
I see it. Hadn't taken a look at it until recently, and I had a few assumptions about "begins from savestate." Without looking at it, I don't really have a good defense. Trying to build a lot of the context from scratch isn't helping much, though. I've been trying some disassembly and setting breakpoints, though I wouldn't say I've gotten things figured out. We can add 0393 to our list of object stats. Apparently, hitting a warp takes whatever is around that location (depending on object index, of course) and uses it as our destination planet. In the case of the movie, the object is at offset +0x0E, so 03A1 is our address when we hit that odd warp. As for what fills stat 0393, I'm not entirely certain. There's some kind of index that goes through increments based on how many objects exist, I think? The fact we have another warp object means an extra spot for an increment of this number, so the second warp leads to planet 8. We're out of object slots, having filled all four of the parts slots in the object table, so no additional increments look to be possible. 00BB is temporarily used to assist in filling 0393. Plenty of sub-frame calculations are done, so no guarantees memory watch is helpful. No analysis on how the extra warp came to be. This isn't really a conclusive analysis, though. I don't have all that great an idea on the pattern they decided to code in.
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Skipping an entire planet off the current route sounds rather interesting. I may not want to TAS, but I'm into analyzing things for now, so let's see what makes this tick. I've only briefly looked at the provided video. So I see the results of it, not its setup. A moving warp where it should be stationary is interesting. If shooting stuff to fill out the object addresses is apparently needed, then I suspect the timing of the interrupt routine is key to corrupting the warp. It sounds like something that should not happen but does. So, time to crack out my old scripts to relearn what's part of the object data, and the debugger to see what it's trying to do when being created. Any information on whether you might have shot the warp before the powerpak save state?
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
Oh, another one. I am bowing out, however. No sign ups from me this time. Haven't felt much TASing desire in a while. Since it's branching levels, it doesn't sound very conducive to the idea of incremental submissions that clear one level at a time. I mean, if it's anything like the Zook Man layout with an intro, a choice of stages, and the final stages, we could at least cut it into three segments, but it's a thought for later, I suppose. And hey, it might be interesting to see if the competition would try to analyze rivals' movies to figure out what techniques their opponents found to try and optimize later stages. And to discourage "hiding" the techniques until later, if optimizations were submitted for stages already due and done, cut the value of those frames saved down to a third or something. Anyway, for the rest of you, no repeat defending champ to worry about, so TAS this with confidence you'll all win!
Editor, Experienced Forum User, Published Author, Skilled player (1173)
Joined: 9/27/2008
Posts: 1085
There's my demon again -- The potential of an endless glitch or technique being discovered after publication. That turns the game into an endless scoring environment, making it impossible to properly obsolete when the next run itself could be trivially obsolete by just doing that endless trick a little longer. It gets worse if it's a combination of techniques that allows for it. Which one to ban? Mario's deaths, or his ability to collect 1-ups? Stopping either would be enough to make his visit to each stage in Super Mario Bros. a finite one. This stopped me earlier. And so far, this barrier is proving very solid. And my best answer so far is to rely on the apparent community to judge if it's appropriate, which is just not the rigid structure Vault would like.