Login
You're viewing the assemblag.es public feed.
  • Sep 9, 2026, 12:39 PM

    New quasi-blog post: "Analysing 2048 on a 3×3 board"

    chiark.greenend.org.uk/~sgtath

    A rather late writeup of a project I did some years ago, to scale down the puzzle game 2048 to a smaller board, allowing it to be analysed exhaustively, and learn from the results.

    Includes a Javascript implementation inline in the article, and a second much more evil version that chooses the tile drops maliciously.

    💬 2🔄 6⭐ 15

Replies

  • Sep 9, 2026, 12:47 PM

    @simontatham Are you being paid by some state actor to tank everyone's (read: mine) productivity by revisiting old games-that-are-timesinks?

    Sure feels that way :-P

    💬 0🔄 0⭐ 1
  • Sep 9, 2026, 12:49 PM

    @klausman it's a pure coincidence that this blog post happened shortly after the "Mines on weird tilings" project, I promise!

    This blog post was because I found my old analysis code lying around and remembered I'd never got round to doing anything with it. And the Mines project was mostly somebody else's patch, with only small tweaks and code review from me, so it happened when the contributor felt like doing it, not when I did.

    💬 0🔄 1⭐ 1
  • Sep 9, 2026, 2:01 PM

    @simontatham I am very amused that the first thing I did on seeing this post was decide to go find a 3x3 implementation to try, before reading it... only to discover at the very top a playable 3x3 implementation :) Nice.

    The Satan version doesn't seem to want to play for me. New game generates 2 random tiles, but then they won't move (Firefox on Windows 11).

    I am clearly less good at 2048 than I thought, as I'm not getting to 256 anywhere near 90% of the time!

    💬 0🔄 0⭐ 1
  • Sep 9, 2026, 2:04 PM

    @lnr hmm, thanks for the report. I think I know what _kind_ of thing must be happening. The Satan version depends on an extra 1.2MB data file, and I load it lazily on demand when (if) the user first attempts to make a move in that applet. So presumably that extra HTTP request is failing for some reason.

    But I don't know _why_ it might be failing. I'm also using Firefox, and it loads fine there, and it's not obvious why Linux vs Windows should make a difference to something like this.

    If you open the Firefox network diagnostics, reload the page, and try moving in the Satan applet, do you see a record for an attempted load of satan.dat? And if so, what does it say went wrong?

    Come to think of it, is there any complaint in the Javascript console?

    💬 0🔄 0⭐ 0
  • Sep 9, 2026, 2:13 PM

    @simontatham I note that it may be a more general connectivity issue - initially the webpage didn't load at all, and was very slow on the second attempt.

    Looking at the javascript console there are many errors, and it's not immediately obvious which are from this tab! (Mostly objections to the Crash Reports\submitted directory not existing.)

    💬 0🔄 0⭐ 0
  • Sep 9, 2026, 2:20 PM

    @lnr ah, is that the Ctrl+Shift+J console in a separate window? The "Console" tab under the F12 developer-tools interface provides just the JS console for the tab in question.

    I've added a few more diagnostics to the XMLHttpRequest code, so that if the load of satan.dat genuinely fails, you should get a JS alert rather than silently doing nothing.

    But if it's just being slow to load then I suppose there's not much I can do. Though that does at least justify the effort I put into not even trying to load the file until it was needed! I _almost_ didn't bother, on the theory that 1.2MB for a web page wouldn't seem excessive to a lot of modern websites. (Some of my own blog posts include images totalling far more than that, after all.) But it's so much larger than the rest of this post's files put together that I couldn't quite bring myself to load it unconditionally.

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0