The point of contention for me wanting to use this run as a rule changer was over what we constitute as "maximum score". The game continues incrementing an internal score counter when the display score is maxed out and overflowed, meaning we would have had to come up with a solution for that, and the solution is simply... "Nah." That is, an internal score counter should not solely count as maximum score. Maximizing (or overflowing) the displayed, observable score in game can and should be considered a valid goal here. At most, a run that maximizes the internal counter would supersede a run that only maximizes the displayed counter. We would never strictly require the internal counter to be maximized. Some very quick and dirty math leads me to believe that a run that maximizes the internal 4byte score counter would be somewhere north of 50 days, assuming that the exact pace of the TAS is kept all throughout, and that's about as unreasonable as it sounds to me.
That being said, I'm happy for any rule change that allows for more runs to come in, and I'm happy to accept those runs, and naturally I'm happy to accept this one as well!
Joined: 5/22/2020
Posts: 197
Location: Chennai, India
Here is an encode:
Link to video
I voted no on this one, because it doesn't feel like a satisfying goal to me, and the fact that I can only watch numbers shuffle around the screen for so long. Regarding the optimization, I don't know if there is a better strategy that can be used, but what this movie seems to do is the human strategy of neatly tucking the highest powers into a corner (which admittedly is a good strategy).
Thanks for the encode!
Well, looks like this port is very bad compared to the original one. I assumed that the number of tiles are not maximized. In this port, after tile 2048, the tile just disappears (?), so I don't know what's the point of continueing the game.
In the original and in majority of different ports, the largest tile is 131072 depending on what the final tile will be.
Example video:
Link to video
I personally really liked to the point before the 2048 tile magically disappeared, which seems like a simple "restart" the game while continuing...
I would vote yes of another 2048 port with "maximum score" objective, but voting no on this game's TAS for not having the difficulty of going for that goal.
Sorry if I "wasted" your time p0008874, I was more concerned on letting my voice heard over investigating a seemingly random port of the game and thinking through how would a maximum score TAS would look like.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Well, looks like this port is very bad compared to the original one. I assumed that the number of tiles are not maximized. In this port, after tile 2048, the tile just disappears (?), so I don't know what's the point of continueing the game.
The tile does kind of exist as "4096", but without any graphic so it is invisible (but sometimes it glitches and shows some other number).
In fact, after testing by poking values into RAM (the board is represented by addresses 0xA54 to 0xA72, 2 bytes each, specifying the value of the tile), you can get "higher tiles" like 8192, 16384 and 32768, and the game will add the correct score. However, combining two 32768 tiles will cause them to disappear entirely and be replaced with a "no tile" in that position. This means the game can go on forever.
Joined: 5/22/2020
Posts: 197
Location: Chennai, India
Technical stuff:
* Syncs fine on Bizhawk 2.8 (uzem core).
* SHA1 hash of the ROM used is f78f8bd532e021c7c71e0306593d40b98591ee97, which is an established good version.
Optimization:
The strategy used is not different from the published run, so it's also established to be fine especially given there is not much room for manipulation in this port.
Goal choice:
Here comes the hard part. The author claims that the score overflows to 0 when 65536 is reached, so they have basically planned out the game over to happen at this exact value. However, from a little research, it seems like only the "display score" is overflown at this point. The 4 byte address at the location 09E0 shows the correct score. The fact that the game knows that it is higher than the placeholder scores is further evidence that the game atleast internally keeps track of the score properly. Given this knowledge, its possible to get a much higher internal score, which can be kept track of with a lua script. Now if we are to make the branch "maximum display score" instead, then it would make more sense to game over at 65534.
Joined: 11/13/2006
Posts: 2792
Location: Northern California
Alright, let's get some discussion in here. There's two questions to ask regarding this run and the state of this category in general.
1. Should we allow "maximum score" as a standard branch universally?
Currently, we allow it as a form of full completion, but this does not catch 100% of cases, which is a bit ironic for full completion, really. The proposed change to the rule here would just be to allow "maximum score" as a branch independently of full completion. We would likely lessen the rules on methodology in this case, maybe only disallowing unassisted infinite loops and ACE.
This change would also apply to timed games where the only objective method of competitive play is score. This could mean allowing timed sports games as well, but the mere thought of having that conversation again is giving me PTSD. We'll see.
2. For infinite games, how do we define "maximum score"?
Max score for timed games like Sharp Shot is easy to define, but what about games like this where play can be infinite? Some of the prior discussion in this thread has revolved around the nature of this game's score counter, and defining maximum score in relation to that counter is an important distinction for us to make, especially if we're going to broaden how we treat the category itself. In this case, the distinction is between the displayed score and the internal score counter. The display score is indeed maxed out and overflowed, but the game continues to internally keep track of score beyond that. Should we demand that a maximum score run max out the internal counter, or should we just stick to display score?
My personal stances here are "yes, allow max score universally" and "stick to display score", but I'd like to see other opinions. That, or a bunch of people agreeing with me. That also feels nice.
TASvideos Admin and acting Senior Judge 💙 | CohostwarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
1. Should we allow "maximum score" as a standard branch universally?
Currently, we allow it as a form of full completion, but this does not catch 100% of cases, which is a bit ironic for full completion, really. The proposed change to the rule here would just be to allow "maximum score" as a branch independently of full completion. We would likely lessen the rules on methodology in this case, maybe only disallowing unassisted infinite loops and ACE.
I totally agree with this part.
Samsara wrote:
This change would also apply to timed games where the only objective method of competitive play is score. This could mean allowing timed sports games as well, but the mere thought of having that conversation again is giving me PTSD. We'll see.
I agree with timed games where you can have a final input as soon as possible but sport games are a little bit difficult for me right now...
Samsara wrote:
2. For infinite games, how do we define "maximum score"?
Max score for timed games like Sharp Shot is easy to define, but what about games like this where play can be infinite? Some of the prior discussion in this thread has revolved around the nature of this game's score counter, and defining maximum score in relation to that counter is an important distinction for us to make, especially if we're going to broaden how we treat the category itself. In this case, the distinction is between the displayed score and the internal score counter. The display score is indeed maxed out and overflowed, but the game continues to internally keep track of score beyond that. Should we demand that a maximum score run max out the internal counter, or should we just stick to display score?
I will here continue with my rule change suggestion posted on the proper thread that has a new fresh look thanks to this situation:
I would say internal score should be the only matter :
1) display score is overflowed and comes back to 0 : no problem i think.
2) display score is overflowed and locked at the max value : same but if not possible, we count it ourselves.
3) display score is overflowed and glitched : internal counter is the only way to keep tracks of the score in this situation so this is the only way.
For this submission, I would also like to give a suggestion: like at one point with infinite games for fastest completion : We could accept both TASes that go for max displayed score and max internal counted score but the one that goes further point will obsolete the other (not only max displayed score VS. max internally counted score) ? It should mean than with this, this run should be accepted and could be obsoleted with a maximum internal score.
1. Yup, sounds good to me. To make things less onerous for judges, the proof that the score really is maximized could just be that it beats all other known scores and there are no obvious ways to increase it further. I also think that if a score is beaten, the higher score obsoletes the lower score, even if it doesn't beat the time (and other obsoletion rules apply, i.e. don't be needlessly sloppy in unimproved areas).
I don't really have a problem with allowing timed sports games for this. Trying to score as much as possible in sport seems like a formidable, albeit repetitive challenge.
2. Trying to look at this from a casual viewer's perspective, I think using the display score is the more appealing option. It just seems more approachable to me. Viewers should not require knowledge about RAM watch to comprehend the goal. A maximum internal score run just seems like reaching the max display score, continuing past that with no perceivable progress, and then randomly ending with the implication "ok, it's maxed out now, just take our word for it".
imo, allow max score universally, and allow for max display score. If it tracks more internally, that could supersede max display score but should not be required.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
1. Should we allow "maximum score" as a standard branch universally?
Currently, we allow it as a form of full completion, but this does not catch 100% of cases, which is a bit ironic for full completion, really. The proposed change to the rule here would just be to allow "maximum score" as a branch independently of full completion. We would likely lessen the rules on methodology in this case, maybe only disallowing unassisted infinite loops and ACE.
This change would also apply to timed games where the only objective method of competitive play is score. This could mean allowing timed sports games as well, but the mere thought of having that conversation again is giving me PTSD. We'll see.
I feel the current full completion rule "Glitches and memory corruption may still be used as long as they do not directly affect requirements" would make sense for "max score" as a new separate Standard goal.
Among human score attacks, infinite pattern is a known problem, and it seems to generally be considered a thing that defeats the point of a score attack? So that would be the second limitation I would like us to keep, until someone makes a point why it may be a good thing to allow.
So yeah, both rules we already have for max score.
Samsara wrote:
2. For infinite games, how do we define "maximum score"?
Max score for timed games like Sharp Shot is easy to define, but what about games like this where play can be infinite? Some of the prior discussion in this thread has revolved around the nature of this game's score counter, and defining maximum score in relation to that counter is an important distinction for us to make, especially if we're going to broaden how we treat the category itself. In this case, the distinction is between the displayed score and the internal score counter. The display score is indeed maxed out and overflowed, but the game continues to internally keep track of score beyond that. Should we demand that a maximum score run max out the internal counter, or should we just stick to display score?
My personal stances here are "yes, allow max score universally" and "stick to display score", but I'd like to see other opinions. That, or a bunch of people agreeing with me. That also feels nice.
I think the default end point should still be whenever new content has been completed, or when the difficulty has stopped raising. If there's a kill screen, it's also still a great reason to finally let it go already. And if the score overflows or stops after that point, that's just one more valid ending point.
As to what to actually consider the definitive counter, relying on the visible one makes the most sense. If it glitched, internal counter may have to be used instead. And if the visible counter works okay, it may indeed look confusing to ignore it and reply on the internal one instead.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
To make things less onerous for judges, the proof that the score really is maximized could just be that it beats all other known scores and there are no obvious ways to increase it further.
BTW I don't even think we need this proven. We just need it to look optimized, which means not easily improvable by a lot.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
To make things less onerous for judges, the proof that the score really is maximized could just be that it beats all other known scores and there are no obvious ways to increase it further.
BTW I don't even think we need this proven. We just need it to look optimized, which means not easily improvable by a lot.
I'll agree with that. After all, we have the same standard for judging optimization in every other run. However, I still think the score should match or beat all known scores. There's not much of a point in calling the branch "maximum score" if somebody can just point to a higher score during judgment.
I'll agree with that. After all, we have the same standard for judging optimization in every other run. However, I still think the score should match or beat all known scores. There's not much of a point in calling the branch "maximum score" if somebody can just point to a higher score during judgment.
Right.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
