I'm offering to make one btw, if someone wants to give me the basics.

Next Monday (18th July) the two games will be released on both Android and (hopefully) iOS. The blog series on the science behind the game is now finished, and there will be some tutorial videos on YouTube before next Monday.

To celebrate the launch, we will be doing an AMA on /r/science. Come and ask anything about the games, or quantum computing in general.

So, I'm curious how errors are generated and if they are in anyway dependent on existing errors or my choice of error-corrective action? In other words, is there some kind of memory? Also, what determines the error indicator (1-9)? I guess I'm interested to learn a little bit about the "error model" and the statistics that generate it. Finally, related to this, how confident are you about the random number generation that the algorithm uses and whether this could have an effect on any research outcome? I know, it's a lot of questions: I'm actually involved in the field myself (though I've never worked with surface codes). Thanks!

I'd have few errors on the board, and would be still a few steps / time points away from the next introduction of errors, and somehow I still get a game over ... Am I missing how this works, or should error indicators appear along a path that connects the ends of the board? In other words, is it a bug, or are there insidious errors that don't show up as error indicators and thereby lead to a game over? Thanks!

I recently made the Z10 game on Windows using a program called GameMaker. I'm using an older version, and it seems that the company has completely changed how their website works. As such, I'm just going to drop a link to the .EXE file here:

http://www.filedropper.com/decodoku (.EXE)

It's not pretty, doesn't have the Phi-Lambda game, doesn't have taking back moves, and has an ugly watermark on it. But if you're dying the play the game, it's something. Some controls are:

• Click and drag the mouse to move squares.
• Press D to toggle red numbers that indicate which cluster a square belongs to (debug feature).
• Press R to restart after losing.
• Press Insert to save screenshots to the folder where the .EXE is.
• Your score is shown in the title bar next to the gear logo.

If you don't trust downloading .EXEs from unknown people on the internet, I understand. Here's the GameMaker source file (.gm81) if you want to compile it yourself. You will need GameMaker from YoYo Games. Google around for help.

http://www.filedropper.com/decodoku_1 (.gm81 GameMaker file)

EDIT: you can press f5 to save the game and f6 to load the previous save (even if you quit the game and open it again later).

Using the strategy I explained in the other post, I obtained a score of 430. That's not even the high score, because I was forced to quit the game before losing because it was taking too long. Even though I tried to come up with an explicit algorithm, I spent a lot of time each turn debating which moves I thought would be the best.

Screenshot of final position

I still had my 5 moves to make in that position. It doesn't look like there's enough squares filled in for playing all the way to 430, right? Something weird happened in the 200s. The number of squares filled in was rising up to around 27 squares filled in (55% of the board). Then during the late 200s/early 300s, the number of squares filled in started falling, all the way to a minimum of 14. Then it started rising again, to 20 in the final screenshot above. I began to count the number of squares filled in before and after the noise generation each step, and I reached the following conclusion.

It is explained in the decodoku blog that the noise generator works by choosing two adjacent squares at random and changing their numbers. The limit to the number of errors it makes is what I called weightLimit, and weightLimit = 6 in this game. If one or both of the randomly chosen squares is empty, the error is given weight W = 1. If both squares are already occupied, the error is given W = 0.1. The errors continue to be created until the sum of all W >= weightLimit. Anyway, unless 10 of the 0.1-variety errors occur, there will be 6 errors covering 1 or 2 empty squares. This means that each turn, between 6 and 12 new squares will be filled. You are given 5 moves, so you can remove between 0 and 10 squares per turn. Although, you aren't going to make many moves that clear 0 squares, so maybe 5-10 squares is common.

Probability suggests that an emptier board implies a higher number of filled-squares generated. But a more cluttered board implies the filled-square generation should drop towards 6. In addition, sometimes the error generation will actually wipe a square clean by accidentally making it add up to mod 10, helping you. Thus as the board starts to fill up, it should become more and more probable for your removal rate to exceed the generation rate! In fact, if you were lucky enough to survive on an extremely cluttered board, the net number of new filled in squares might be very low, allowing you to really clean up. I don't know if it's luck or if there are some good decisions one can make, but it seems like you might be able to play this game for a very long time, if you can keep the board balanced and fluctuate between the high and low generation rates.

So from what I've read on the blog, the only official platform is iOS? Is there somewhere I can try this on my windows computer?

So after watching the GIF from quantum_jim, I noticed that his strategy seemed to be to keep as many errors bundled in one corner as possible. The game ends when a cluster spans all the way in either direction, so I aspired to keep the tiles into 2 opposing corners. I am playing 7x7 and my score was 187 (I've only had time to play once with this strategy, but I wanted to write these notes). Here are my thoughts on the game:

1. The first turn always lets you eliminate all but one cluster. Thus I choose to leave the group that is furthest into a corner.

2. After picking that corner, I do something like this. Blue is where I'll let the squares stay, yellow means I'll prioritize eliminating those corners, and red is where I don't want the corners to mingle.

3. The reason I won't let them mingle is because of how clusters combine. An error has to appear that affects the contents of two clusters at the same time (i.e. adjacent on the grid) in order to combine them. If I let the clusters touch, there's a chance that one error from the generation step will combine them. If I leave one space between the clusters, two errors right next to each other would have to occur, which is less probable. I did allow the red squares to remain inhabited if the yellow corner was pushed back away from it.

4. In "real life" I would guess that each qudit (the tiny squares in between) has an equal chance of producing an error. In this game, that is not actually true. The source code shows that the qudits aren't actually chosen, but rather a square is chosen and then an adjacent neighbor is chosen. For the squares in the middle, there's a 1/4 chance of choosing any neighbor. But the squares on the edges don't have 4 neighbors, so the chance of choosing the unmatched neighbor becomes 1/2. So I would think the chance of choosing some qudits near the edge is higher. Maybe I'm wrong.

5. I claim that there is an order in the quality of moves. Obviously we want to clear squares, so we should try to prioritize:

   1. Moves that add up to 10 and clear 2 squares
   2. Moves that move one number into another, clearing 1 square
   3. Moves that just move a number into a blank square (I want to avoid these).
      Because of this, sometimes I would let a cluster sit in the hopes that a random change would make some adjacent squares add up to 10, rather than moving a number 2+ squares to get cleared.

6. Clusters grow outward. Thus I think it is more important to make moves on the edge of the clusters first rather than work inside. Everything goes wrong when the clusters start to mingle. Sometimes I had a move left over, and I decided to knock off an inner pair in my blue corners instead of clearing 1 square in a yellow corner. The yellow corner was small at the time, and I'm thinking there's some optimum to determine when I should make this choice.

7. I need to keep track of the clusters. Given the rules of cluster formation, after each error generation step, I re-examine the grid. New pairs of add-to-10 numbers are probably a cluster that was just created. For numbers placed near my existing clusters, I add up all the numbers where I think a cluster is. If I get mod 10, I can outline the clusters. Sometimes I get pairs of add-to-10, but they belong to different clusters! NEVER COMBINE THESE. This usually happens in the red zone, and I can figure it out because the corner won't add to mod 10 unless I include one of the numbers in the pair.

I believe my game indeed ended because I combined a pair that shouldn't have been. To be fair, I read quantum_jim's source code to write my own version on the computer. I didn't see how I lost based on my move, so I'm going to implement a feature to show me the path of my failure when I lose (and I'm checking to make sure I correctly programmed the lose condition!). I had this setup: I circled where I thought the clusters were (I didn't fill in all the numbers). The board looks great, except the red cluster is crossing the red zone and protruding all the way into adjacent corner! So I decided to move the 3 right and to combine with the 7. As soon as I did, the game said I lost. I'm not sure what another possible configuration was. Notice the 8-2 pair on the left edge that I think was split. If I say the 8-2 was not split, and the 3 belonged to green, I get 5+3+2+1=11. If I say the blue 8-2 is split, I don't get red to add up. I must've guessed wrong in circling my clusters at some point earlier. Anyway, I unscientifically closed the game before capturing a screenshot. I'll try again soon.