Submission #7464: p0008874's Uzebox 2048 "maximum score" in 02:17.35

Uzebox
maximum score
(Submitted: maximum score)
(Submitted: 2048.uze any v1.0)
BizHawk 2.8.0
8243
60.01631993960238
5982
PowerOn
Submitted by p0008874 on 5/1/2022 11:33 AM
Submission Comments
Follow the lulz if you want the truth: https://edramatica.com/Tool_Assisted_Speedrun
This run is continue [4640] Uzebox 2048 by p0008874 in 00:46.29 with Aims for maximum score and Heavy glitch abuse.
The source code of score, 65536 will force to 0 due to overflow.

Samsara: I can judge it. I can judge it 2048 times.
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!

despoa: Processing...
Last Edited by p0008874 18 days ago
Page History Latest diff List referrers