Hoe de bot denkt

1. Waar de bot draait

De botpagina heeft een iframe met game.html als bron. Bij elke iframe-load voegt bot.html CSS toe die de gewone spelchrome verbergt, en voert daarna de botstring met eval() uit binnen dat iframe:

cell.frame.contentWindow.eval('var IDX=0,TARGET=' + activeLevel + ';' + BOT);

Die plek is bewust gekozen. De game gebruikt const- en let-globals zoals T, BTEL, ETEL, LEVEL, HART, KLAVER en pushKey(). Code die in dezelfde scriptomgeving wordt ge-evalueerd kan die namen zien, ook al zijn het geen gewone window-eigenschappen. Zo kan de bot peek() aanroepen, T[BTEL] lezen en via pushKey() toetsen indrukken alsof hij onderdeel van de pagina is.

2. Welke data hij ziet

De bot gebruikt hetzelfde schermgeheugenmodel als het spel. Er is geen nette lijst met objecten; hij leest tekens uit VRAM met peek(offset). Het slangenlijf wordt opgebouwd uit de game-array T, van staartindex ETEL tot kopindex BTEL.

Voor denkbeeldige routes bewaart de bot alleen verschillen in een overlay-map cells. Daarin staan bijvoorbeeld een geduwde steen of een leeg geworden staartvak. Staat een vak niet in de overlay, dan leest hij het echte scherm met peek(). Zo hoeft niet voor elke tak de volledige 4000-byte VRAM-array te worden gekopieerd.

3. Een besliscyclus

Elke zet volgt dezelfde ladder. De eerste strategie die een richting oplevert wint; de bot drukt die toets, wacht volgens de snelheidsschuif, en rekent daarna opnieuw vanuit de nieuwe live toestand.

const decide = (idle, looping) => {
  resetDanger();
  const urgent = idle >= 45 || looping;
  return nearFood(false) ?? routeFood(false) ?? nearFood(true) ?? routeFood(true) ??
    (urgent ? (pressureFood(false, true) ?? pressureFood(true, true)) : null) ??
    (!urgent ? tailFirst() : null) ??
    pressureFood(false, urgent) ?? pressureFood(true, urgent) ??
    survivalMove();
};

4. Pijlengevaar

Een leeg vak kan in het volgende tick fataal zijn. danger(offset) markeert een doel onveilig als er al een pijl staat, als een pijl er straks in stapt, of als een pijl via de rand terugkomt.

Dit model kijkt een tick vooruit, niet naar de hele vijandentoekomst. Dat is genoeg: na elke echte game-update rekent de bot opnieuw met het verse scherm.

5. Zetten simuleren

De kern is move(state, scancode, allowSmile). Die geeft een nieuwe denkbeeldige toestand terug als de zet legaal is, of null als hij botst, omkeert, sterft of een onmogelijke steen wil duwen.

6. Voedsel zoeken

Voedsel zoeken is verdeeld over drie planners. Ze starten allemaal bij de kop, simuleren lijf en geduwde stenen, en bewaren alleen de eerste toets van een winnende route.

In de eindfase zoekt de bot dieper, omdat de laatste harten en klavers vaak precies in lastige hoeken liggen. Smileys blijven tweede keus: ze worden alleen toegestaan als schone routes mislukken.

7. Valcontroles

Een hart bereiken is niet genoeg. Veel slechte slangenbots volgen de kortste route en ontdekken te laat dat het voedsel in een doodlopende zak lag. Daarom test Sneekie's bot kandidaten met meerdere signalen.

8. Noodzetten

Na de normale veilige voedselplanners heeft de bot drie noodgedragingen. Ze voorkomen bevriezen, maar staan in een vaste volgorde zodat staartvolgen geen eindeloze cirkel wordt.

9. Routes scoren

Na de veiligheidsfilters krijgt een voedselkandidaat een score. De normale route-score geeft overleving het meeste gewicht, daarna punten, en pas daarna kortheid:

De grote gewichten voor staartbereik en overlevingsdiepte zijn het anti-valgedrag. Een iets langere route met toegang tot de staart wint van een korte route een krappe hoek in.

10. Snelheidslimieten

De bot moet tussen zichtbare zetten kunnen denken. Daarom zijn er harde caps:

• danger() gebruikt een generatiecache.
• nearFood() is ondiep: 260 toestanden en 9-12 stappen.
• routeFood() stopt bij 950 zoektoestanden.
• pressureFood() gebruikt 720 toestanden normaal en 1050 wanneer urgent.
• survivalDepth() is een beam search en bewaart per diepte de 40 toestanden met de meeste uitgangen.
• De schuifregelaar verandert de wachttijd tussen toetsaanslagen, niet de zoeklogica.

De schuifregelaar klikt vast op deze snelheden: 10, 10, 20, 30, 49, 50, 60, 70, 80, 90, 100. Lage waarden laten de bot langer wachten tussen zetten; hoge waarden drukken veel sneller toetsen in, tot ongeveer 45 ms per zet.

delay = round(45 + 375 * ((100 - speedValue) / 100) ** 1.6)

11. Win, vast, herstart

De botpagina heeft zeven tabs: levels 26-32. Winst flitst groen, falen flitst rood, en beide gaan daarna door naar de volgende tab. Na level 32 gaat hij terug naar level 26.

Score wordt gebruikt voor de idle-timer in plaats van itemaantal, omdat late harten klavers kunnen spawnen. De laatste klaver kan een lange veilige route vragen zonder dat de score meteen verandert.

12. Grenzen en afwegingen

De bot is bewust praktisch, niet perfect. Hij lost niet het hele level als een enorm plan op, want het bord verandert na elke pickup, geduwde steen, gespawnde klaver en vijandentick. In plaats daarvan plant hij voortdurend opnieuw vanuit de live toestand.

• Hij simuleert het lijf en geduwde stenen, maar niet een volledige meer-tick-toekomst van alle vijanden.
• Hij behandelt huidig en volgend pijlengevaar voorzichtig en rekent na de echte game-update opnieuw.
• Zijn state-hash is compact en bedoeld om te snoeien, niet om elk borddetail te bewaren.
• Hij kiest alleen een smiley wanneer schone voedselroutes falen.
• De survival-beam bevoordeelt veel uitgangen en kan smalle maar technisch veilige routes missen.

Kort gezegd: de bot denkt als een voorzichtige slangen-speler. Hij wil dichtbij voedsel, maar alleen als dat voedsel ademruimte overlaat. Wordt het krap, dan zijn staart, open ruimte en toekomstige uitgangen belangrijker dan de dichtstbijzijnde onveilige punten.