System Requirements Document for 2048-playgama

1. Introduction

2048-playgama is a complete Unity game project delivered as a downloadable ZIP archive containing a ready-to-configure game Template plus a full Editor toolchain. The product is a merge puzzle in the lineage of 2048 — playable in 2D or 3D — but built around a new merge idea rather than a copy of the existing number-slide formula, with attractive graphics and a level-based structure.

The intent is a game that is instantly understandable like the familiar 2048-style titles, yet novel enough to attract an audience and be highly addictive, supported by helper/assist tools that are unlocked by watching ads. Advertising is delivered through Playgama and must be configured fully, and must never disrupt or negatively affect the player experience.

The audience is twofold:

• Players — everyday casual players who decide within seconds whether the game is fun, play levels, and unlock helpers through rewarded ads.
• Game Designers / Level Creators — the people who re-skin the template, tune the new merge mechanic, and author levels and stages using the advanced level-creation tooling.

The project must be free of errors and problems, easily customizable, and must include advanced features together with level-creation capability.

2. System Overview

2048-playgama is a Unity project shipped as a ZIP. It contains two cooperating halves:

1. The game Template — the playable merge puzzle: a toy-tray board of chunky tiles that slide, snap, and fuse, a score bar, a level shelf, and a dock of helper capsules unlocked through Playgama rewarded ads.
2. The Editor toolchain — the level editor and customization surfaces that let a designer author levels, tune difficulty progression, and re-skin graphics, settings, and content without touching code.

Actors

• Player (human) — plays the merge puzzle, selects levels, and unlocks helpers by watching rewarded ads.
• Game Designer / Level Creator (human) — customizes the template and authors levels and stages.
• Playgama (external provider) — owns ad delivery and the rewarded-ad lifecycle. Its Developer Console is a provider-managed surface reached through the Playgama MCP integration; the console requires JavaScript and offers developer log in / sign up (email entry, password setting, "Continue with Google") plus access to SDK documentation and developer support links.

Accepted behavior at a glance

• A new merge idea in the 2048 family, playable in 2D or 3D, with attractive graphics.
• Level-based progression with a level shelf for selection.
• Helper/assist tools unlocked by watching ads.
• Playgama ad integration, fully configured, non-disruptive.
• A full level editor and easy customization of graphics, settings, and content.
• Delivery as an error-free, ready-to-configure ZIP.

Narrow exclusions

• Ads must not disrupt or negatively affect the user experience; no full-screen interstitial between moves or before a merge resolves, and no timer, streak, or ad gate that interrupts an in-progress move.
• Ads are delivered via Playgama — no other ad provider is in scope.
• The generic indigo/blue-on-white SaaS template look is forbidden.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. The deliverable is a ZIP archive of the Unity project, containing the game Template and the full Editor, ready for setup and configuration. The ZIP is the product artifact; the game and editor run inside the Unity project it contains.

Access ownership. The game surfaces — Landing, Game, Levels, Helpers — are reachable without an account. The player's progress, score, and unlocked helpers are local game state; no application-owned account, login, or sign-up is required or introduced for play. The designer surfaces — Level Editor and Customization — are likewise part of the shipped project and are used inside the Unity Editor by the person who owns the project; no separate application identity is introduced for them.

Provider ownership. Advertising is owned by Playgama. The rewarded-ad lifecycle — request, load, completion, and reward grant — is executed through the Playgama integration. The Playgama Developer Console is a provider-managed surface: it requires JavaScript to work properly, and it offers developer log in / sign up (email entry, password setting, "Continue with Google") along with access to SDK documentation and developer support links. That console is not a first-party page of this product; it is where the integration is configured and where the developer account lives.

Current vs. future. Everything described in this document is current: the template, the editor, the level-creation capability, the helper unlock flow, and the Playgama ad configuration. No future-horizon features are asserted by the source.

2c. Page Content and Component Coverage

Landing

• Information/state: the game's identity and its one-rule promise — a merge puzzle in the 2048 family with a new idea, playable in 2D or 3D, with attractive graphics. Anonymous; no account state.
• Primary action: start playing (enter the Game).
• Supporting actions: view the level shelf (Levels); view the helper dock (Helpers).
• Domain entities: game identity, merge rule summary, tile ramp, level shelf preview.
• Component responsibilities:
  • Oversized headline block ("Merge the toy box.") in Fredoka Bold, ink on the pastel sky ground, stacked over a solid coral colour block.
  • Primary CTA pinned beneath the headline block, teal-on-ink.
  • Live, tilted low-poly 3D tray of mixed-value tiles on the pastel sky ground, cropped and bleeding off the right and bottom edges, with three loose tiles floating in front of the tray plane.
  • No button sits on top of the tray; no headline overlaps the 3D scene.
• States:
  • Loading: the 3D tray scene initialises; headline and CTA render immediately as text.
  • Empty: not applicable — the landing always presents the tray and CTA.
  • Success: the tray idles with a slow 6-second pointer-following tilt; CTA is reachable and legible.
  • Error/recovery: if the 3D tray cannot initialise, the headline, CTA, and a static tray arrangement remain fully usable.
  • Reduced motion: the tilt and idle motion collapse to a static arrangement with a single 150ms opacity fade; the tray drops below the headline as a full-width square with the CTA above it at 375px.

Game

• Information/state: the live toy tray — a single large rounded-square well with an inset rim holding chunky rounded tiles; the current score as an editorial numeral in Fredoka Bold tabular figures at 48–64px with the best score as a smaller ink label beside it; the current level context.
• Primary action: perform a move — drag/swipe the tray to slide tiles.
• Supporting actions: open the helper dock (Helpers); return to the level shelf (Levels); restart or leave the current level.
• Domain entities: tray, tiles with numeric values, tile ramp (coral → teal → lemon → grape → mint), score, best score, level, move state, merge result.
• Component responsibilities:
  • Tray well with visible rim; tiles cast real contact shadows.
  • Score bar as a compact floating row above the tray.
  • Helper capsules docked in a bottom rail.
  • Merge burst: two tiles clack together, squash to 94%, fuse, and the new tile pops to 118% while emitting a 300ms confetti burst in its own colour.
  • Tile slide/snap at 120ms ease-out with a 6% landing squash.
• States:
  • Loading: the tray and tiles initialise for the selected level.
  • Empty: a freshly started level shows its authored starting tiles.
  • Success: a merge resolves, the score increments, and the merged tile settles at its new value.
  • Error/recovery: an invalid move (no tiles can slide) leaves the tray unchanged and the score untouched; the player can continue attempting moves or leave the level.
  • Reduced motion: slides, squash, pop, and confetti collapse to instant state changes with a single 150ms opacity fade and no pointer-follow tilt.

Levels

• Information/state: the player's stage selection and progression context across the level-based game — a scrollable shelf of miniature live tray renders at alternating vertical offsets.
• Primary action: bring a level fully into view and select it to play.
• Supporting actions: scroll the shelf sideways; return to the Game.
• Domain entities: levels, level order, level badges (low-poly props: chunky globe, lemon, grape bunch, mint cube, coral rocket), progression state.
• Component responsibilities:
  • Horizontal rows of miniature live tray renders, alternating vertical offsets, scrolling sideways so each level can be brought fully into view.
  • Level badges rendered as low-poly 3D props in the same plastic material as the tiles.
• States:
  • Loading: tray thumbnails render as live mini-trays.
  • Empty: if no levels are authored, the shelf shows an empty shelf state with no selectable levels.
  • Success: a level is brought fully into view and selected; play begins on the Game surface.
  • Error/recovery: if a thumbnail cannot render, the level remains selectable by its label and badge.
  • Reduced motion: the shelf wraps into rows instead of scrolling sideways, so each level can be brought fully into view.

Helpers

• Information/state: the set of gameplay helper/assist tools and their lock state; each helper is a capsule chip with a thick 2px outline and a small teal padlock/unlock ring.
• Primary action: unlock a helper by watching a Playgama rewarded ad.
• Supporting actions: return to the Game with the helper available.
• Domain entities: helpers, lock state, unlock ring, rewarded-ad request, reward grant.
• Component responsibilities:
  • Bottom dock of capsule chips, each with a teal padlock ring that draws itself around the chip during the Playgama rewarded-ad load, then flips to an unlocked state with the helper icon filling in.
  • Helper icons rendered as low-poly 3D props in the same plastic material as the tiles.
• States:
  • Loading: the teal ring draws around the chip while the rewarded ad loads.
  • Empty: with no helpers unlocked, all chips show their padlock ring.
  • Success: the ad completes and the helper flips to unlocked with its icon filled in.
  • Error/recovery: if the ad fails to load or is not completed, the helper stays locked, the ring resets, and the player can retry or continue playing without the helper.
  • Reduced motion: the ring draw collapses to an instant state change with a single 150ms opacity fade.

Level Editor

• Information/state: the full tooling for creating and configuring game levels and stages — level identity, starting tile layout, difficulty progression, and level badges.
• Primary action: author or edit a level and save it into the game's level set.
• Supporting actions: preview a level as a live mini-tray render rather than a screenshot; create a new level; adjust difficulty progression.
• Domain entities: levels, stages, starting tile layout, tile values, difficulty progression, level badges.
• Component responsibilities:
  • Level authoring surface for layout and starting tiles.
  • Live mini-tray preview of the authored level.
  • Difficulty progression controls.
  • Save/apply into the game's level set.
• States:
  • Loading: the editor opens the existing level set.
  • Empty: with no levels authored, the editor offers a new-level starting point.
  • Success: the authored level is saved and appears in the level set used by the Levels shelf.
  • Error/recovery: an invalid level configuration is reported and the previous saved state is preserved.
  • Reduced motion: preview motion collapses to a static mini-tray render.

Customization

• Information/state: the template's customizable surface — graphics, settings, and content.
• Primary action: change a customization value and apply it to the template.
• Supporting actions: adjust graphics, adjust settings, adjust content.
• Domain entities: graphics assets, game settings, content entries, tile ramp colours, typography, level badges.
• Component responsibilities:
  • Graphics customization (tile materials, tray surface, badges, imagery).
  • Settings customization (game parameters exposed for configuration).
  • Content customization (text, labels, level content).
• States:
  • Loading: current customization values are read from the project.
  • Empty: unset values fall back to the template defaults.
  • Success: the changed value is applied and reflected in the template.
  • Error/recovery: an invalid value is rejected and the previous value is retained.
  • Reduced motion: not applicable — this surface is static configuration.

3. Functional Requirements

FR-1 — Complete Unity project delivered as a ZIP As a project owner, I should receive the complete Unity project as a downloadable ZIP file, so that I can open and configure it locally.

• Provenance: explicit
• Trigger/input: the project owner requests the deliverable.
• Observable result: a ZIP archive containing the Unity project.
• Access state: no application identity required.
• Failure/recovery: if the archive is incomplete or corrupt, it is re-exported from the project.
• Continuation: the owner extracts the ZIP and opens the project in Unity.
• Owner: system_process (build/packaging).

FR-2 — ZIP contains a complete game Template plus a full Editor, ready for setup As a project owner, I should find a complete game Template and a full Editor inside the ZIP, ready for setup and configuration, so that I can start from a working project rather than an empty one.

• Provenance: explicit
• Trigger/input: the owner opens the extracted project.
• Observable result: the Template (playable game) and the Editor (level editor and customization tooling) are both present and ready to configure.
• Access state: no application identity required.
• Failure/recovery: missing or broken assets are restored from the project's source.
• Continuation: the owner proceeds to customize the template or author levels.
• Owner: system_process (project contents), surfaced through Level Editor and Customization.

FR-3 — Merge puzzle in the 2048 family with a new idea As a Player, I should play a merge puzzle like 2048 but built on a new idea, so that the game feels fresh rather than a copy.

• Provenance: explicit
• Trigger/input: the player starts a level and performs a move on the tray.
• Observable result: tiles slide, snap, and fuse according to the new merge rule; the tray state changes.
• Access state: no application identity required.
• Failure/recovery: an invalid move leaves the tray unchanged.
• Continuation: the player continues making moves on the same level.
• Owner: first_party_page — Game.

FR-4 — Playable in 2D or 3D As a Player, I should be able to play the merge puzzle in 2D or 3D, so that the presentation suits the platform and the designer's chosen look.

• Provenance: explicit
• Trigger/input: the player plays the game in the configured 2D or 3D presentation.
• Observable result: the tray and tiles render in the selected dimensionality and remain fully playable.
• Access state: no application identity required.
• Failure/recovery: if one presentation mode is unavailable, the other remains fully playable.
• Continuation: play continues in the available presentation.
• Owner: first_party_page — Game.

FR-5 — Attractive graphics As a Player, I should see attractive graphics, so that the game is appealing at first glance.

• Provenance: explicit
• Trigger/input: the player views the Landing and Game surfaces.
• Observable result: the toy-tray presentation renders with chunky rounded tiles, contact shadows, and the saturated tile ramp.
• Access state: no application identity required.
• Failure/recovery: if a graphic asset fails to load, a template default is substituted.
• Continuation: the player continues into play.
• Owner: first_party_page — Landing and Game.

FR-6 — The new idea is appealing, novel, easy to understand, and highly addictive As a Player, I should grasp the new merge idea immediately and want to keep playing, so that the game is easy to pick up and hard to put down.

• Provenance: explicit
• Trigger/input: the player reads the one-rule promise on Landing and performs the first merge on Game.
• Observable result: the merge rule is understood from the first interaction; the score increments and the merged tile settles at its new value.
• Access state: no application identity required.
• Failure/recovery: if the player cannot resolve a move, the tray remains unchanged and the player can try another direction.
• Continuation: the player continues to the next merge or the next level.
• Owner: first_party_page — Landing and Game.

FR-7 — Helper/assist tools unlocked by watching ads As a Player, I should unlock helper/assist tools by watching ads, so that I can get assistance in play without paying.

• Provenance: explicit
• Trigger/input: the player selects a locked helper chip in the helper dock.
• Observable result: a Playgama rewarded ad is requested and loaded; on completion the helper flips to unlocked with its icon filled in.
• Access state: no application identity required.
• Failure/recovery: if the ad fails to load or is not completed, the helper stays locked, the teal ring resets, and the player can retry or continue playing without the helper.
• Continuation: the player returns to the Game with the helper available.
• Owner: first_party_page — Helpers (unlock interaction), with the rewarded-ad lifecycle owned by provider Playgama.

FR-8 — Ads integrated without disrupting or negatively affecting the experience As a Player, I should experience ads that never disrupt or harm my play, so that the game stays enjoyable.

• Provenance: explicit
• Trigger/input: any ad presentation occurs during play.
• Observable result: no full-screen interstitial appears between moves or before a merge resolves; no timer, streak, or ad gate interrupts an in-progress move.
• Access state: no application identity required.
• Failure/recovery: if an ad cannot be shown, play continues uninterrupted.
• Continuation: the player continues the current move or level without interruption.
• Owner: first_party_page — Helpers and Game (ad presentation boundaries), with delivery owned by provider Playgama.

FR-9 — Ads delivered via Playgama As a project owner, I should have all ads delivered through Playgama, so that monetisation follows the required provider.

• Provenance: explicit
• Trigger/input: an ad is required (helper unlock).
• Observable result: the ad request and completion are handled by the Playgama integration.
• Access state: no application identity required for the player; the developer account lives in the Playgama Developer Console.
• Failure/recovery: if Playgama is unreachable, the helper stays locked and play continues.
• Continuation: the player retries the unlock or continues playing.
• Owner: provider_surface — Playgama.

FR-10 — Playgama integration fully configured As a project owner, I should have the Playgama integration fully configured, so that rewarded ads work out of the box in the shipped template.

• Provenance: explicit
• Trigger/input: the project is opened and the ad integration is exercised.
• Observable result: the Playgama integration is configured and the rewarded-ad flow for helper unlocks is operational.
• Access state: the Playgama Developer Console requires JavaScript to work properly and offers developer log in / sign up (email entry, password setting, "Continue with Google") plus access to SDK documentation and developer support links.
• Failure/recovery: if configuration is incomplete, the affected helper unlock reports the failure and the helper stays locked.
• Continuation: the owner completes configuration in the Playgama Developer Console.
• Owner: provider_surface — Playgama (Developer Console), with the in-project integration configured in the template.

FR-11 — Project free of errors and problems As a project owner, I should receive a project free of errors and problems, so that it runs without fixes.

• Provenance: explicit
• Trigger/input: the project is opened and played.
• Observable result: the game and editor run without errors.
• Access state: no application identity required.
• Failure/recovery: any surfaced error is corrected in the project before delivery.
• Continuation: the owner proceeds to customize or author levels.
• Owner: system_process (project integrity).

FR-12 — Easily customizable As a Game Designer / Level Creator, I should customize the template easily, so that I can re-skin and retune it quickly.

• Provenance: explicit
• Trigger/input: the designer changes a graphics, settings, or content value on Customization.
• Observable result: the changed value is applied and reflected in the template.
• Access state: no application identity required.
• Failure/recovery: an invalid value is rejected and the previous value is retained.
• Continuation: the designer applies further customizations.
• Owner: first_party_page — Customization.

FR-13 — Advanced features and level-creation capability As a Game Designer / Level Creator, I should have advanced features and a level-creation capability, so that I can author levels and stages for the game.

• Provenance: explicit
• Trigger/input: the designer authors or edits a level on Level Editor.
• Observable result: the authored level is saved into the game's level set and previewed as a live mini-tray render.
• Access state: no application identity required.
• Failure/recovery: an invalid level configuration is reported and the previous saved state is preserved.
• Continuation: the designer authors the next level or adjusts difficulty progression.
• Owner: first_party_page — Level Editor.

FR-14 — Level-based progression with stage selection As a Player, I should select levels from a shelf and progress through them, so that the game has structure beyond a single endless board.

• Provenance: required_inference
• Trigger/input: the player opens Levels and brings a level fully into view.
• Observable result: the selected level loads on the Game surface with its authored starting tiles.
• Access state: no application identity required.
• Failure/recovery: if a thumbnail cannot render, the level remains selectable by its label and badge.
• Continuation: the player plays the level and returns to the shelf for the next one.
• Owner: first_party_page — Levels.

FR-15 — Score and best score visible during play As a Player, I should see my current score and best score while playing, so that I can track progress within a level.

• Provenance: required_inference
• Trigger/input: a merge resolves on the Game surface.
• Observable result: the current score increments in Fredoka Bold tabular figures at 48–64px with the best score as a smaller ink label beside it.
• Access state: no application identity required.
• Failure/recovery: if the score cannot be persisted, the current session score still displays.
• Continuation: the player continues making moves.
• Owner: first_party_page — Game.

FR-16 — Anonymous first impression before play As a Player, I should understand the game and start playing from a first screen, so that I can decide to play within seconds.

• Provenance: required_inference
• Trigger/input: the player arrives at Landing.
• Observable result: the headline, CTA, and live tilted 3D tray render; the player can enter the Game.
• Access state: anonymous; no account required.
• Failure/recovery: if the 3D tray cannot initialise, the headline, CTA, and a static tray arrangement remain fully usable.
• Continuation: the player enters the Game or browses Levels.
• Owner: first_party_page — Landing.

4. User Personas

Player

Product context. The Player is an everyday casual player who arrives at the game from a portal or mobile context and decides within about three seconds whether it is fun. They know the 2048 family well enough that the merge rule should need no explanation, but they are looking for something that feels new rather than a re-skin.

Primary goal. Understand the merge rule instantly, play satisfying merges, and keep going — one more run, one more level.

Distinct accepted responsibilities.

• Perform moves on the toy tray: drag/swipe to slide tiles, watch them clack, squash, fuse, and pop.
• Read the score as the loudest typographic object after the headline, with the best score beside it.
• Select levels from the level shelf and progress through the level-based game.
• Unlock helper/assist tools by watching Playgama rewarded ads.
• Experience ads that never interrupt an in-progress move.

Relevant inputs or decisions.

• Which direction to slide the tray on each move.
• Whether to spend a rewarded ad to unlock a helper now or keep playing without it.
• Which level to bring fully into view and select next.

Interactions with other accepted participants.

• With Playgama: the Player initiates a rewarded-ad unlock; Playgama delivers the ad and its completion; the Player receives the unlocked helper.
• With the Game Designer / Level Creator (indirectly): the Player plays the levels and difficulty progression the designer authored, and sees the graphics the designer customized.

Observable success. The first merge resolves within seconds of arriving; the score increments; the merged tile settles at its new value; a helper flips to unlocked after a completed rewarded ad; the player moves on to the next level.

What makes this role different. The Player is the only actor who consumes the merge mechanic in real time and the only one whose experience is affected by ad placement. Their success is measured in comprehension speed and the pull to keep playing, not in configuration.

Game Designer / Level Creator

Product context. The Game Designer / Level Creator is the person who owns the Unity project after delivery. They re-skin the template, tune the new merge idea, and author the levels and stages that Players will play. They work inside the Unity Editor on the shipped project, not inside the player-facing game.

Primary goal. Turn the template into their own game quickly — new look, new levels, tuned difficulty — without rewriting code.

Distinct accepted responsibilities.

• Author and edit levels and stages: level identity, starting tile layout, tile values, difficulty progression, and level badges.
• Preview a level as a live mini-tray render rather than a screenshot.
• Customize graphics, settings, and content across the template.
• Configure and verify the Playgama ad integration for rewarded helper unlocks.

Relevant inputs or decisions.

• The starting tile layout and difficulty curve for each level.
• Which graphics assets, tile materials, and badges to use.
• Which settings and content entries to expose or change.
• Whether the Playgama integration is correctly configured for rewarded ads.

Interactions with other accepted participants.

• With Playgama: the designer configures the integration and uses the Playgama Developer Console (which requires JavaScript and offers developer log in / sign up with email entry, password setting, or "Continue with Google", plus SDK documentation and developer support links).
• With the Player (indirectly): the designer's authored levels and customized graphics are what the Player plays and sees.

Observable success. An authored level is saved into the game's level set and appears on the Levels shelf; a customization change is applied and reflected in the template; the rewarded-ad unlock works end to end.

What makes this role different. The designer never plays for score — they shape the content and presentation that the Player consumes. Their work is authoring and configuration, and their success is measured in how fast and safely they can change the game.

5. Core User Flows

Flow A — Player: first impression and first merge

1. The Player arrives at Landing anonymously. The headline "Merge the toy box." renders in Fredoka Bold over the pastel sky ground, with the primary CTA pinned beneath it in teal-on-ink, and a live tilted low-poly 3D tray of mixed-value tiles bleeding off the right and bottom edges.
2. The Player reads the one-rule promise and understands the merge idea without explanation.
3. The Player activates the primary CTA and enters Game.
4. On Game, the tray initialises for the starting level with its authored starting tiles; the score bar floats above the tray showing the current score in Fredoka Bold tabular figures and the best score as a smaller ink label beside it.
5. The Player drags the tray. Tiles slide and snap with a 120ms ease-out and land with a 6% squash.
6. Two tiles clack together, squash to 94%, fuse, and the new tile pops to 118% while emitting a 300ms confetti burst in its own colour. The score increments.
7. Failure/recovery: if the Player attempts a move in which no tiles can slide, the tray remains unchanged and the score is untouched; the Player tries another direction.
8. Continuation: the Player keeps making moves, or leaves for the level shelf.

Flow B — Player: selecting a level from the shelf

1. The Player opens Levels. The shelf shows horizontal rows of miniature live tray renders at alternating vertical offsets, each with a low-poly level badge.
2. The Player scrolls the shelf sideways until a level is brought fully into view.
3. The Player selects that level.
4. The selected level loads on Game with its authored starting tiles and difficulty progression.
5. Failure/recovery: if a thumbnail cannot render, the level remains selectable by its label and badge.
6. Continuation: the Player plays the level, then returns to the shelf for the next one.

Flow C — Player: unlocking a helper with a rewarded ad

1. During play, the Player opens the helper dock on Helpers (or the bottom rail on Game). Each helper is a capsule chip with a thick 2px outline and a small teal padlock ring.
2. The Player selects a locked helper chip.
3. The teal ring draws itself around the chip while the Playgama rewarded ad loads.
4. Playgama delivers the rewarded ad and reports its completion.
5. On completion, the helper flips to an unlocked state with its icon filling in.
6. Failure/recovery: if the ad fails to load or is not completed, the helper stays locked, the ring resets, and the Player can retry or continue playing without the helper.
7. Continuation: the Player returns to Game with the helper available. At no point does a full-screen interstitial appear between moves or before a merge resolves, and no timer, streak, or ad gate interrupts an in-progress move.

Flow D — Game Designer / Level Creator: authoring a level

1. The Designer opens Level Editor inside the Unity project. The editor loads the existing level set.
2. The Designer creates a new level or opens an existing one and sets its identity, starting tile layout, tile values, difficulty progression, and level badge.
3. The Designer previews the level as a live mini-tray render rather than a screenshot.
4. The Designer saves the level into the game's level set.
5. Failure/recovery: if the level configuration is invalid, the editor reports it and preserves the previous saved state.
6. Continuation: the authored level appears on the Levels shelf and is playable by the Player.

Flow E — Game Designer / Level Creator: customizing the template

1. The Designer opens Customization. Current values are read from the project.
2. The Designer changes a graphics value (tile materials, tray surface, badges, imagery), a settings value, or a content entry.
3. The Designer applies the change.
4. The change is reflected in the template.
5. Failure/recovery: an invalid value is rejected and the previous value is retained.
6. Continuation: the Designer applies further customizations, or returns to Level Editor.

Flow F — Game Designer / Level Creator: configuring the Playgama integration

1. The Designer opens the Playgama integration configuration in the project.
2. The Designer uses the Playgama Developer Console — a provider-managed surface that requires JavaScript to work properly — to log in or sign up (email entry, password setting, or "Continue with Google").
3. The Designer uses the SDK documentation and developer support links referenced by the console to complete the rewarded-ad configuration.
4. The Designer verifies the rewarded-ad flow end to end by unlocking a helper from Helpers.
5. Failure/recovery: if configuration is incomplete, the affected helper unlock reports the failure and the helper stays locked; the Designer returns to the console to complete it.
6. Continuation: the configured template is delivered in the ZIP, ready for setup.

6. Visuals Colors and Theme

Muse and headline. After Bruno Simon — a playable toy-box world for a merge puzzler. The headline is "Merge the toy box."

Mode. Light mode.

Colour tokens (exact hex, by role).

Tile ramp (fully saturated toy plastic, never a gradient). coral #FF6B4A → teal #2FC4B2 → lemon #FFD05A → grape #7B61C9 → mint #6FE0A8.

Prohibited colour behaviour. No blue-indigo UI anywhere; the sky ground is pale and desaturated; no primary action uses blue. The generic indigo/blue-on-white SaaS template is forbidden.

Typography.

• Headings: Fredoka SemiBold/Bold, rounded terminals, tight tracking (-0.01em), sentence case, chunky and friendly.
• Numerals: tile values and the score render in Fredoka Bold at display scale with tabular figures so they never jitter while counting.
• Body: Nunito Regular/SemiBold, 1.6 line-height, 16–18px reading size.
• Scale: 1.25 modular with a display jump — 20 / 24 / 30 / 38 / 48 / 64 / 96.
• Hero headline: clamp(40px, 9vw, 112px).
• Tile numerals: clamp(28px, 7vw, 64px).
• Body: 16–18px. Labels: 13px uppercase, +0.08em.
• Prohibited fonts: Inter, Roboto, Arial, Helvetica, Poppins, system-ui for any heading or body text.

Shape language. Toys, not cards. Tiles are chunky rounded cubes with 22–28% corner radius and a soft double shadow (a 2px hard lip plus a 12px diffuse drop) so they read as physical blocks sitting in a tray. The tray is a single large rounded-square well with an inset rim. Helper chips are capsules with a thick 2px outline and a small teal padlock/unlock ring. No hairline borders, no flat rectangles, no glass blur.

Layout. One dominant object per screen. The tray occupies the centre 60% of the viewport with the score bar as a compact floating row above it and helper capsules docked in a bottom rail. Landing is an asymmetric two-column split: oversized headline stacked left, the live 3D tray tilted in perspective on the right, bleeding off the right edge. Levels is a scrollable shelf of tray thumbnails, not a uniform card grid. Everything is built on a 4/8pt scale and must hold at 375px (single column, tray full width, helper rail wraps to two rows), 768px (tray centred, headline above) and 1280px (split hero, tray right).

Imagery. Low-poly 3D props rendered in the same plastic material as the tiles: a chunky globe, a lemon, a grape bunch, a mint cube, a coral rocket — used as level badges, helper icons and reward stamps. No stock photography, no flat vector clip art, no gradient blobs. The tray itself is the hero image, and the level editor previews levels as a live mini-tray render rather than a screenshot.

Avoid. Blue or indigo primary buttons on white; glassmorphism, frosted panels and gradient-blob heroes; a uniform grid of identical hover-lift cards for the level list; Inter, Roboto, Arial, Helvetica, Poppins or system-ui for any heading or body text; full-screen interstitial ads between moves or before a merge resolves; photorealistic or stock-photo imagery anywhere in the hero or level badges; any timer, streak or ad gate that interrupts an in-progress move; replacing the readable tray numerals with decorative lettering that drops below 28px on mobile.

7. Signature Design Concept

The board is a physical toy tray.

The public entry — Landing — is a split stage, not a centred SaaS hero. The left 45% carries the oversized Fredoka headline "Merge the toy box." at clamp(40px, 9vw, 112px) in ink, stacked over a solid coral #FF6B4A colour block that holds the primary CTA pinned beneath it in teal-on-ink. The right 55% is a live, tilted low-poly 3D tray of mixed-value tiles on the pastel sky ground #EAF4FF, cropped and bleeding off the right and bottom edges, with three loose tiles floating in front of the tray plane.

The tray is a single large rounded-square well with a visible inset rim. Tiles are chunky rounded cubes with 22–28% corner radius and a soft double shadow — a 2px hard lip plus a 12px diffuse drop — so they read as physical blocks sitting in a tray, casting real contact shadows. The tile ramp climbs coral → teal → lemon → grape → mint, each step a fully saturated toy plastic, never a gradient.

Composition rules. No button sits on top of the tray. No headline overlaps the 3D scene. At 375px the tray drops below the headline as a full-width square with the CTA above it.

Signature moves carried into the product.

• Merge burst: two tiles clack together, squash to 94%, fuse, and the new tile pops to 118% while emitting a 300ms confetti burst in its own colour — the only place saturated colour moves on screen.
• Helper rail as a bottom dock of capsule chips, each with a teal padlock ring that draws itself around the chip during the Playgama rewarded-ad load, then flips to an unlocked state with the helper icon filling in.
• Level shelf instead of a card grid: levels are horizontal rows of miniature live tray renders at alternating vertical offsets, scrolling sideways so each level can be brought fully into view and wrapping into rows under reduced motion.
• Score bar as an editorial numeral: the current score renders in Fredoka Bold tabular figures at 48–64px with the best score as a smaller ink label beside it, so the number is the loudest typographic object after the hero headline.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: expressive Hero Dimensionality: webgl

Landing Hero Motion Brief

• Focal subject: the live, tilted low-poly 3D toy tray of mixed-value tiles on the pastel sky ground, with three loose tiles floating in front of the tray plane.
• Input → transformation → outcome thesis: the pointer's position over the stage drives a slow 6-second tray tilt; the moment a drag begins, the tilt stops and the tray becomes the play surface. The transformation is the tray shifting from an idle, touchable object into an active board — the outcome is that the visitor reads the game as a physical toy they can pick up, and the CTA beneath the headline takes them into play.
• Motion vocabulary: toy physics with real weight — tiles slide and snap with a 120ms ease-out, land with a 6% squash, merged tiles pop to 118% then settle, and every merge emits a short confetti burst in the merged tile's colour. The idle state has a slow 6-second tray tilt following the pointer. Helper unlock plays a teal ring that draws around the chip before it lights up.
• Composed first frame: headline stacked left over the solid coral block with the CTA pinned beneath it in teal-on-ink; the tilted tray on the right, cropped and bleeding off the right and bottom edges; three loose tiles floating in front of the tray plane; no button on the tray, no headline overlapping the scene.
• Reduced-motion state: all of the above collapses to instant state changes with a single 150ms opacity fade and no pointer-follow tilt; the tray drops below the headline as a full-width square with the CTA above it at 375px.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

One crafted real-time object: the toy tray itself — a single large rounded-square well with a visible inset rim, holding a mixed-value set of chunky rounded tiles in the coral → teal → lemon → grape → mint ramp, each tile casting a real contact shadow onto the white tray surface. The scene shows the product's defining state: a board mid-merge, with one freshly fused tile at its 118% pop and a 300ms confetti burst in its own colour. Three loose tiles float in front of the tray plane. The tray tilts slowly with the pointer and stops the moment a drag begins.

9. Non-Functional Requirements

NFR-1 — Ad non-disruption (explicit). Ads must not disrupt or negatively affect the user experience. No full-screen interstitial between moves or before a merge resolves; no timer, streak, or ad gate that interrupts an in-progress move. Rationale: explicit hard constraint in the authoritative source.

NFR-2 — Playgama-only ad delivery (explicit). All ads are delivered via Playgama. Rationale: explicit hard constraint in the authoritative source.

NFR-3 — Fully configured Playgama integration (explicit). The Playgama integration must be fully configured so rewarded helper unlocks work in the shipped template. Rationale: explicit hard constraint in the authoritative source.

NFR-4 — Error-free project (explicit). The project must be free of errors and problems. Rationale: explicit hard constraint in the authoritative source.

NFR-5 — ZIP deliverable (explicit). The deliverable is a ZIP file of the Unity project. Rationale: explicit hard constraint in the authoritative source.

NFR-6 — Readable text and controls stay whole (direction). Headlines, wordmarks, labels, numbers, cards' text and controls stay entirely inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them. Imagery, decoration and motion may be cropped, bled off an edge, rotated, overlapped or cut exactly as the direction asks, as long as it covers no readable text or control. Moving and scrollable content may cross the viewport or container edge by design; every item must become fully readable as it passes. With prefers-reduced-motion, provide a usable static arrangement: wrap items into rows or allow horizontal scrolling so each item can be brought fully into view. Rationale: creative direction.

NFR-7 — Responsive breakpoints (direction). The layout must hold at 375px (single column, tray full width, helper rail wraps to two rows), 768px (tray centred, headline above) and 1280px (split hero, tray right). Rationale: creative direction.

NFR-8 — Reduced-motion support (direction). Under prefers-reduced-motion, all motion collapses to instant state changes with a single 150ms opacity fade and no pointer-follow tilt; the level shelf wraps into rows instead of scrolling sideways. Rationale: creative direction.

NFR-9 — Tile numeral legibility (direction). Tile numerals must never drop below 28px on mobile. Rationale: creative direction.

10. Tech Stack

• Unity — the project engine; the deliverable is a Unity project containing the game Template and the full Editor. (explicit)
• Playgama — the advertising provider for rewarded helper unlocks, configured through the Playgama integration and the Playgama Developer Console (https://developer.playgama.com/mcp). (explicit)
• WebGL / real-time 3D rendering — required by the creative direction's webgl hero dimensionality for the Landing tray scene. (direction)
• ZIP packaging — the delivery format for the complete project. (explicit)

11. Assumptions and Constraints

Assumptions

• A-1 (required_inference) — The Player's progress, score, and unlocked helpers are local game state; no application-owned account, login, or sign-up is introduced for play. The Planning Scope assigns access_requirement: none to Landing, Game, Levels, Helpers, Level Editor, and Customization.
• A-2 (required_inference) — The Level Editor and Customization surfaces are used inside the Unity Editor by the person who owns the project; they are not player-facing runtime screens.
• A-3 (required_inference) — The Playgama Developer Console is a provider-managed surface, not a first-party page of this product. Its JavaScript requirement, developer log in / sign up (email entry, password setting, "Continue with Google"), and SDK documentation / developer support links are provider facts.
• A-4 (required_inference) — The level-based structure is the game's progression context; the Levels shelf is the player's stage selection surface.

Constraints

• C-1 (explicit) — Ads must not disrupt or negatively affect the user experience.
• C-2 (explicit) — Ads must be delivered via Playgama.
• C-3 (explicit) — The Playgama integration must be fully configured.
• C-4 (explicit) — The project must be free of errors and problems.
• C-5 (explicit) — The deliverable is a ZIP file of the Unity project.
• C-6 (direction) — The generic indigo/blue-on-white SaaS template is forbidden; no blue-indigo UI, no glassmorphism, no gradient-blob heroes, no stock photography.
• C-7 (direction) — No full-screen interstitial ads between moves or before a merge resolves; no timer, streak, or ad gate that interrupts an in-progress move.

12. Glossary

• Template — the ready-to-configure Unity game project containing the playable merge puzzle, its graphics, settings, and content.
• Editor — the full Unity toolchain shipped in the ZIP, comprising the Level Editor and Customization surfaces.
• Tray — the single large rounded-square well with an inset rim that holds the tiles; the game board.
• Tile — a chunky rounded cube with a numeric value, rendered in the coral → teal → lemon → grape → mint ramp.
• Merge — the fusion of two tiles into a new tile of higher value, accompanied by the squash-fuse-pop burst.
• Helper — a gameplay assist tool unlocked by watching a Playgama rewarded ad.
• Rewarded ad — a Playgama-delivered ad whose completion grants a helper unlock.
• Level shelf — the Levels surface: horizontal rows of miniature live tray renders at alternating vertical offsets.
• Level badge — a low-poly 3D prop (chunky globe, lemon, grape bunch, mint cube, coral rocket) used as a level marker.
• Playgama Developer Console — the provider-managed surface where the ad integration and developer account are configured; it requires JavaScript and offers developer log in / sign up and SDK documentation / developer support links.
• ZIP — the delivery format containing the complete Unity project.