CASE STUDY · SOLO UNITY PROJECT

PawDoku / shipped

A mobile logic puzzle that forced me to stop thinking only about mechanics and start thinking about the whole product.

Role: Solo developer
Engine: Unity
Language: C#
Platform: Android
Status: Published

What the project became

PawDoku is a pet-themed logic puzzle where each row, column and region follows placement rules. The first version was about getting the puzzle to work. The finished project had to handle much more: mistakes, lives, coins, progression, boosters, daily content, persistence, player feedback, monetisation, store services and release behaviour.

That shift is the main reason I use PawDoku as my primary portfolio project. It shows the difference between building a mechanic and owning a game long enough to actually ship it.

The gameplay layer

Four systems the puzzle itself is built from.

Puzzle validation

Placement rules, invalid-move detection, and clear feedback when a move is wrong.

Lives & economy

Wrong moves cost lives and coins, tying moment-to-moment decisions to the wider game loop.

Boosters

Hint, undo, retry and streak-related tools built into gameplay rather than bolted on afterward.

Daily challenge

A separate, repeatable challenge flow with its own lives, streaks, and reward logic.

The parts players only notice when they break

Two of these turned into real engineering problems, not just feature checkboxes.

Cloud saves without silently overwriting progress

Problem: A returning player's progress has to survive across devices and sessions, tied to Google Play sign-in.
Constraint: Local and cloud data can disagree — overwriting either one without asking loses real progress.
Solution: I added a conflict prompt so a returning player decides whether to keep the cloud save or the local one, instead of the game choosing silently.
Result: Save state that survives reinstalls and device switches without quietly erasing anyone's progress.

Ads that don't wreck the first session

Problem: Banner, interstitial and rewarded ads all need to coexist without punishing a brand-new player.
Constraint: A remove-ads purchase still has to leave rewarded ads available, since players often want those on purpose.
Solution: Each ad format is gated separately and onboarding-aware, with purchase logic that only turns off the formats a player actually paid to remove.
Result: Monetisation that doesn't get in the way of learning the game, and doesn't strip away rewards players still want after paying to remove ads.

IAP & consent

Coin packs, booster packs, purchase handling, first-purchase feedback and consent flow, treated as product systems with real failure states rather than plain button callbacks.

Analytics & notifications

Level starts, completions, failures, claims, purchases and ad outcomes are all instrumented so behaviour can be understood after release. Notifications support daily and inactivity-return loops.

Getting it out of the editor

Shipping exposed a different category of problems: safe areas, device layouts, SDK behaviour, mobile lifecycle cases, store requirements, consent, build configuration, debugging release-only issues, and making sure the tutorial can't leave a player stuck in an impossible state.

I handled the Android release process and the Google Play integrations myself. That work is less visible in a trailer, but it's the part of PawDoku that most changed how I approach later projects.

What I learned

PawDoku made me a lot less impressed by a mechanic that works once. I now look for restart behaviour, persistence, failure recovery, onboarding, device constraints, and what happens after the hundredth play session — because those are the things that decide whether a system is actually finished.