All games Durioo+ games team

From an idea to Durioo+

How one small game goes from a first idea to children playing it in the Durioo+ app: five steps and one release gate, with Claude helping on the design and doing the coding, and the team approving every step.

The core flow

Each stone is one step. A step starts only when the one before it is approved, so nothing reaches children without a person saying yes.

  1. 1

    StartAn idea for a small game next to the videos.

    Designer + Claude

    Plan the game with Claude

    Shape the idea together: who it is for, what it teaches, how it plays.

    • Age group, theme and learning goal
    • Screens drawn at 1280 × 720
    • 3 to 5 levels, each adding one new thing
    • Checked against the house rules
    Out: an agreed game design
  2. 2
    Claude

    Get the zip and the prompt

    Ask Claude to pack the design for building.

    • Design zip: screen PNGs + HTML + README
    • Placeholder art and the list of art and sound slots
    • A build prompt for Claude Code
    Out: design/<game>/ and the prompt

    Hand-offEverything a developer needs, in one folder.

  3. 3

    BuildIn the durioo-games repo, on the shared game kit.

    Claude Code

    Claude builds the game

    Plan first, then code, tests and a report, with two team decisions on the way.

    • Plan with numbered decisions, wait for approval
    • Code, unit tests and browser tests
    • Report with screenshots
    • Commit only after a yes
    Out: a checked <game>-1.0.0.zip
  4. 3

    Inside step 3: how Claude Code builds

    The dashed boxes are where the team decides. Claude never skips them.

    1. Read the designPNGs, HTML values, README
    2. PlanConflicts with the rules, then numbered decisions
    3. Team approves"Use your defaults and start building"
    4. BuildRound logic in TypeScript, scenes from the design
    5. TestUnit, web and mobile, pause, CDN, slow phone
    6. ReportChecks table, zip size, screenshots, placeholders
    7. Team says commitThen the zip is ready for the CMS

    A failing test or a change request goes back to Build. The same checks the CMS runs are run here first (pnpm validate, pnpm simulate:cms), so an upload never fails by surprise.

  5. 4
    Team → CMS

    Upload to the CMS

    The Durioo+ CMS checks the zip before it takes it.

    • Under 15 MB, only allowed files and paths
    • A new, higher version every time
    • No links to outside sites
    • Published to the games CDN
    • Status: draft → internal → beta → live, turned on per platform (iOS, Android, Web)
    Out: a version on the CDN, not yet live

    UploadSame checks as pnpm validate ran in step 3.

  6. Release gateStep 5 starts only after this.

  7. Release gate: the team decides

    A game can upload and play before these are done, but it is not set live until they are.

    Ustaz reviewIslamic content, prayer movements and du'a lines are checked.
    Real voiceArabic is recorded by a person and reviewed; EN and MS use one consistent Duri voice. Games can ship with placeholder voice. Real recordings replace the files by name, with no rebuild needed.
    Final artDesigners replace the placeholder art slot by slot, by file name.
    Play testThe team plays it end to end on real phones, like on this preview site.
  8. 5

    LiveSet live per platform in the CMS.

    Durioo+ app

    Live for children

    The app opens the game next to the videos.

    • Mobile app (WebView) and website (iframe)
    • Messages: ready → started → completed or exit, plus pause and resume
    • Level progress saved per child profile (on this device first, across devices later)
    Out: children play 🎉

How games are grouped

Each game has one theme, one or two age groups, and an access level, the same fields as the Durioo+ CMS.

Age

3–66–9

A game can have both.

Access

FreeVIP only

Free games count toward 1 new game per day for free users.

Status

Draft Internal Beta Live

Set per game in the CMS; live is turned on per platform.

Playable in this preview (tap to open) Coming soon

The tech stack, and why

Every game uses the same tools, so a new game is mostly design and content, not new plumbing.

Making the game

Phaser 4game engine

Fast 2D games in the browser, with touch, sound and scaling built in. Why: runs the same in the app's WebView and the website's iframe, and stays smooth on cheap Android phones. Pinned to one exact, settled version.

TypeScriptstrict mode

JavaScript with types. Why: mistakes in the messages to the app, level data or art names show up while coding, not in a child's hands.

Game kitshared code

Our own package every game builds on: app messages, start screen, level stones, stars, the demo hand, Duri, audio and saved progress. Why: every game follows the same rules for free, and a fix lands in all of them.

Art and sound slotsWebP · SVG · MP3

Each picture and sound has a fixed name and size. Why: the game uses a placeholder until the real file arrives, so art, voice and code move in parallel.

Noto Naskh Arabic, Nunitobundled fonts

Small font files packed into each game. Why: Arabic letters are always correct glyphs, never pictures, and nothing loads from the internet.

Building and checking

Claude CodeAI developer

Plans, writes the code and tests, and reports back. Why: many small games, produced fast, with several games built side by side in parallel sessions.

pnpm workspaceone repo

All games and the kit in one place. Why: one command builds, tests or checks any game, and they all share one kit version.

Vitedev server · build

Instant reloads while building, and a small self-contained folder at the end. Why: the zip uses only its own files with relative paths, exactly what the CDN wants.

Vitestunit tests

Tests for round logic and levels, without starting the game. Why: rules like "2 wrong tries gives a hint" are proven in milliseconds.

Playwrightbrowser tests

Plays each game in a real browser, the way the app would. Why: it checks the messages, pause and resume, that no outside network calls happen, the CDN headers, and the frame rate on a slowed-down CPU.

Host-simpretend app

A page that acts like the Durioo+ app around the game. Why: test mobile and web, EN and MS, VIP and free, vocal only, before any app build.

ESLint + Prettiercode style

One style, and common mistakes caught automatically. Why: code from many sessions reads as one codebase.

Shipping it

Durioo+ CMSupload + checks

Takes the zip, runs its checks, and holds the status (draft, internal, beta, live) per platform. Why: a broken or unsafe game is stopped before it reaches the CDN; our pnpm validate runs the same checks first.

Games CDNone folder per version

Serves each version from its own folder with strict security headers. Why: versions never overwrite each other, and loading is fast everywhere.

Durioo+ appsReact Native · Next.js

The mobile app opens the game in a WebView, the website in an iframe. Why: one game build works in both, talking to the app through one small message contract.

Firebase Hostingteam preview only

This preview site. It serves the same production builds that go to the CMS, plus a home button. Opened on their own, they play with default settings (English, VIP). They only accept the app's messages from duriooplus.com, so other sites cannot embed them. Why: the whole team can try every game on their own phone in seconds. Not used for release.

House rules every game keeps

Checked in the plan, in the tests and in the report.