# Best way to generate pieces in match-3 games, and then tracking them?

I've been working on a match-3 style game in Actionscript using Flixel, and so far, I've been able to build the core mechanics of the game, including board generation, piece generation, piece swapping and movement, and checking algorithms.

However, I am now running into issues with clearing out pieces and letting the above pieces fall down and generating new pieces.

The reason I'm running into these issues is that when all of the pieces are generated, the pertinent values (position, sprite ID, and sprite object) are pushed into an array that helps me track everything, all the time. When pieces are moved, I swap the values of the corresponding arrays and life goes on.

And that array is the core of my problem: if a row in the middle of the board clears out, ideally, all of the pieces above the cleared pieces should fall down to take their place and new pieces are generated at the top and also fall into place. Except if I try to do that now, all the pieces can fall down, but then I'd have to bump all of their values into the right arrays (oh god my head) and then generate new pieces and fit THOSE into the correct place in the array.

Am I overthinking this? Or is there a far better way to track these pieces?

Thanks guys!

• I don't understand what you mean by pushing values into corresponding arrays. – Markus von Broady Nov 5 '12 at 22:58
• Why not use a 2D array? And just map their values. The pieces falling down is just a visual thing. And you lock the player input until the animation is done ( but the values are set before animaton begins ) – Sidar Nov 5 '12 at 23:48
• @MarkusvonBroady: I use an array that corresponds to specific positions on my 5x7 grid, so piecesArray[3] would refer to the third grid spot that I generate. When pieces move around the board, the positional arrays exchange piece data amongst each other to correspond with the new positions. – JonLim Nov 6 '12 at 1:10
• @Sidar: I am currently doing something similar right now - the arrays contain their positional data. Are you saying I should just update the positional data within the array values? – JonLim Nov 6 '12 at 1:11
• @JonLim I think the suggestion is that you should do the opposite: rather than having your primary data structure be the list of pieces, have your primary data structure be the 2d grid itself, the interface that you present to the user. – Steven Stadnicki Nov 6 '12 at 1:22

Lets say this is our 5 by 5 grid and we have a match

So we know 3 tiles will be removed, therefore we need to randomize 3 new values for 3 spots. The catch is however we first need to move the tiles in the same column that were above( blue ) the tiles that were removed (red). It would be easier to traverse from the bottom up ( highest index first to lowest). You can easily count how many tiles you need to move first based on the current index value of y|row to index value 0. You simply copy the value in order. So in the illustration at {3}{2} ( y index first then x) the tile value should receive the blue tile value. At this point we haven't tweened anything yet.
We know the amount of new tiles needed to fill the column so we simply generate new values and set the free spots to these values (you can do this from bottom up or the other way around ). You then simply create your visuals and tween them to the right position.

The position is calculated by the tile width and height.
For example if we take 32x32 and index column(x) = 2 and index roy(y) = 4.
The position = 64, 128.

When creating tile objects, it's easy to just store their position in them. So when you click on them you can just request their grid position. Don't forget to update this on every move.

If you set all these values into variables ( including the size of your 2D array ) you can easily resize your grid, visually and structurally.
Keep in mind that I'm trying to keep the actual data separate from my visuals. Eventhough they are in a way linked by their grid position. We simply have the sprites to click on them and request their position. ( you can do this without sprites though, by calculating the mouse position and converting it into a grid position). But the actual logic is done trough the 2D grid. We then simply call functions to move our visuals and set their new grid position.

I also have to mention, you need to do bound checking as you traverse trough your grid. You don't want out of bound exceptions ( going below 0, or above the capacity )

Hope this helps.

• Perfect, thanks Sidar! This is what I was thinking, thanks for confirming and the additional help! – JonLim Nov 6 '12 at 16:41