Not as much as you think. Suppose you have { 98304, 196608, 393216, 786432 } on the board, taking up 4 spaces. 9 spaces on the board are sufficient to combine small cards until you have { 1, 2, 3, 6, 12, 24, 48, 96, 192 }, with the final three spaces open. It takes about 200 moves to build up this sequence, enough time to catch 9 bonus cards. Make the first of these bonus cards a 98304, which you can merge with the four high cards to make a single card: 1572864. Make the next 8 bonus cards each 196608, which is enough to combine to form a 3145728. At this point you have 11 cards on the board: { 3145728, 1, 2, 3, 6, 12, 24, 48, 96, 192 }. Get a 1, and merge it up to a 384. (A few small cards will come in.) Now you have { 3145728, 384 } plus a few small cards. Then catch bonus 384, 768, 1536, etc., until the 384 becomes a 393216. (This takes 10 doublings, or about 200 cards: the small cards now build up to another 384. The board now has { 3145728, 393216, 384 } plus a few small cards. After 7 more bonus cards, all 393216, you now have { 6291456, 1, 2, 3, 6, 12, 24, 48, 96, 192, 384 }, which quickly becomes { 6291456, 768 } plus a few small cards, and the cycle begins again. Once the high card reaches (say) 3 * 2^85, it will require about 75 bonus cards or about 1500 moves for the 768 to "catch up" with the high cards. During this phase there is only one extremely high card on the board, plus the mid-size card, plus room to bring in the bonus mid-size card, leaving 13 open spaces to play with, more than enough to handle 1500 small cards in a row. The small cards will build up to { 1, 2, 3, 6, 12, 24, 48, 96, 192, 384, 768, 1536 }. Some of the bonus cards can periodically be used to "clean up" the mid-size cards (e.g. a well-timed bonus 192 could merge the { 192, 384, 768, 1536 } to a 3072) to prevent them from clogging the board, and this lets the technique continue until the high card gets much higher, perhaps 3 * 2^1000.
I find that once I have { 48, 96, 192 } on the board, it takes a lot of discipline to maintain the overall "board health", rather than rush to merge the high cards to make 384 as soon as possible. The goal should be to get the 384 with a healthy board, not to get the 384 at all costs! Once you have the 384, it may take a bit of a "strategy reset" to start dealing with small cards again. Keep an eye on merging the mid-size cards, so you don't end up with say three 24's on different parts of the board. Also, the bonus cards will start to get surprisingly big surprisingly often, so try to bring them in next to bigger cards when you can! Focus on building the second-largest card (so if the two highest cards are { 384, 48 }, concentrate on building a second 48 next to the first one, so you can merge it to a 96), then focus on matching the third-highest card until that builds up to a 96 next to the first one, and so on. You'll be at 768 before you know it. Good luck!!
Yeah, there seems to be a lot of room for making mistakes up until you get a 192 on the board. Once I have a 384, I start building a highway for 192-96-48. But once those are on the board, I seem to have trouble building 24-12 in close proximity to each other, while balancing the incoming 2-1.
I know right? The number of times I've had all the parts to a 768 and not put the together for lack of the tiny cards working is in the ten-twenty region. I have made a 768 twice, legit.
Nice one. I've filed a bug with Apple. It looks like they are using a biased byte to store the base-10 exponent, which only handles [-91..164], and incorrectly wraps around in this case, rather than underflowing to zero. The correct value is 5.846e-92, so the displayed value is off by 10^256. (The value is wrong internally too; subsequent operations like sqrt() treat it as a huge number instead of a tiny one.) Similarly, if you calculate 0.1 ^ 256, it shows the answer as 1. Not quite a Pentium-level bug, but they probably should still fix it
Took me so long to realise that the row you move is the row the tile gets added to! Glad I know now, my scores are quite shocking compared to my GC friends! I haven't even broken the 3k mark yet, eek >.<
Thanks. That is an....interesting range of exponents to handle. I just talked to my sister last night and she has yet to build anything more than a 96. She didn't know about the preview drag. You're not alone...
I didn't realize that until I started reading tactics online lol. I think you'll learn a lot more on how the game functions by reading online than from the basic in-game tutorial or by just playing without intentionally looking for patterns.
Another pattern I've found very helpful is to try to make "collapsible" runs of cards, particularly on the edges. For instance, the sequence {24, 3, 3, 6, 12} is beautiful because it will "collapse" to a 48, whereas {24, 3, 3, 3, 6, 12} is problematic, because it collapses to {24, 3, 24 }.
30 seconds after the wonderful screenshot below was taken, I was setting up Reflector to capture the big moment on video for posterity -- and then, intending to show Control Center to enable AirPlay, I swiped upward... Oh, the heartbreak!!! Curse you iOS 7!! Asher, if you're reading this, perhaps there could be an Undo option for the final (losing) move only, if another move would not have lost. (Or else the game could outright prevent such a move.) This wouldn't give the player any strategic advantage (as a general-purpose Undo would), because after the final losing move you don't see the 'Next' tile. Silly idea or otherwise, I wish I had this game back!!!
Lesson learned? Always do control center or 4 finger swipes OUTSIDE the game board. Threes is not the only app this applies to.
I started the swipe at the very bottom of the device (on the bezel), but Threes still recognized it as a "move". It looks like iOS pops up the little "tab" on first swipe but passes the swipe through to the app for interpretation; only the second swipe pops up the Control Center. Perhaps Threes should ignore swipes that begin at the edge (particularly the top or bottom) of the screen for this reason? Right now it accepts swipes that start anywhere on the screen. Edit: I've sent a bug report to Asher/Greg suggesting that they put a narrow "dead zone" strip at the bottom and top of the screen, to prevent mis-swipes like this. Right now Control Center /Notification Center are effectively inaccessible from the app, without making an unintended move!
When I'm playing a game and want to do a special OS swipe, I always pause or open a menu (depending on the game) first. Just in case.
Just had a thought for another test for those who have simulators. Wondered how results would be affected if you started out with X number of moves that were random and then had it proceed the rest of the way normally. That would give us some idea of how important early moves are - or if the game is relatively forgiving in the early stages.
This is probably just me but I feel that ever since the app update (where the white card shows a + sign in the preview) the game has gotten more difficult? So far I've been able to get around 7000 points during most plays ever since I got 21444, with some 11000 every now and then. Now I'm lucky if I get 6000, most of the time I'm stuck around 3000. Just curious if anybody has noticed a change since the update.
I noticed the same thing at first, but I think it was just an illusion. I had subconsciously expected the game to get easier due to the '+' hints, so I was probably playing a little more sloppily because of that, and at first my scores dropped. But once I consciously corrected for that, my scores have gone mostly up, and now I've achieved the 1536 tile twice!* *Well, technically just once. See post #770.
Hahaha! Of course right after posting this I had two 8000 and a 12000. And I definitely played slower this time. So yep, it's just me.
The thread has fallen asleep so let me try to awake it a bit. The other day I noticed something which made me question the way we have been rating the performance of bots. I had made my bot play with certain settings, and it scored something around 89,000. Then I increased the search depth, ran the simulation again with the same random seed, and the bot actually scored slightly worse than before--88k-something. Everything well within the uncertainty caused by the game mechanics: even with the same random seed, after a different move the new card will be inserted in a different place and the rest of the game will play out differently. After further inspection, however, I noticed that the second bot, even if the score seemed to suggest that it played equally to the first, actually played for almost 200 more moves! So it could be argued that it played a lot better, but just received lower bonus cards. This is a significant factor. When you have a 1536 on the board, bonus cards can range from 6 to 192, but making a 192 out of normal cards takes about 100 moves, so the difference between the two is a big deal. It seems to me that rating the bot performance based on score or high card reached doesn't give a fair picture, because those two metrics depend significantly on the bonus cards received. It seems more appropriate to simply use the number of moves; this also has the advantage of avoiding the jumps caused by the scoring algorithm. So I made a few more test runs, and recorded the median number of moves for various settings using the "1-X-Y" classification I explained a few posts ago. I'm attaching the resulting graphs, which I think are interesting. It seems quite clear that increasing Y above 2 or 3 gives no improvements, while increasing X works well up to 4; things don't seem to go as well with X=5, but I don't have those numbers in the graph because the bot starts becoming very slow at that point and I don't have results over enough simulation runs. Regardless, it seems clear that the improvements decrease as X grows, so I'd say that reaching a median of 1000 moves is unviable for my bot, even if I had more computing power.
My hunch is that the variance in number of moves is not going to be significantly different from the variance in "score", which to simplify the analysis (and avoid jumps) could also be computed as the plain sum of the cards' face values, rather than the power-of-3 mechanism. Despite the introduction of "jumps", the actual ordering of scores changes minimally between power-of-2 and power-of-3 scoring in practice. The goal either way is typically to play as long as possible, because the scores are monotonically increasing; there are only rare occasions where you'd find different "optimal" moves for different scoring mechanisms. (For instance, if you have two separated 768's on the board, whether to prioritize "board health" and perhaps delay joining them as your current algorithm does, or to sacrifice board health if you see a clear path to make the 1536.) For example, here's a contrived case: Code: NEXT: 1 2 3 6 3 3 1 96 2 1 768 6 6 3 1 768 24 With power-of-3 scoring, you''re probably best off to swipe right and merge the 768's right away, even though it produces a board that could even lose on that same move (if another 1 comes in). Swiping left is better for "board health", but is also risky; there's a distinct possibility you could lose before merging the 768's, which would result in a much lower score. On the other hand, for power-of-2 scoring (or number-of-moves scoring), you're best off to swipe left and try to rescue the board as a whole.
Wouldn't a "better" game be one with a high score but *less* moves? Given the randomness, a handful of runs wouldn't really show which approach is best but over enough samples, it should fall out and show the best approach. It might be interesting to try having a "winning" state of, say, a 1536 tile and see which approach gets there fast enough.
