Experienced Forum User, Published Author, Experienced player
(878)
Joined: 11/15/2010
Posts: 267
Nice improvements. After I did some RTA runs and some other runners picked it up I knew there were routing issues on the ship, and I was pretty sure the mushrooms could be faster. Looks like you made a couple of other little improvements as well. great work!
Experienced Forum User, Published Author, Experienced player
(878)
Joined: 11/15/2010
Posts: 267
Nice to see the RNG get crushed, and the movement is crazy. Unfortunate that some much of the time is spent counting the score between stages. Definitely a yes from me
Experienced Forum User, Published Author, Experienced player
(878)
Joined: 11/15/2010
Posts: 267
feos wrote:
Does this game require/involve any non-trivial routing?
I would say yes.
I didn't spend much time looking at the strategy aspect of the game, but the strategy used here seems to make sense at a high level. If you played this game "blind" I suspect you would not arrive at the strategy used here on your first attempt. It doesn't seem like the strategy used is complicated, but the RTA run uses the same route, and FRK seems pretty thorough from what I've seen.
The fight is also non-trivial, as I said before I saved time compared to FRK and if it were truly trivial I suspect that would not have been possible. The fight is short, and I wouldn't say it is extremely complicated, but I think calling it trivial is over-simplifying it. Which turret do you kill first? When and where do you move to avoid dying? What is the fastest way to deal damage? If it was trivial I would be convinced that the fight could not be further improved, but as noted in the improvements section I have not ruled out the possibility of further improvements.
Experienced Forum User, Published Author, Experienced player
(878)
Joined: 11/15/2010
Posts: 267
Samsara wrote:
link_7777 wrote:
GJTASer2018 wrote:
The previous submission of this game was rejected for triviality, and I don't understand how this is supposed to improve anything. Voting No.
It is 3 frames faster, so clearly there is something non-trivial.
I can weigh in on my decision a little bit.
My usage of trivial didn't refer to the game's ability to be improved, it referred to the game itself. Even with a three frame improvement, nearly the entire running time is still menus with one 5 second section of shooting at the end. Over 99% of this run cannot be improved by virtue of it being all menuing, and if the last submission's comments are any indication, it would be 100% identical in an RTA run. It didn't quite feel right to me to publish a game where only <1% has any competition, especially when the shooting section doesn't look noticeably tool-assisted.
I do think it deserves a second look from a different eye, though. Game choice was always one of those things that felt a little too subjective for a single person to decide.
Thanks for the info from the rules side ThunderAxe31.
As for the game side, I think there is a misconception that since often menus are really easy to optimize when making a tas that it translates to them being trivial and easy to reproduce RTA. There are runners that are great at menuing, NESCardniality comes to mind. I compared this run with ShesChardcore's current record for this category (the menuing is probably reasonably good, I know Chard as someone that runs a lot of very short categories, so I think it is likely a bunch of them are heavy in menuing). From the end of the intro to the beginning of the fight is 12449 frames for Chard, 12248 for this run. This is a difference of over 3 seconds (keeping in mind that a large chunk of that time is just wait time).
I agree that the fight at the end is the main interesting part of the run, and it is quite short. I think the fight looks tool assisted compared to the current record, but part of that may be because I spent some time trying to optimize it. Admittedly it would probably look less tool assisted to a more casual observer.
Thanks for weighing in Samasara, and I'm glad you think it deserves a second look. I was initially going to mark this as unpublishable for TASMania, but I decided to revisit and look for an improvement. I know there have been rule changes and I figured if I could shave a few frames it could be revisited under a new submission.
Experienced Forum User, Published Author, Experienced player
(878)
Joined: 11/15/2010
Posts: 267
I described how the difficulty worked a bit in the submission notes, but here is a much deeper analysis. The spawn rate is nearly maxed out in the last stage anyway, so I'd be surprised if additional code to set it one point higher existed.
Here are the difficulty parameters and the code that changes them (with pseudo-code). As I said it looks like it uses the count of bombs in the stage to set the rest of the parameters, and the bomb count gets capped at 60.
Experienced Forum User, Published Author, Experienced player
(878)
Joined: 11/15/2010
Posts: 267
After making further adjustments to the script I've improved the final run time to 6:03.04 from the originally submitted 6:05.15. The new focus is in-game time and here is a table that shows the improvements to each of the hurldes races.
http://tasvideos.org/userfiles/info/63854639035495257
Experienced Forum User, Published Author, Experienced player
(878)
Joined: 11/15/2010
Posts: 267
It doesn't seem like they were too tight on memory, so they probably opted to make the code simple. This does seem in direct contrast to the score though. The score isn't even kept in memory, they directly use the nametable itself. I had to do a slight hack to even check what happens when the score maxes out (it just rolls over) since there is no way to poke the nametable value in the emu
Experienced Forum User, Published Author, Experienced player
(878)
Joined: 11/15/2010
Posts: 267
Looks like when you press a button it puts any values in an array at 0x314 and adds to the outstanding count at 0x43. it looks like it uses decrement to process so if there are 0xA outstanding items it will process 0x314+9 first. Essentially it looks like it is a stack (lLIFO), so you could delay processing of an earlier input buy using other inputs. I would note that the elements are 0 based, so if you press button "2" it will put a 1 in the array (0-B instead of 1-C)
Experienced Forum User, Published Author, Experienced player
(878)
Joined: 11/15/2010
Posts: 267
Nice one again Blazephlozard. I suggest swapping movies and adding Blazephlozard as a co-author. I also added edit privileges in case you wanted to make changes to the submission text. I also added permissions for you on the Rollerblade Racer submission.
I have in my notes that 0x12 and 0x16 are the user inputs, but maybe one of them is holding for later processing? I did notice the the fairly extensive buffering, but didn't really think to abuse it to end input early.I didn't see were they were buffering the data, but I have in my notes that 0x43 is the outstanding input check count. This seems to be how it knows that there are buffered inputs that it still needs to process.
Experienced Forum User, Published Author, Experienced player
(878)
Joined: 11/15/2010
Posts: 267
Nice work Blazephlozard! I also suggest the movie be swapped and Blazephlozard be added as co-author. I was thinking that before I read that far into your comment.
The submitted movie was 21944 frames, the new one that I posted is 21789, so it is about 2.5 seconds faster. The original submission also ended input early, so it is slightly better than that, and that is why the race 6 time is much slower in the original submission. Without ending input early the race 6 time would have been 11.89
The new race 1 is an improvement on the original submission, but not as fast as what you found. Looking at the input I'm guessing you were trying things manually and ended up having better luck. For the new movie I wrote a script that tried to optimize, but it definitely isn't checking all possibilities. I believe the script to make this movie was trying combinations of 2 blank frames in the first 16 frames, then running out to 128 frames and checking the mini map position. It would then capture the first 8 frames from the best run and repeat. I attempted to improve on this by making it combinations of 11 and capturing 2, but that turned out to be slower
Experienced Forum User, Published Author, Experienced player
(878)
Joined: 11/15/2010
Posts: 267
feos, based on the movie file you posted I have to think there is still some room for improvement. I finished with some scripting and came up with this
http://tasvideos.org/userfiles/info/63688943399108546
I think your argument is that the goal should be in game time, and I think the more time I've spent on it I would agree with that choice. The movie I posted is 4 frames ahead after the 3rd opponent, but as you've been suggesting it probably makes more sense to compare in-game time. The time for the normal races is always 5.38, but the times for the hurdles vary greatly
Comparing the one I just posted to the one you posted the other day (hurdles only):
unfortunately I don't think the hurdles are very sync stable, so from here I think we have several choices.
1. Update the goal and switch to the movie I just posted
2. Play around with the lua script and rerun to try to find improvements.
3. Argue further about the goals.[/list]
Option 1 is the easiest, and while it is easy to argue that the 1st race is improvable it is really hard to say what that would do to the possibilities on the other races.
I think with the amount of time I've spent running scripts I'd lean towards option 1, but I think whatever makes this so hard to optimize also makes it hard to judge. Thoughts?[/list][/code][/url]
Experienced Forum User, Published Author, Experienced player
(878)
Joined: 11/15/2010
Posts: 267
No. The multi-player mode isn't really something you'd TAS, it is more of a party style thing. There are more events, but you play one at a time and just compare results. You aren't competing against a CPU like you are in single player
Experienced Forum User, Published Author, Experienced player
(878)
Joined: 11/15/2010
Posts: 267
I wrote a script to help me try to optimize the other hurdles events in an attempt to clean it up. As you've described it has definitely saved an amount of real time in the overall movie. The game looks very straight forward, but it definitely isn't.
I'll compare my updates to what you've posted. Some of the scripts may finish today, so we'll see where we are when that is done. I may have something new, or I may need to make some adjustments and continue testing
Experienced Forum User, Published Author, Experienced player
(878)
Joined: 11/15/2010
Posts: 267
I'll spend a little more time looking at optimization, though in this case I'm not sure getting to the finish line as fast as possible is going to be any different from waiting to cross the finish line for dramatic effect.
It may be that a second look buys a few lag frames, so I'm checking it out a bit, but that is probably a better reason to look
Experienced Forum User, Published Author, Experienced player
(878)
Joined: 11/15/2010
Posts: 267
feos wrote:
TASVideoAgent wrote:
the hurdles in 110M hurdles don't behave consistenly for each race. I did try to optimize the handling of hurdles for the first race, but it doesn't matter since you have to wait for the opponent to finish anyway.
Why not aim for in-game time?
I guess I didn't think about it much when I was making the run in the first place, but originally it didn't seem like it was worth the time to try to optimize every hurdles race.
Now that I'm thinking about it there are a couple approaches, There is manipulating the timer, and then there is optimizing the middle races (since only the first and last one are optimized as submitted) which is what I think you were getting at.
As for manipulating the time it looks like the in-game time roughly approximates real time (somewhat poorly, it is a bit slow), so I doubt there is a direct manipulation for the time. The timer does seem to stop for animation changes sometimes, but I think that is probably lag (though the game does still read the controller inputs on those frames). I haven't really checked, but this may mean you could shave a few frames of lag somehow.
I could spend some time trying to optimize the other races, but now that I look back at it I'm not sure it would be more entertaining. Both the jumping and the hurdle hit detection are pretty sketchy. The more optimized runs manage not to crash, but they still have significant pauses to line up running through the hurdle. From that standpoint the races that run through the hurdles provide slight (very slight) variety.
I guess overall I'd argue that it doesn't make much difference and therefore probably isn't worth spending time on. But I'm willing to hear arguments and if people think it is worth optimizing I could probably spend more time on it
Experienced Forum User, Published Author, Experienced player
(878)
Joined: 11/15/2010
Posts: 267
I was expecting to see more dash-jumps on the springs in the early parts of the revolution. Are the springs too close for dash-jumping or something? or is it not faster?
Overall though, outstanding work. Yes vote for sure