This TAS more thoroughly demonstrates the concept of TI-83 speedcoding previously done by DwangoAC in
this movie. It also uses TI-83 v1.02 firmware.
Game Choice
The new movie uses a different game that as far as I know has not been TASed before on any platform, and so should allow for improved entertainment value. The code clones the DOS game Daleks, more information about it can be found
here. The basic idea is that you're the Doctor and Daleks chase you optimally each turn, killing you if they get to you. You have one use of the "sonic screwdriver" to take out all surrounding Daleks, and infinite use of the "Tardis" to warp randomly across the map with the infinite use being counteracted by the chance to land on a Dalek in normal play. The original game has a "last stand" function that is omitted as it would do nothing but slow down the code with no change in visuals.
Speedcoding
An explanation of the how the code that is written in the TAS works can be found in this
pastebin. Each piece of code is a single "token," usually corresponding to one byte but some tokens are 2 bytes. The TAS optimizes the path to find each token in the various menus. The Catalog contains every token and each letter can be used to warp to that point in the alphabetical list of tokens, an example of which is seen immediately when finding the "AxesOff" token. Many of the menus can be performed quickly by taking the number shortcuts to immediately drop in tokens (for example V->1->1 on the 2nd line of code inputs Xmin). An intentional unnecessary rand call is added to the input waitloop to allow for more complex RNG manipulation decision trees, being able to advance RNG an arbitrary number of times by waiting longer to move the Doctor. The final program takes about 400 bytes, and I believe up to 100 levels should technically be possible with the size of the List data storage type if the level restriction is omitted, though the code would likely run too slow for later levels to be watchable.
The code avoids two severe speed issues from the previous TAS: first, LBL and
GOTO should be avoided like the plague in TI 83/84 BASIC. The BASIC interpreter does not search efficiently for LBL and doesn't garbage collect properly after using GOTO. Also, another interpreter bug exists in the
for instruction. For loops should always have a closing parenthesis even though the language does not typically require them due to the "End" token actually marking the scope of the loop. For some reason, "If" statements are massively slowed when the closing parenthesis is omitted, as explained on the linked wiki page for the "For" instruction. Many of the other techniques are explained in the pastebin linked at the top of this section.
Gameplay
The gameplay attempts to demonstrate the first nine waves, up to ten Daleks. It makes clever use of the programmed-for RNG manipulation to create fast initial enemy positions, warp efficiently, and make strong use of the sonic screwdriver. It is likely the game can be completed faster, but as described in the previous submission and judge notes it is extremely difficult to tell if any given RNG is optimal given the nature of the RNG running off a seeded rainbow table. Any given combination of initial seed and waiting for teleports could lead to faster gameplay, but then could destroy the run if slower RNG is ahead in the table.
My hope is that the more technically researched choices in BASIC code and programming menuing and more unique gameplay could lead to a change in ruling compared to the previous submission. Speedcoding in assembly can also be done on-calculator using the asm( instruction, but there would be no technical complexity in the (lack of) menuing for the "speedcode" portion of the TAS. TASing released assembly games is a whole other problem on the TI-83, as its "power on" state does not load a "ROM" like typical consoles so the game would need to be deployed in some manner prior to the gameplay portion of the run, but perhaps running from savestate would be allowed to enable some form of more traditional TI-83 TASing.
Maru: I'm judging this a little bit differently than I have judged other TASes. Basically for this submission, I just decided to sit back and see what feedback this TAS would get. Even after the massive code efficiency improvement, feedback did not drastically change. It seems mostly agreed upon that these speed-coding demonstrations have to be eligible for the Moons tier or higher. Currently, the reason why it cannot go into Vault is because it is an unofficial game with some code changes (thus it is a hack) and has gameplay resembling Vault submissions. Feedback in terms of entertainment did not quite cut the gap. I understand that there is a hardware limitation with what you were trying to accomplish. There may have been more positive audience reception with a speed-coding demonstration if it was done on a calculator like a TI-84 Plus CE, which has aesthetic and technical merits over the TI-83, but BizHawk does not support that at the moment.
Regarding speed-coding demonstrations, if a future submission does get decent feedback, then we will have some work to do, but this unfortunately was not the one. Although I am rejecting this, I do respect this type of craft and do encourage you and others to continue exploring in the realm of speed-coding.
