Posted July 01, 2025 by ☆ MelodyHSong ☆
#Devlog
Hello everyone!
I wanted to share a little look back at the first project in my personal #10TinyBuilds challenge: a complete Sudoku game built in Unity! My goal was to build a small but polished game, and the journey was full of interesting decisions, processes, and most importantly, lots of learning. Thank you Brackeys for the tutorials on Unity! ✰
The whole process began with a simple goal: make a Sudoku grid that works!
✰ Decision: I decided to start with the absolute minimum. My first version didn't even have random puzzles; it just had one single puzzle written into the code. This was just to prove the basic idea worked!
✰ Process: This involved creating the visual grid and the logic to check if a number was valid in a row, column, and 3x3 box.
✰ Learning: Getting a simple prototype working quickly is so motivating! It gives you a solid foundation to build on without feeling overwhelmed.
A Sudoku game with only one puzzle isn't very fun, so the next big step was making infinite, solvable puzzles.
✰ Decision: Instead of trying to build a valid puzzle from an empty grid (which is super hard!), I learned that a much better approach is to generate a complete, solved grid first and then poke holes in it. This guarantees every puzzle has a solution!
✰ Process:
1 - I built a "backtracking" algorithm. It starts with an empty grid and recursively tries to place valid numbers. To make it random, I had it shuffle the numbers 1-9 before trying them. ✰
2 - Once a full, correct grid was made, I saved it as the "solution."
3 - Poking holes! The code randomly removes numbers one by one. After taking one out, it runs a quick check to make sure the puzzle still has only one unique solution. If not, it puts the number right back.
✰ Learning: This was the trickiest bit of logic! The key takeaway was that sometimes, working backward from a finished state is way easier than building up from nothing.
With the core puzzle working, I shifted my focus to making it feel like a real game. This was a super iterative process of just playing it and seeing what felt right.
✰ Decision: It needed a scoring system! This gives the player a goal beyond just finishing.
✰ Process: I added logic to give points for correct answers and take them away for mistakes. We even refined it later to give fewer points for correcting a mistake, which added a nice little layer of strategy.
✰ Decision: The feedback for the player needed to be better. Just having a wrong number disappear was confusing.
✰ Process: This led to a bunch of cute improvements:
1 - Incorrect numbers now stay on the grid but turn the cell a light red color. So much more intuitive!
2 - Correct numbers lock in and turn a happy green color, which feels really satisfying. ✰
3 - A "Win Screen" was added for a clear, rewarding "You did it!" moment. We later added a button so you can close it and admire your finished work.
4 - A little confirmation pop-up was added to the "Solve" button, just to prevent any accidental game-overs.
This was the biggest leap in turning the project from a little prototype into a complete package.
✰ Decision: The game needed a proper front-end, which meant I had to learn how to use multiple scenes.
✰ Process: I split the project into a MainMenu scene and a GameScene. This immediately created a new puzzle: how do I make things like audio settings carry over when the scene changes?
✰ Learning: This is where I learned about the Singleton Pattern! ✰ I created a persistent AudioManager that gets created once and then just follows you from the menu to the game, never being destroyed.
✰ Decision: Players should be able to quit and come back to their game.
✰ Process: I created a SaveLoadManager to handle saving the game state to a file.
✰ Learning: This was a huge learning moment! My first try at saving failed because Unity's built-in tools can't save 2D arrays (int[,]). The solution was to write little helper functions to "flatten" the 2D arrays into simple 1D arrays (int[]) for saving, and then build them back up to 2D when loading.
✰ Learning (The Hard Way): I ran into some tricky bugs where things would break when loading the game scene. Audio would stop, or the grid wouldn't generate. This taught me about "race conditions," where scripts can run in an unexpected order. The fix was to make my AudioManager more self-reliant by having it find its own components with code instead of relying on Inspector links that can get lost between scenes.
This project was such an incredible success for the #10TinyBuilds challenge. It started as a simple grid and blossomed into a full-featured game with menus, settings, save states, and a high score tracker. The most valuable lessons weren't just in the code itself, but in the iterative process of playtesting, identifying what feels wrong, and building a solution. Every bug, from the save system to the audio manager, was a puzzle in itself, and solving them was just as rewarding as finishing a Sudoku grid.
Thank you for playing, and I can't wait to start the next tiny build! ✰
- #10TinyBuilds: 1 of 10 -
✰ MelodyHSong ✰