This is a
TI-83 TAS, but it's unlike anything ever submitted before. Rather than loading a game, this run writes it... and *then* TAS's it. Slowly. In all the glory the TI-8x line is (in)famous for. Also, the game is *really* broken for how short it is - it's like the result of Snake and Astroids swapping a few too many digital bits without using (memory) protection. Or something. On second thought, forget that analogy and
take a gander at the source code in its entirety:
26üK
1.1üB
{4AnsüA
ClrHome
For(A,1,û2
randInt1,16)+.1randInt1,8üC
Repeat C=Ans(1
Aüdim(áA
áA(1
Output(10fPart(Ans),int(Ans),"O
Output(10fPart(B),int(B),"
Output(10fPart(C),int(C),"*
getKey
If Ans=45
Goto 0
If Ans=34 or 2>abs(Ans-25
AnsüK
áA(AüB
áA(1)+(K=26)-(K=24)+.1K=34)-(K=25
If max(áA=Ans
Goto 0
Ans+16(not(int(Ans-(17=int(Ans)))+.8(not(fPart(Ans))-(.9=fPart(Ans
augment{Ans},áAüA
End
augmentAns,{Ans(AüA
End
Lbl 0
ClrHome
A
As ais523 put it, that's some pretty serious mojibake for anyone without the proper fonts installed, so I recommend viewing the source code from the
TI Basic Developer site on the
Snake wiki page if you're interested but I wanted to include it here so it's clear exactly how little code this game is derived from.
Speedcoding
The highlight of this TAS, and really, the only reason to watch it, is the speedcoding (writing source code as fast as possible) at the beginning of the run. I was inspired by
Bisqwit's NES emulator speedcoding project, which I've always been amused by. When I started looking into making a TI-83 run many months ago I discovered that it was possible to load an .x8p file or create a movie but not both at the same time, so I started down the path of writing a game. I jumped in without considering the consequences and immediately got stuck because I, er, didn't *really* know how to use a TI-83 calculator, or at least not how to write a program with one. I initially thought I could literally type the commands out, but that doesn't work - after reading the
TI-Basic starter kit page I discovered you have to delve into each menu, such as the Prgrm menu, and select the symbol for a For loop, or an If, and even to write a = operator. I considered writing a complex Lua script but opted to enter everything manually, and the process became much faster once I realized I had to start thinking like an EMACS user.
Of course, by doing it by hand I encountered a number of issues when I missed ) characters or mistyped list symbols and I caused myself great pain as hexing everything in kept causing desyncs. There is a substantial amount of lag that changes depending on where things are on the screen which makes hexing a nightmare. There are lag frames every time you enter a menu, every time you create a newline, pretty much lag any time you repaint the screen in any way other than writing a single character on the same line. After entering all of these commands manually I exit programming mode and enter execution mode which starts the game Snake. I opted to make no changes at all to the source code to stay faithful to the published code, although I later regretted not increasing the drawing speed.
Why I chose Snake
When I was a teenager I had a
Compaq 386 20 MHz luggable with an orange plasma display and I had a copy of a math learning game called Googol. You can play
Googol Googolpede here in a browser. Googolpede was a great way to practice my math facts - you'd have to run your snake into either T or F to answer questions, and it could be quite challenging - you'd have to solve the equation while avoiding walls or yourself. It left a deep imprint on me and I've enjoyed Snake ever since - I was thrilled it was highlighted at
AGDQ 2014, but I digress.
About *this* variant of Snake
This simple variant of Snake has some quite interesting features considering how compact it is:
* Segmented snake parts and stuff to eat that shows up inside you!
* The ability to wrap around the edges of the screen!
* The ability to phase through body parts at the edges!
* Snake coiling!
* Really bad controls!
* RNG that isn't!
* Really slow movement that gets even slower when you press buttons!
Needless to say, the game is quite abusable, and thankfully has an obvious ending (although it takes quite a while to get there, but more on that in a moment). For starters, the game moves the head of the snake 5 frames before the end of the snake is advanced forward, as if you're growing and shrinking repeatedly. The result is you can't directly chase your own tail and you have to be one segment behind it. Additionally, after drawing your new snake location on the screen, directional button presses for the next 5 frames will impact what happens when the next segment is drawn, and button presses after that point affect what will happen after the one after that is drawn. In other words, you have to press buttons in advance, which is unnatural and annoying.
The game starts fairly tamely in part because with only a single segment it's not like you can run into yourself but that starts becoming a problem very quickly (well, if you consider the glacial pace of this game quick). Once more than one segment shows up you start to notice that * food bits show up regardless of whether your body is already occupying that space or not, meaning you have to move yourself out of the way before you can eat it or you'll collide with yourself instead of eating the food and die, unless you're at the edge of the screen. Let me break that down:
You can wrap off the edges of the screen, and if a part of your body is at the edge of the location you're appearing at it's possible to phase through your body (i.e. you're in the same place more than once - sometimes way more than once). Sometimes when you do this your body part becomes invisible leaving land mines for you to find later if you forget where you've been. This property can be heavily abused in the four corners where it's possible to coil yourself by repeatedly phasing into yourself. I use this several times to artificially shorten the snake length, although it takes time and I was going for pure speed since this is likely only Vault material so I avoided it when possible.
It's a good time to note that the RNG isn't actually random. The first game you play will always start with the first * food piece in the lower right, and then the next position is always the same, and so on - in fact, player controls have no impact whatsoever on the RNG, so the only thing you can do is reposition where your snake body is so future *'s appear where you can get to them. This starts to get exceedingly difficult as your body grows to the point that you end up constricting where you can move.
Every time you eat a * your body grows by one and your score grows by 1, starting at 0 points. I'm not sure why yet from looking at the code but when you hit 100 points the next food piece you eat ends the game, showing the score in the upper right corner. I'm quite happy about this, as the next obvious goal choice would be to completely fill the screen which would take another 28 points and the run was way longer than I thought possible as it was.
Sync info
As I've implied above, this was created using only the calculator's 1.02 version firmware (which you can dump from an appropriately outfitted TI-83 calculator using
these instructions). This run will desync if using 1.07 firmware.
So, sit back, watch the run on Turbo, and enjoy! Thanks go to adelikat for making the emulation possible and thanks to Spikestuff for the encode.
Noxxa: This is a really interesting run, and its idea of tool-assisted speedcoding to create and then run a game at once is pretty nice. However, there are a few flaws with this particular run that bring it down:
- First of all, the resulting run is extremely slow-paced and boring to watch. It takes 20 minutes to get 100 points, which means collecting food at an average rate of five per minute, or one per 12 seconds. That is very slow. The game has no sound or visual appeal to speak of, either, as the snake entirely consists of 0s.
- The game's "random number generation" is completely deterministic, which makes the game trivial to run - as long as you have mapped out a route (and with some practice), it is possible to do a perfect run with ease. The game's controls are bad, but not impossible to work with.
- While the RNG is deterministic, it can still be manipulated before game start, which could lead to potentially shorter routes and faster times. Neither the author nor anyone else has tested this, but I find it unlikely that the first seed is the best seed with regards to route length. This would need to be checked before we can ascertain whether the run is optimal.
- The code sample used to create the game in this speedcoding run is a slightly notable example of a game program, but it is by no means official and as such, there is no reason to adhere to using this version, and not a version that may be optimized to be faster, better looking, have better features, or be superior in some other way. To accept a run like this as a speedrun, we need to set criteria as to what game sources we'll allow, and there is no particularly good reason to accept this as an "official" Snake build. Therefore, this run would have to be judged like a homebrew game.
Furthermore, I don't believe tool-assisted speedcoding is a concept that should work its way to the Vault. The
Vault was designed as a repository for speedruns of any game that can viably be speedrun, and speedcoding does not fit the same mold. It does not ordinarily speedrun a game, so it does not really belong in the Vault.
Even if it did qualify for the Vault, I would still hold against this run the second and fourth points outlined above, which respectively make the run fail to qualify on TAS-worthiness, and lack of sufficient notability of the game version. The third point also makes me doubt whether the run is optimal.
The tool-assisted speedcoding concept in this run would be good for a showcase run for Moons, but as outlined above, this run has many flaws that make it uninteresting to watch, which means this submission ends up with no good place on the site for it. As such, rejecting.