I believe that it may analyze the board for all possible piece placements for all pieces and then choose the piece that provides the least good solution.
Thanks. It's actually explained in the link on the github page after all. I just missed it the first time. It's what you say basically:
The method by which the AI selects the worst possible piece is extremely simple to describe (test all possible locations of all possible pieces, see which of the pieces' best-case scenarios is the worst, then spawn that worst piece), but quite time-consuming to execute, so please forgive me if your browser chugs a little after locking each piece. If you can figure out a way to accelerate the algorithm without diminishing its hate-filled efficiency, do let me know. The algorithm for "weighing" possibilities is to simply maximise the highest point of the "tower" after the piece is landed.
The author says that the algorithm couldn't be changed without invalidating the replays so I'm guessing that means it's a deterministic algorithm. Judging from the comment about "weighing" possibilities (which I interpret as evaluating boards) I'm further guessing it's an ad-hoc implementation of Best-First Search. In that case, I suspect its performance could be improved quite a bit by replacing it with a Monte Carlo search. But as the author fears, that would definitely invalidate replays (you'd get slightly different results each time).
Another optimisation is some kind of prunning heuristic- some kind of intuition about which pieces P don't need to be considered once a certain piece S has been rejected as the worst possible, because those other pieces P can only yield better boards then S (better for the player). No idea what that heuristic would look like, but the result would stay the same so the replays could still run as before.
An interesting challenge might be to make an "offline" version. How difficult a randomizer can you make without being able to see the player's board?
You'd lay down some rules such as "the pieces must theoretically have an even distribution over some period" and "piece sequences must come probabilistically and not hard coded."
You could then objectively test the randomizer by pitting a standardized bot against it.
The method by which the AI selects the worst possible piece is extremely simple to describe (test all possible locations of all possible pieces, see which of the pieces' best-case scenarios is the worst, then spawn that worst piece), but quite time-consuming to execute, so please forgive me if your browser chugs a little after locking each piece. If you can figure out a way to accelerate the algorithm without diminishing its hate-filled efficiency, do let me know. The algorithm for "weighing" possibilities is to simply maximise the highest point of the "tower" after the piece is landed.
The author says that the algorithm couldn't be changed without invalidating the replays so I'm guessing that means it's a deterministic algorithm. Judging from the comment about "weighing" possibilities (which I interpret as evaluating boards) I'm further guessing it's an ad-hoc implementation of Best-First Search. In that case, I suspect its performance could be improved quite a bit by replacing it with a Monte Carlo search. But as the author fears, that would definitely invalidate replays (you'd get slightly different results each time).
Another optimisation is some kind of prunning heuristic- some kind of intuition about which pieces P don't need to be considered once a certain piece S has been rejected as the worst possible, because those other pieces P can only yield better boards then S (better for the player). No idea what that heuristic would look like, but the result would stay the same so the replays could still run as before.