If you're not familiar Network puzzles, this is a starting puzzle,
As with every type of puzzle, we always start with a solver. We will always start by looking at how we, as human beings will solve a puzzle. We only resort to brute-force approaches when there is no alternative. We think this gives us puzzles that people will enjoy playing.
For Network puzzles, we have developed a notion of required 'connects', and available 'connects'. Take this portion of a Network puzzle:
Let us suppose that we have already decided that cell 5 is in the correct orientation (doesn't matter how) - it doesn't have power (yet) and that's fine. If we now look at cell 4, cell 4 has a demand from cell 5 - cell 4 must 'connect' to cell 5, and that gives us only one orientation for cell 4, i.e. it must be in the horizontal orientation.
We can also look at cell 6 - cell 5 requires a 'connect' from cell 5, and there is only one way that this requirement can be satisfied..
We can look at cell 2 - cell 5 requires a connect from cell 2, but we don't have enough information to decide on an orientation for cell 2. Both cells 1 and 3 can be rotated so that they are available to connect to cell 2. In this situation we can say that cell 5 requires a connect from cell 2, and cells 1 and 3 are available for connect from cell 2. We don't know anything about the cell above cell 2 - this is only a portion of the puzzle.
If you look at the solving techniques on our Network page, you will see that the help on the page talks about looking at straight and T-shaped pieces around the edges first, and then moves from there. We can still think about this in terms of 'connects' - a 'T' shaped piece on the edge of the puzzle has connects available in 3 directions, and also has a direction in which no connect is available, i.e. the outside of the puzzle. This gives one possible orientation for this piece - and this is true if a T piece is on the edge of the puzzle, or in the middle of a puzzle.
By using the idea of required and available 'connects', we have codified most of the solving techniques used for this type of puzzle, i.e. we have generalised on the concept.
This technique allows us to solve most of any single Network puzzle. As is quite common with puzzles of this type, the last few cells can't always be found using this technique. In this situation a human player will either just look at a puzzle and be able to see a solution, or will discover the solution from semi-randomly turning the cells until they can just 'see' the solution.
This is always problematic to implement for an algorithm-based solver, you can't write software that can intuitively just 'see' something like that. In this instance, we resort to some kind of backtracking algorithm for the remaining cells. We will only do this when there is a small number of cells remaining. This makes sure that we don't end up with a puzzle that a computer can solve, but a human player cannot.
When thinking in terms of required and available 'connects', we are guaranteed this will only find a unique solution. When implementing a backtracking algorithm, we will always make sure to implement it to check for all possible permutations - we don't want to present a solution that may not be unique. We are only interested in puzzles with unique solutions, so we need to make sure our solver behaves in this way too.
The generator is much simpler in comparison. We start from a blank grid, and go through these steps,
This is a high-level overview of how we make our Network puzzles. We hope you find this interesting, please contact us if you have any questions about this approach!