02 · PLAY CONSUMER MOBILE GAME HUB
NaqiVerse, A Cozy Multi Game Mobile Universe
Five complete casual games brought together through one playful, coherent mobile product.
- Role
- Design, engineering and systems, end to end
- Platform
- iOS + Android · Expo / React Native
The problem
Five different game loops usually mean five different apps, or one app that feels like a folder of prototypes.
My contribution
One codebase where each game is a pure logic module inside shared product systems: persistence, progression, economy, social play and theming.
Core stack
- Expo
- React Native
- TypeScript
- Matter.js
- Zustand
- Reanimated
- Firebase
Proof it works
The shipped build runs five complete games, seasonal leaderboards, friends, achievements, a Naqoins economy and a theme shop, playable fully offline.
What it is
Context
NaqiVerse is a cozy little universe of five casual games, Fruit Merge (a Suika style physics game), Blocqi, Sudoku, 2048 and Snake, wrapped in soft colour, springy taps and gentle celebrations.
It plays completely offline out of the box. Signing in with Google or Apple is optional and unlocks the online layer: a cloud profile, global and per game leaderboards, friends with shareable codes, and seasonal resets.
What made it hard
The challenge
The real difficulty is not any single game, it is making five unrelated game loops feel like one product. A physics sandbox, a grid puzzle, a logic game, a swipe game and an arcade game each want different input, timing and celebration models.
On top of that sit product systems that must work across all five at once: scoring that feeds one progression track, achievements that evaluate any game's events, persistence that survives app kills mid puzzle, and a social layer that stays entirely optional.
The experience
A walk through the product
01
Home is a hub, not a menu, level, streak and a rotating daily pick give a reason to open the app before choosing a game.
02
Every game reports into one profile: XP, levels, ranks and the Naqoins balance are shared systems, not per game bolt ons.
03
Leaderboards are seasonal and filterable per game, the season banner shows the reset countdown so competition stays fresh.
04
Friend codes make adding people one short string, no contact access, no phone numbers.
05
Safety is built into the social layer: any player can be reported or blocked straight from their leaderboard row.
06
Naqoins earned by playing are spent in the theme shop, the economy loops back into how the whole app looks.
What I built
The work, lane by lane
Interface
- A shared design system, palette, type scale, spacing, gradients and shadow tokens, driving every screen
- Home hub with daily pick, stats, badges, friends, leaderboard, theme shop and settings screens
- Springy Reanimated micro interactions and celebration moments tuned per game
Game engineering
- Five games, each as a pure logic module (no React) with a thin presentation layer
- A Matter.js physics core for Fruit Merge with sprite mapped fruit tiers and per tier merge sounds
- A shared GameScreen shell handling headers, pause, game over, streaks and achievement evaluation
Data & persistence
- Local first persistence for scores, streaks, settings and mid game state, Sudoku resumes exactly where you left off
- Optional Firebase Auth + Firestore cloud profile behind Google and Apple sign in
Social & economy
- Seasonal overall and per game leaderboards with rank tiers
- Friends via shareable codes, friend requests, blocking and reporting
- Naqoins + XP economy, level rewards, daily missions and an unlockable theme shop
Quality & comfort
- Reduced motion, haptics and sound toggles; labelled controls throughout
- Store policy groundwork: privacy policy, data deletion page and data-safety documentation in the repo
Engineering decisions
Decisions and their trade-offs
Real decisions cost something. Each of these names its price.
01Pure logic modules, thin views
Every game's rules live in a logic.ts with no React imports; the screen component only renders state and forwards input.
Trade-offMore upfront structure per game, but game rules became unit testable, and adding the fifth game cost far less than the first.
02One shared GameScreen shell
Headers, pause sheets, game over celebrations, streak updates and achievement checks are one wrapper; a game only supplies { paused, onGameOver }.
Trade-offThe shell must stay generic, so a game wanting truly custom chrome has to opt out, a cost accepted for coherence across five games.
03Offline first, social optional
Everything plays without an account; sign in only unlocks cloud profile, leaderboards and friends. Local state is the source of truth.
Trade-offTwo persistence paths to keep in sync, but no player is ever forced through an account wall to play.
04An economy that feeds the interface
Naqoins earned anywhere are spent on themes that restyle the entire app, so progression has a visible, personal payoff.
Trade-offEvery screen must render correctly under every purchasable palette, the design tokens carry that guarantee.
Under the hood
How the system holds together
The architecture is a hub of product systems around five isolated game cores. Zustand stores own settings, stats, achievements and onboarding; the Firebase layer is a strictly optional ring around local state.
Deeper technical notes
- Fruit Merge runs a dedicated Matter.js engine module (suika/engine.ts) with an image sprite renderer mapped over eleven fruit tiers; drop and merge events feed the shared audio map.
- Achievement evaluation subscribes to game over events from the shared shell, so new achievements never require touching game code.
- Progression is split into xpUtils, levelTiers and levelRewards modules; seasonal leaderboard resets are handled server side in the Firebase layer with a visible countdown in the client.
- Blocking and reporting are first class Firebase services (blockService, reportService), and blocked players disappear from both leaderboards and friends.
Gallery
Every screen, up close
Real screenshots from the shipped build, open any of them for a closer look.
Quality, privacy, accessibility
Evidence of care
- Reduced motion, haptics and sound preferences are user facing settings, not developer flags.
- Interactive controls carry labels; game boards support multiple input styles (Snake takes swipes or an on screen D-pad).
- Social safety: reporting and blocking ship in the same release as leaderboards and friends.
- Privacy groundwork in the repository: privacy policy, data deletion page, Play data-safety notes and third party notices.
- Screenshots on this page: other players' handles and the friend code are replaced with synthetic values.
Where it stands
Outcome and current proof
- The supplied build runs all five games end to end with persistence, progression, economy, achievements and theming.
- The online layer, cloud profile, seasonal leaderboards, friends, blocking, reporting, is implemented against Firebase Auth + Firestore with security rules in the repo.
- No store availability, download or player numbers are claimed; none have been supplied for verification.
Technologies
Chosen for reasons
- Expo + React Native + TypeScript
- one typed codebase for iOS and Android, with Expo Router for file based navigation
- Matter.js
- real 2D physics for the Suika style merge game
- Zustand
- small, predictable stores for settings, stats, achievements and onboarding
- Reanimated
- springy 60fps micro interactions that run on the UI thread
- Firebase Auth + Firestore
- an optional online ring, profile, leaderboards, friends, kept outside the offline core
- AsyncStorage
- local first persistence including mid game autosave
For your project
What this experience enables
- Consumer apps that juggle many features without collapsing into a folder of screens
- Game or gamified systems: scoring, streaks, achievements, seasons and soft currency economies
- Offline first products with a cleanly optional account and cloud layer
- Social features shipped responsibly, friends, leaderboards, blocking and reporting together