How to use Gemini to design a falling-block puzzle
Gemini turned a falling-block puzzle idea into a refined state and rendering plan, then generated browser code after its author clarified gravity and scoring.
Original prompt
Shared by the source author. See source notes for context.
ぷよぷよのゲームを作るための要件定義して
Reach people exploring AI agents
See placements →What happened
The author reports a completed puzzle and publishes its design and representative code; omitted sections prevent a full independent run from the article.
Reported by sujitarou (すじたろう) on noteHow the agent did it
- Gemini drafted rules and component responsibilities for the puzzle.
- The author clarified state transitions, coordinates, gravity and animation ownership.
- Gemini generated browser-game code from the refined implementation plan.
Where a person stepped in
The author reviewed requirements and refined state transitions, coordinate origins, gravity processing and separation of game logic from rendering before implementation.
The author sujitarou documented developing a Puyo Puyo-style falling-block puzzle with Gemini CLI. The account follows the transition from a vague idea through requirements, design revisions and generated browser-game code.
Gemini first produced requirements for paired falling blocks, connected-color clearing, chain reactions and keyboard or touch input. It then proposed Game, Field and Renderer components. The author did not accept that abstract structure as a complete specification; he supplied detailed questions about state transitions, landing previews and the coordinate-system origin.
Further review separated animation timing from rendering and clarified the connected-cell search, gravity order, score triggers and game-over timing. These decisions became a final implementation plan. Gemini then generated code organized around those components, using DOM rendering and a dedicated score manager.
The source reports a completed playable game, but the public article shortens parts of the code. The evidenced outcome is therefore a documented design-and-generation workflow with representative implementation, not an independently tested release assembled from the excerpt. The account's useful detail is the human checkpoint before coding: ambiguities about state and component responsibility were resolved in the plan rather than left for the agent to guess during implementation.
Prompt
Original prompt
Source: note · sujitarou (すじたろう)
Frequently asked questions
What did the human clarify?
State transitions, coordinate origins, gravity order and separation of timing from rendering.
How was drawing organized?
Renderer handled DOM output while Game owned progression and timing.
Is the complete implementation printed?
No. The article abbreviates some code sections, so a full independently runnable release is not established.
More details
About this account
Gemini first produced requirements for paired falling blocks, connected-color clearing, chain reactions and keyboard or touch input. It then proposed Game, Field and Renderer components. The author did not accept that abstract structure as a complete specification; he supplied detailed questions about state transitions, landing previews and the coordinate-system origin.
Japanese original and translation opened. Original prompt excerpt retained in Japanese. The post claims a completed playable game but its public code excerpt omits sections; no independent play test or full release is inferred. Original prompt excerpt retained from the source.
Credit: sujitarou (すじたろう) on note
Source published 19 Jul 2025
Source checked 14 Oct 2026
Tools and topics
Gemini CLI · JavaScript · HTML · DOM
Puzzle prototype · Game state design
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.