Sliding Puzzle
This sliding puzzle was inspired by collaboration with a graphic designer, whose brief was to present a landing page for a healthcare organisation in an eye-catching and educational way. We chose to include a sliding puzzle, as a creative and dynamic way of displaying information, so I opted to build this interactive component for the design.
The purpose
The puzzle isn't simply there for decoration - it would also allow the client to display a relevant fact under each tile, inspiring curiosity. At the same time, the format is immediately recognisable and intuitive to many users. The aim is to hold the user's interest while they attempt the puzzle, but also to not lock the user out of any key element of the experience, by making this dependent on them finishing the puzzle (which can be surprisingly difficult!) - completion is very much an optional 'bonus' (with a small reward).
Features
- Flexible design - the puzzle automatically cuts and shuffles any image, without needing to manually create 'tile' assets;
- Board length and width can also be defined as needed;
- Manual 'reshuffle' button (for testing purposes or as client desires);
- Custom randomization factor
Web Stack & Tech
Written in JavaScript, with p5.js for drawing the canvas. When beginning production of the app, I had just learned some of the creative applications of JavaScript's canvas API, but realised that some additional functionality (such as the visual auto-shuffle on page load) could be achieved more easily and efficiently with the p5.js library, which uses many canvas API features under the hood. This involved some refactoring, but the resulting code was easier to maintain and therefore update, ultimately saving some production time.
Challenges
Sliding puzzles are familiar, but conceptualising how the puzzle could be built with programming logic, proved to be a puzzle in itself. My solution involved creating a fixed 'board' of tiles which could register the position of the user's mouse click, as well as a means of breaking up a source image into tiles, tracked with their own index numbers as they move. When the user clicks a tile, the program would need to find the location of the blank tile, before swapping their positions (the canvas actually 'redraws' on each click).
The toughest challenge was discovered during testing- I learned that in some cases, randomised tile placement meant the puzzle was actually unsolvable. The solution involved reverse-engineering from a completed puzzle, with rules imposed so that each step of the 'shuffle' could only happen if the randomly-selected tile was adjacent to a blank tile, and swapping with it directly. This also required a greater amount of randomization, because there are fewer possibilities for movement on each iteration. As a result I built in a randomization index to quickly test the impact of the number of individual shuffle 'attempts' on the overall level of shuffling, and potentially the difficulty of the puzzle.
Lessons
While some change will be inevitable throughout development and testing, mapping out the design logic further to anticipate issues before writing code could have helped to avoid some rewriting and refactoring.
In future I would also consider where well-chosen libraries can make implementation easier, though the process of learning the canvas API, as I wrote the initial program, was also valuable.
Other Projects
Schillinger Rhythm Generator
Direct Debit Date Calculator
