Analysis on the algorithm of "Serial Capture treasure"

Ignorant like me, but only last year to know that there is a "serial treasure" such a game, and it seems that each lottery hall has dozens of consoles for people "entertainment." Last year and a few friends passed the lottery to see the hall in the play "Serial treasure" people seem to be quite a lot of, dozens of games consoles are basically not enough. Play also baise, whether it is a suit of middle-aged comrades, or dress up ordinary ordinary people, have fun ... To be honest, I can't understand why they're addicted to this, and of course I don't really have a cold on this kind of game.
Maybe it's a reasonable explanation to earn (big) money and pass the time through the game. For example, each game console will be the time of the roll screen to broadcast a place who has a number of rewards and other information, for many players still some or more attractive.
Of course, "Serial treasure" is operated by welfare lottery (? In some ways, it may be reassuring to have fun.

As a technician, I'm actually interested in the gem-linking algorithm in "Serial capture" and the technical points of the gem matrix filling process. Compared to the conventional business logic in game development, it may be more "technical" in implementation.
Anyway The first question, gem wiring algorithm, I did not see the connection rules at the outset, thought is "a stroke" and the like, after the discovery is not, as long as the adjacent gem similar can be wired. Think about the algorithm implementation, it is obvious that breadth-first search is very suitable for this application scenario (again and again the game should be similar to the same algorithm processing).
Then came the second question, how do you populate the gem matrix after each gem that meets the rules of the connection is eliminated? After all, this is a networked game, assuming that critical game logic is calculated on the server side, how should the server inform the client about the gem matrix (possibly larger) and the elimination of information (possibly more)? The approach I came up with is roughly as follows:
0) Gem Matrix (Gemmatrix) Generation This is nothing to say, usually through the various gem probability configuration to generate each element
1) Eliminate the gems marked by BFS (there may be multiple groups)
2) Gemmatrix column line by row from low to high, move the gem to a low row vacancy, and finally calculate the number of rows to be filled (needrows)
3) The additional gem fill matrix (GEMMATRIXEX) is treated like a previous step
4) If the complete number of Gemmatrixex (availrows) is less than needrows, the Needrows-availrows line will be Gemmatrixex expanded and populated with the rules of step 0, then the gem move is processed with the rules of Step 2
5) Place the non-empty elements in the Gemmatrixex into the Gemmatrix in the column row by line from low to high
6) After filling the Gemmatrix for BFS treatment, and then go to step 1, the cycle until Gemmatrix to eliminate
In combination with the above ideas, the server informs the client that the final gem matrix and the elimination of history and other information is not difficult to generate.

The simplified processing code is as follows.

--gem matrix size per GuanzhongLocalMatrixsizearr = {4,5,6}--Gem MatrixLocalGems = {}--Gem Fill matrixLocalGemsstandby = {}Local functiongetvalidstandbyrownum (LV)LocalRET =0    LocalSZ =MATRIXSIZEARR[LV]LocalR = #Gemsstandby forrow =1R Do         forCol =1, SZ Do            ifGemsstandby[row][col] = =0  Then                returnretEnd        Endret= ret +1    End    returnretEndLocal functionextendstandbygems (row, LV)LocalSZ =MATRIXSIZEARR[LV] fori =1, row Do        Table.insert(Gemsstandby, {}) forj =1, SZ Do            Table.insert(gemsstandby[#Gemsstandby], Gengemindex (j))End    EndEndLocal functionshiftstandbygems (LV)LocalR = #GemsstandbyifR <2  Then        return true    End    LocalSZ =MATRIXSIZEARR[LV] forCol =1, SZ Do                 forrow =1R Do            ifGemsstandby[row][col] = =0  Then                 forK = row +1R Do                    ifGemsstandby[k][col] >=1  andGemsstandby[k][col] <=5  ThenGemsstandby[row][col]=Gemsstandby[k][col] Gemsstandby[k][col]=0                         Break                    End                End            End        End    End    return trueEndLocal functionshiftgems (LV)LocalSZ =MATRIXSIZEARR[LV] forCol =1, SZ Do                 forrow =1, SZ Do            ifGems[row][col]. SelectedorGems[row][col]. Gemindex = =0  Then                LocalBflag =false                 forK = row +1, SZ Do                    if( notGems[k][col]. Selected) and(Gems[k][col]. Gemindex >=1) and(Gems[k][col]. Gemindex <=5) ThenGems[row][col]. Gemindex=Gems[k][col]. Gemindex Gems[row][col]. Selected=falseGems[k][col]. Gemindex=0Gems[k][col]. Selected=falseBflag=true                         Break                    ElseGems[k][col]. Selected=falseGems[k][col]. Gemindex=0                    End                End                if  notBflag ThenGems[row][col]. Gemindex=0Gems[row][col]. Selected=false                End            End        End    End    return trueEndLocal functionfillgems (LV)LocalNeedrows =0    LocalSZ =MATRIXSIZEARR[LV] forCol =1, SZ Do        LocalTMP =0                 forrow = sz,1, -1  Do            ifGems[row][col]. Gemindex = =0  Thentmp= tmp +1            Else               Break            End        End        ifTMP > Needrows Thenneedrows=tmpEnd    Endshiftstandbygems (LV)Localnum =getvalidstandbyrownum (LV)ifNum < Needrows ThenExtendstandbygems (needrows-num, LV) Shiftstandbygems (LV)End         forCol =1, SZ Do         forrow =1, SZ Do            ifGems[row][col]. Gemindex = =0  Then                 forRow2 =1, Needrows Do                    ifGemsstandby[row2][col] ~=0  ThenGems[row][col]. Gemindex=Gemsstandby[row2][col] Gemsstandby[row2][col]=0                         Break                    End                End            End        End    End    return trueEnd

Analysis on the algorithm of "Serial Capture treasure"