Approach to puzzle generation

I have a task in hand about making a puzzle generator, that can fill a game board with colored pearls, that then needs to be solved by the player.

The core rules are

• Pearls are placed in a grid, size varying each level.
• The player needs to clear out all the pearls, or the level is lost.
• Only three pearls in a row (adjacent to each other) can be popped.
• Popping 7 or more will pop each pearl of that color, easing up the board quite a lot.
• Pearls are affected by gravity, and will fall down on the cleared pearls place.
• No new pearls are spawned.

I also need two levers to adjust difficulty. One being the number of colors the pearls can have (clear to the player) and another being a "cruelty" factor in how tight the spectrum of right solutions vs dead ends the level contains.

I seem to be at a crossroad between two ways of approaching this, and would like feedback from you gents and gals.

My two options seems to be :

• Start out with a clean board, and programmatically add pearls-combos to the board till its full. Then the player needs to track backwards from there to solve it. (They wont see it actually being generated, this will happend backstage) This should ensure that a board always have at least one solution, which is backtracking how the engine placed the pearls in the first place.
• Making a pure random board, and then set a scripted runner to try and solve it, branching every time there are more than poppable option, and starting over on a new board if all branches leads to a dead end. This should give me a good result about how many dead ends vs solutions the board contains.

Im not sure which is the best approach, or if I got it all wrong and need to go for a third approach to this. Admittedly, this is my first attempt on a puzzle game mechanics.

• The second approach is apparently wrong, first branching out means exponential complexity which an awful thing to deal with. Besides, the first solution guarantees at least one solution which good. Commented Oct 10, 2014 at 11:28
• It is important to note that seven-somes will be needed to fill up the neglected areas on the edges. It is going to be "harder" to fill out the columns near the edges because there is only one possible threesome that touches columns 0 & n-1 Commented Oct 10, 2014 at 12:23
• I added an example on one way to create a dead-end route. You can check for dead-ends by looking for rows that belong to different threesomes (each pear could remember its originating threesome) and cause other threesomes to break if removed from the game. Commented Oct 10, 2014 at 12:27
• Hi, Forgot to mention, you can add a threesome anywhere on the board (not only in the bottom). This is important cause obviously during gameplay you'd want the player to look for threesomes all over the board (in the examples I've always added threesomes in the bottom - mainly to simplify the explanation). Commented Sep 28, 2015 at 6:09

Use the first approach. pick a random place on the board an add a threesome by pushing all the elements in these spots in the three columns, one row up. At a certain rare %, add a seven-some. This will allow you to add random pearls everywhere. You can guarantee multiple solutions by adding threesomes that are not codependent. breaking threesomes "bad" will make them dependent and increase the difficulty. How to break threesomes you ask?

This is how you break threesome and increase difficulty: