Free Flow Puzzle
Recreated Free Flow Puzzle game using Unity3D
Recreated Free Flow Puzzle game using Unity3D
Gameplay Programmer
Unity3D, C#
Puzzle
Built during college as a self-directed learning project — the goal was to take a game I enjoyed playing (Flow Free) and rebuild it from scratch to understand how it works under the hood. No tutorial followed, no assets purchased. Just reverse-engineering the mechanics by playing the original and implementing everything in Unity3D.
The core challenge was the path-drawing system — handling touch input on a grid, tracking which cells belong to which colour path, enforcing puzzle rules (paths can't cross, all cells must be filled), and detecting a valid solve state. A small but mechanically precise problem that required clean data structures and careful input handling on mobile.
The heart of the game — a touch-driven system that lets players draw colour paths across a grid. Tracks path state per colour, handles mid-path backtracking (dragging back over your own path to erase it), prevents paths from crossing, and resolves conflicts when a new path overtakes an existing one.
Built the grid data model that represents puzzle state — each cell knows its colour ownership, whether it's an endpoint, and whether it's occupied. Solve detection checks that all paths are connected endpoint-to-endpoint and that every cell on the grid is filled — the two conditions Flow Free requires for a valid solution.
The interesting thing about re-implementing an existing game is you can't look
up the answer — you have to figure out what the problem even is
before you can solve it. Flow Free looks simple on the surface, but the
path-drawing mechanic has a lot of edge cases: what happens when you drag
back over your own path? What happens when you cross a colour that's already
connected? What's the correct order of operations when a new path "steals"
a cell from an existing one?
Working through those questions by playing the original, forming a hypothesis
about the rules, and then implementing and testing them was a strong early
lesson in thinking about game systems precisely — not just
building something that looks right, but something that behaves correctly
in every edge case.