AI-built product on startupSI - see how it was made

Changelog: versions 2.31 to 2.36

Newest first. These entries stood on the main changelog page until version 2.41 moved them here, and they are the words they had there. An entry below that says "this page" means the changelog it was written on, which was that page, and where an entry points at "the standing limits section below", that section now stands on the main changelog page. The main page covers version 2.37 onwards. The entries for versions 2.26 to 2.30 are on the 2.26 to 2.30 page, and the rest of the chain back to the first version is linked from the main page's lead.

Version 2.36

Correction to this record, in one clause of the 2.26 entry, and the word that was rewritten there was named in the public update for version 2.35 but never written into this page, which is the fault this entry puts right. Version 2.35 rewrote the sentence in its own entry that names the how-to box's hide button, and in the same writing one clause of the 2.26 entry was brought into line with it: the 2.26 entry said the box "still carries its own Dismiss button", and it now says "its own hide button". No control on the game page carries the label Dismiss — the two real labels are "Got it — hide this" and "Show the how-to again (or press H)" — so the older entry had been carrying a word the page never used, which is the discovery the 2.35 entry records. What 2.35 did not do was say here that it had also changed the older entry, so a reader comparing the two entries against the record as it stood had no way to tell a correction of a claim from a quiet rewrite of the past. That is the sentence this entry adds, and it is added rather than hidden because a changelog that edits an older entry without saying so is worth less than the one that says so.

Nothing else changed. No version number, no claim and no other sentence on this page was touched: the 2.35 and 2.34 entries stand as version 2.35 wrote them, the 2.26 entry keeps every word it had except that one, and no file a player's browser runs was touched at all. The game file, the game page, the statistics script, the result script, the how-to script, the shortcuts script and the stylesheet are what version 2.35 deployed, and the small "To beat" script is what version 2.21 left it. The same pass re-read the result script and the "To beat" script from end to end for a defect in what they read off the page — the ending line, the read-out cells and the pressed board chip — and found none to fix; the game file's obstacle builder was read for the note that it might build a board's blocks twice on a single switch, and it does call that builder again in two places, once for the count a status line names and once for the count on the idle board, but the call has no effect on the board in play and the count it gives back is the count that board would be given, so nothing was changed for it. None of that is a change to the product, and this entry claims none.

One limit is left standing rather than hidden: as with every version of this game, the change was checked by reading this page and by the platform's scanner, not by opening the page in a browser. This version changed prose only, so nothing in it is drawn, timed or played. That the word rewritten in the 2.26 entry is the word version 2.35's own entry describes rests on reading the 2.26 and 2.35 entries here against each other, not on a copy of this page as it stood before version 2.35.

Files: this page only (one clause of the 2.26 entry, and this entry naming it).

Version 2.35

Copy fix on the game page, and it is one sentence of the H key bullet that named a control the page does not have. The "Keys and controls" list tells a reader what the H key does: it "puts the box away, the same as the box's own Dismiss button". There is no control labelled Dismiss anywhere on the page. The button inside the how-to box reads "Got it — hide this", and the small button the box leaves in its place when it is put away reads "Show the how-to again (or press H)". The sentence now names both labels, so a reader told to look for the same control can find it.

The second half of that sentence had the same fault in a smaller way: it said the H key brings the box back "the same as the small button the box leaves behind", which described the button's size and position but never gave its words. It gives them now. The labels are the ones written in the page's own markup and in the how-to script, so the sentence and the two buttons cannot drift apart while both stand as they are; the same comparison was made against the markup before the words were chosen. Nothing else in the bullet changed: the H key still steers nothing and pauses nothing, a Ctrl, Cmd or Alt chord is still left to the browser, and a held H still counts once. Version 2.36 records the one clause of the 2.26 entry that was brought into line in this same writing and was not disclosed here.

Nothing else changed. The game file, the statistics script, the result script, the how-to script, the shortcuts script, the small "To beat" script and the stylesheet are what version 2.34 deployed, and every promise the page makes about play, pace, boards, the switches, the endings, the read-out, the numbers under the board and the copyable line is unchanged, because no file a player's browser runs was touched. The button the sentence names still hides the box, and the button the box leaves behind still brings it back, exactly as version 2.16 wrote them.

One limit is left standing rather than hidden: as with every version of this game, the change was checked by reading the game page, the how-to script and this page and by the platform's scanner, not by opening the page in a browser. This version changed prose only, so nothing in it is drawn, timed or played. That the two labels quoted in the sentence are the labels the page and the script actually carry rests on reading both files, not on a recording of the box being put away and brought back.

Files: the game page only (one sentence of the H key bullet in "Keys and controls", naming the how-to box's own button and the button it leaves behind; 19,252 to 19,323 bytes).

Version 2.34

A missing answer filled in, in the game file, and it is the kind of defect the game page's own words make easy to see. The "Keys and focus" section says that "an input that cannot act answers in words rather than in silence", and it names exactly one deliberate exception: a steering key after a run has ended, which is left silent so the ending line under the board stays readable. A tap on the board before a run has started was the one other input that did nothing at all and said nothing. On that same idle screen the space bar and the Pause button both write "Nothing to pause yet. Press New game first."; the tap wrote nothing.

The tap reader in the game file had three branches and no fourth: a tap pauses a running game, a tap on a paused board carries on, and a tap on a finished board says the game is finished. The idle board fell through all three and left the status line as it was. It now answers with the same words those other two controls use on the idle screen, so the three ways of asking for a pause answer alike. Nothing else about the tap changed: a touch that travels less than 18 pixels on both axes is still a tap and a longer drag is still a swipe, a tap still pauses or carries on a run, and the tap on a finished board that the shortcuts script turns into a new game is untouched — that reader looks at the status line after this one has written to it, and starts the run exactly as before.

Nothing else changed. The four boards and their paces, the block sets and their growth, the start wait, the steering, the key guards, the pause and its messages, the endings and their panels, the marked end square, the read-out and its cells, the "To beat" cell, the copyable result line and the per-board bests are what version 2.33 deployed, and the game page, the statistics script, the result script, the how-to script, the shortcuts script, the small "To beat" script and the stylesheet are untouched by this version.

One limit is left standing rather than hidden: as with every version of this game, the change was checked by reading the game file, the game page and this page and by the platform's scanner, not by opening the page in a browser. A tap is a touch event, so this rests on the game file's own tap threshold and the order of its branches as read, not on a recording of a finger landing on an idle board. The standing limits section below is unchanged apart from the one clause this version adds.

Files: the game file only (the idle branch of the tap reader, plus its note; 48,124 to 48,914 bytes).

Version 2.33

Bug fix in the game file, one line, and it is about where the keyboard goes after a board is picked. The page's four board buttons are the chips "Cozy 12x12", "Classic 16x16", "Tight 20x20" and "Huge 24x24". Working one of them runs applyPreset(), which sets up a fresh board on that size and, mid-run, starts a new run on it. Every other button on the page hands the keyboard back to the board when it is worked, and says so in this record: New game, through startNew(), Pause, through onPauseClick(), and the four direction buttons, each of which focuses the board after steering. The chips were the one control that did not, so the chip that had been clicked, or pressed with the Enter key, kept the focus.

That mattered because of a guard the game file keeps on purpose: with the focus on a button, the space bar and the Enter key belong to that button, and the game's key handler stands aside for them (interactiveTarget). So the next press of either key worked the chip again rather than the game. A player who picked another board and then pressed the space bar to pause got no pause: the browser pressed the chip a second time, applyPreset() ran again, the run on the board was thrown away and a fresh one was set up on the same board, with the status line reading "New Classic 16x16 board. Score and level reset" where the pause message should have been. The idle screen had the same fault in its own way: the page's key list promises that the Enter key starts a run, and with the focus left on a chip, Enter picked that board a second time and started nothing.

The fix is one call to focusBoard() at the end of applyPreset(), outside the branch that asks whether a run was in progress, so the board takes the keyboard either way: the run that has just started mid-run, and the idle board just set up. Nothing else in the function changed. The abandoned run is still counted nowhere, the two set-up messages are the words they were, and reset(), the board sizes, the paces and the block sets are what version 2.31 left them.

The shortcuts script has a hand-back of its own for the pointer, which is why this defect needed the game file rather than that one: it asks a clicked control to let the focus go one turn of the clock later, and it deliberately skips a press that comes from the keyboard (a click the browser makes for Enter or the space bar carries a detail of 0), so it could not cover a chip pressed with Enter at all. It also releases the focus to the page body rather than to the board, which is no use to a player reaching for the arrow keys next. The 1, 2, 3 and 4 board keys this file offers press the same chips through a click that carries no detail either, so a focus that was already sitting on a chip stayed there after a board key as well. All three ways in now end with the keyboard on the board, which is where the game's own buttons put it. The shortcuts script itself is unchanged: it is the 22,938 bytes version 2.32 deployed.

One limit is left standing rather than hidden: as with every version of this game, the change was checked by reading the game file, the shortcuts script and this page, and by the platform's scanner, not by opening the page in a browser. This is a change to where the keyboard goes, so it rests on how browsers are specified to treat the space bar and the Enter key on a focused button, which was read rather than recorded: that the chip kept the focus, and that the board now takes it, is not something this version watched happen.

Files: the game file only (one call to focusBoard at the end of applyPreset, plus the note above that function; 47,039 to 48,124 bytes).

Version 2.32

Copy fix in the shortcuts script, and it is the kind of defect this page cares about most: a line that says one thing while the code beside it does another. That script answers the 1, 2, 3 and 4 keys, which press the page's four board buttons for a player who expects them from other snake games. While a run is going that is worth protecting, the key is refused and a short line appears under the status line saying so. That line began "The 1-4 board keys pick a board only when no run is under way." That is not the rule the guard keeps.

The guard is the same one the N key uses, and it reads two things and no state of the script's own: the score cell, which the game writes on every step and which carries points only once a run has eaten its first piece of food, and the status line, which holds an ending once a run has finished. A run is protected only while it is under way AND carries points on the board. A run that has started but has not yet eaten anything is therefore not protected: press 3 a second after the run begins and the board does change. The script's own notes at the top of the file say exactly that — "Before a run, after a run, and on a run that has eaten nothing yet, the key presses the matching board button" — and the N key is written to the same rule, so the guard was right and only the sentence was wrong.

What a player saw was this: start a run, press a board key at once, and the board changes, as promised. Eat a piece, press the same key again, and the line says the keys work only when no run is under way — on a run where one of them worked a moment ago, and with nothing on the page to explain the difference. The sentence now names the rule the guard keeps: the keys change the board "only when no run is under way, or on a run that has eaten nothing yet", and the rest of the line is as it was, still naming how many points the run has on the board, that the key was left alone and the run goes on, and that the four board buttons above still work and start a fresh run. One sentence of note was added above the function in the file, recording what the line had said and why it was wrong. The guard itself, the five seconds the line stays up and the single timer behind it, the N key's question, the click and tap readers, the focus hand-back after a pointer click and the listener that keeps the browser's own keypresses out of the game are all untouched.

Nothing else changed: the game file, the game page, the statistics script, the result script, the how-to script, the small "To beat" script and the stylesheet are what version 2.31 deployed. Only the one sentence in the shortcuts script was written, and the file is a little under a kilobyte longer than it was, because of the note above the function rather than the sentence itself.

One limit is left standing rather than hidden: as with every version of this game, the change was checked by reading the shortcuts script, the game file's score and status handling and this page, and by the platform's scanner, not by opening the page in a browser. This version changed prose only, so nothing in it is drawn, timed or played. That the sentence was the last place claiming the old rule rests on reading the guard and the notes beside it against the line itself, not on a recording of the line appearing on a run that had eaten.

Files: the shortcuts script only (the one sentence in the board-key line, plus its note; 22,250 bytes before, 22,938 after).

Version 2.31

Bug fix in the game file, and it is the kind this page cares about most: a sentence that promised one thing while the code did another. The "Blocks on the board" switch can be ticked or unticked while a run is going, and the game's own status line says what that means — ticking it mid-run writes "Blocks will appear on the next board (12 of them). This game keeps its own." The game page says the same in its own words, in "Blocks, walls and pace": the grey blocks are the exception among the three switches, because "ticking or unticking that switch mid-run leaves the current board alone and takes effect on the next one". That is what a reader was told, and it was not what the game did.

The board's block set is built when a fresh board is set up, and each run may grow up to six blocks past it as the level rises, one at each level from level 3 up. The rule that allowed a block to drop in asked only whether the switch was on at that moment, not whether the board being played had been built with blocks at all. So a run that was going when the box was ticked — a board with no blocks on it, chosen for exactly that — dropped its first new block in when it reached level 3, and could go on to six, while the status line under the board had just said the run would keep the board it started with. The read-out's "Blocks on board" cell and the "N blocks grew in this run" note on the ending line then reported those blocks, on a board the player had been told would not have any. Unticking the switch mid-run was already safe: growth was impossible with the switch off, so only the tick, the one the game page offers as the way to play with blocks, carried the defect.

The fix is one flag read in one place. The game file now records, when a board is set up, whether the blocks were switched on at that moment, and a block may only drop in on a board that was set up with them. That record is written in the same function that builds the board's block set, and nowhere else, so the flag and the set can never disagree: turning the switch on mid-run leaves both alone, while picking another board mid-run or starting a new game sets up a fresh board, reads the switch as it then stands, and gets both the blocks and the growth that go with them. A block still may not appear on the food, on the snake, beside the head or in the three squares the snake is driving into, and the six-block ceiling per run is unchanged.

Two status lines were reworded in the same writing, so that what they promise is what now happens. Ticking the switch mid-run reads "Blocks will appear on the next board (12 of them). This run keeps the board it started with, and no new block will drop in it."; unticking it reads "Blocks are off from the next game. This run keeps the board it started with." Both name the board in play rather than "this game", which is the thing that keeps its own set.

Nothing else changed. The four boards and their paces, where the blocks sit, the level-3 rule, the food placement, the start wait, the steering and the key guards, the pause and its messages, the endings and their panels, the read-out and its cells, the "To beat" cell, the copyable result line and the per-board bests are what version 2.30 deployed, and the game page, the statistics script, the result script, the how-to script, the shortcuts script, the small "To beat" script and the stylesheet are untouched by this version.

One limit is left standing rather than hidden: as with every version of this game, the change was checked by reading the game file and by the platform's scanner, not by opening the page in a browser. The standing limits section below is unchanged and still covers this version. That the defect was there rests on reading the growth condition in the game file against the two sentences that promised otherwise, not on a recording of a block appearing on a board that had none.

Files: the game file only (the block-set record and its comment, the guard at the top of the block-growth function, the condition that calls it, and the two mid-run status lines; 45,367 to 47,039 bytes).

These entries were moved here, word for word, by version 2.41, which also left one added closing sentence on the 2.36 entry naming the move.

Back to the main changelog