This game is frustrating. I worked to a score of around 10500 and thought i was starting to get the hang of it, i then proceeded to not break 3000 for more than a week and then i got my top score out of the blue when i decided I needed to slow way down. 22000 something. I get so frustrated in the early stages that I think I tend to go too fast. =(
Hi folks, there's a robot (a real robot, with mechanical arms) playing Threes on Twitch! http://www.twitch.tv/teamcolorblind
It plays kinda slow, but that gives you time to try and guess what move the bot thinks is best, which is kinda interesting.
Been watching it some - right now it has a 3072 and a 1536 on the board and still going strong! (over 232,000 points)! Update: 248,403 points in something over 1250 moves for about 2 hours. Besides the cards above, there was a 384 and two 192 cards (my best is a 768 - embarrassing!
Dang, didn't realize it stopped broadcasting the game. I think it would have been great if they recorded each and, if a new record score was reached, save it for people to stream. That way we could at least see the best game. Don't know if the one I reported was the best or not.
Threes! AI Looks like I'm a bit late to the party but I built a Threes-playing AI too. Instead of playing "smart" my program uses statistics (Monte-Carlo search method) to gather data about the best next move. The way it works is for each possible move, a bunch of trial games are played with that as the start move. When a trial game comes to an end the final score is calculated. Whichever starting move led to the highest average final score is the next move chosen. In this way the program gathers statistics about which moves lead to better games. Under the hood millions of trial games are being played to guide the choice for the next move. I've played around with strategies for the trial games. My initial strategy was to play completely random trial games (traditional Monte-Carlo method) and it works quite well. My current trial games are being played where there is a 50% chance of making a random move and a 50% chance of choosing whatever next move leads to the best board "rank". I currently rank boards by giving each free spot 6 points, each card next to another card it can merge with 2 points (so two 3s next to each other are worth 4 points and 3 next to each other are worth 6 points, etc.), and subtract 1 point for every colored card. Because the program selects moves based on many trial games, I have a "dial" that lets me adjust how long the program spends doing trial games before it selects a move. When I set it to 1/16ths of a second it makes 16 moves a second. I played 512 games at this rate and got: Code: 192: 510 (99.6%) 384: 488 (95.3%) 768: 415 (81.1%) 1536: 148 (28.9%) 3072: 3 (0.6%) One of the 3072 games I happened to watch was extremely close to getting the 6144 card. It ended with 3072, 1536, 764, 384 all in a cluster. I'm still working on improving the "smarts". I'm confident the code can (rarely) reach 6144 as-is but I'd like to make the program better before I throw CPU at the problem.
Threes AI continued I've done some more testing and I found that Monte-Carlo search with some of the moves being chosen base on ranking the board is worse than pure Monte-Carlo search. Perhaps my board ranking was poor? Instead I've worked on selecting the next move from random trial games better. I was using the average score from trial games. I tried using the median score as the selector but it was much worse. I'm now using the geometric mean of the average and the three dividers between the 4 quartiles (the divider between q2 and q3 is the median). Using the same move rate of 16 moves / sec I'm now getting: Code: 384: 511 (99.8%) 768: 490 (95.7%) 1536: 260 (50.8%) 3072: 13 (2.5%) I've noticed my program typically loses when it's right about to construct a higher number and it gets unlikely and a useless + is added to the board the balance of colored cards gets really poor. In both of these situations it seems like recovery is impossible. I think my code isn't keeping the board healthy enough with free space so that when these situations arise it's able to handle them. I really need to figure out how to implement a board ranking with looks-ahead that doesn't degrade the Monte-Carlo search performance like my previous board ranking was.
Nice, I was trying a Monte-Carlo approach the other day, after reading an article about the advances in Go programs using that technique. I didn't get far however, and results were significantly worse than the expectimax bot.
Ah it looks liked I missed nneonneo's posts. It seems I have some catchup reading to do. My program is pretty good about getting to 1536 but the times it fails to do so or the times it fails to get to 3072 are all because the board isn't "healthy" and the large numbers aren't nice and close together. Too many colored cards or one useless + card is enough to kill a game when the board is already low on space trying to make the next big card. I think your ranking heuristic that gives some score to numbers next to their double could really help the program keep the board more healthy. One of the reasons why I think it's a long-term board health issue is adding lots more CPU time doesn't make much of an improvement. I don't think Monte-Carlo with random play can see far enough in the future to detect long-term unhealthy boards. Instead it favors short-term and medium-term play can't can't tell that 20 moves down the line things are going to be tight.
To add something to the cloning controversy, I spent the whole afternoon writing a post which was intended to be about 2048 but turned out into something completely different: a visual catalog of real clones of Threes. I guess somebody could find it interesting... http://nontrivialgames.blogspot.com/2014/04/a-visual-catalog-of-threes-clones.html
