Mario's Picross rebuild deck
FIDDLY
Deriving the clues takes ten minutes; producing puzzles that solve by deduction alone needs a line solver run as a generation filter, and without it you are shipping grids that require a guess.
You will get it, but one specific system will fight you.
Deriving the clues takes ten minutes. Producing puzzles that are solvable without guessing takes the rest of the day, and it is the whole difference between a nonogram and a grid of noise with numbers attached. Ask for the line solver explicitly as a generation filter rather than as a hint feature, then spend your review time on the drag painting, because a picross that makes you click 225 cells individually is a picross nobody finishes.
- Difficulty
- FIDDLY · 2 of 5
- First playable
- A weekend
- The original
- 2 team-years
- Released
- 1995 · Nintendo
- Genre
- Picture Logic Puzzle
Build a nonogram puzzle game as a single self-contained HTML file. DOM or Canvas 2D, no build step. Requirements: - Grid sizes 5x5, 10x10 and 15x15. Row and column clues are derived from the solution bitmap as the ordered run-lengths of filled cells. - Three cell states, not two: empty, filled, crossed out. A cross is the player's own notation and must never affect the win check. The win condition is filled cells matching the solution exactly, and nothing else. - The rule that separates a puzzle from a bitmap with numbers beside it: it must solve by deduction alone. Run a line solver over every candidate — for each row and column, enumerate every valid arrangement of its runs against the current known state and fill only the cells common to all of them, looping until nothing changes. If the grid is still incomplete, reject the candidate. Never ship a puzzle that requires a guess. - Drag painting: mousedown sets the target state from the first cell touched, dragging applies that same state to every cell crossed, and the drag locks to a single axis once direction is established. - Grey out a clue number once its run is satisfied, and dim an entire line when it is complete and consistent. - Puzzle bitmaps live in puzzles.json as binary strings you draw yourself, each with a title revealed on completion. Definition of done: every puzzle in the file solves end to end with logic alone, and I can drag-fill a row of ten without a single stray click.
- Hundreds of hand-drawn puzzles whose solutions resolve into something you actually recognise
- The Game Boy reveal chime and the little animation of a finished drawing
- Nintendo's trademark on the word, which is why every clone on the store is called Nonogram something
- Jupiter's thirty-year run of sequels and the difficulty ramp tuned across all of them
Drag painting with a locked axis
The difference between a grid people finish and a grid people abandon is about forty lines of pointer handling. The first cell sets the value, the drag applies that same value everywhere it goes, and the axis locks — it belongs in every tile editor, map painter and multi-select you will ever write.
ScopeAn evening— build just this, not the game
Build a grid painting input component and nothing else. Single self-contained HTML file, Canvas 2D, no build step. - A 20x20 cell grid with three cell states cycled by click: empty, filled, marked. - The mechanic: on mousedown, read the cell under the cursor and compute the target state ONCE from it. That state is then written to every cell the drag touches, including cells it re-enters. A drag must never toggle per cell, or a shaky hand paints stripes. - Once the drag has moved more than half a cell, lock it to a single axis — row or column — until mouseup. - Interpolate between pointer events with a line walk, so a fast flick fills every cell on the path and skips none. - Right-drag paints the third state. Touch events go through the same code path. Escape mid-drag reverts the entire stroke as one undo unit. - Display a stroke counter and the cell count of the last stroke. Definition of done: flicking the pointer across twenty cells within a single frame fills all twenty, and dragging a wobbly diagonal fills one straight line.
Not a clone — Mario's Picross re-themed and cut down to something you can finish. The angle is the important reel: it is what turns a project into a weekend. 24,360 ways to land.
Nile Offline
Mario's Picross, but against bots — no netcode at all, set in ancient Egypt. Rendered in PS1 low-poly with texture warping.
Build a browser game called "Nile Offline". The pitch in one line: a picture logic puzzle in the spirit of Mario's Picross, but against bots — no netcode at all, set in ancient Egypt. WHAT THIS IS Take the SHAPE of Mario's Picross — its core loop, and whatever makes that loop good — and rebuild it as your own game in a different world at a smaller scope. Use your own names, art and audio, which you want anyway: a reskin of somebody else's game is less interesting than a new one that works the same way. THE ANGLE — this is the important constraint, honour it above everything else Against bots — no netcode at all. Everything runs locally. No server, no lobby, no lag compensation. Bots use a small behaviour tree with a tunable reaction time. This single cut removes the hardest engineering in most multiplayer games. This is what makes the project finishable. If a decision would push the scope back towards the original's, take the smaller option every time. THE THEME Ancient Egypt. Tomb architecture as level design: sealed rooms, traps built by people who expected robbers, and hieroglyph legibility as a UI language. The theme is not a coat of paint. Let it change what the mechanics mean — a reload, a health pack and a locked door should all be things that make sense in this world and nowhere else. LOOK PS1 low-poly with texture warping. Vertex-snap positions to a low-resolution grid in the vertex shader, use affine texture mapping so textures swim, dither to 15-bit colour, and fog the draw distance. REQUIREMENTS - Runs in a browser with no build step. Canvas 2D unless the angle genuinely requires 3D, in which case three.js. - Fixed-timestep update loop with interpolated rendering, so it behaves the same at 60Hz and 144Hz. - Every tuning constant in one CONFIG object at the top, exposed as live sliders in a debug panel. You will find the feel by dragging those, not by prompting. - All content — levels, entities, balance numbers — in JSON or plain data files, never inline in the logic. - Audio generated with the Web Audio API rather than asset files. - Respect prefers-reduced-motion: keep the fades, drop the shake and the parallax. BUILD ORDER 1. The core loop with placeholder rectangles, at the reduced scope the angle demands. No theme, no art, no audio. Make it fun as rectangles first. 2. The angle's consequences. Cutting to bots, or to turn-based, or to one level changes the design rather than just shrinking it — find out how and rewrite step 1. 3. The theme, as content and data. 4. The look, applied last as a rendering layer over a game that already works. Start by writing a one-page plan: the core loop, what the angle removes and what that frees you to do properly, and what you are deliberately leaving out. Wait for me to approve it before writing code.
Half the time one of these already does what you wanted, and the other half it saves you a week of solving a problem someone documented in 1997.
One count per game. No account — it is tied to a salted hash of your IP, which is not stored in a form anyone can reverse. Every build adds 2 team-years to the counter on the homepage.
Then try these
Questions
How hard is Mario's Picross to rebuild with an AI agent?
Yes — every game is buildable at some scope. The question is how hard, and Mario's Picross is FIDDLY (2 of 5). You will get it, but one specific system will fight you. Deriving the clues takes ten minutes; producing puzzles that solve by deduction alone needs a line solver run as a generation filter, and without it you are shipping grids that require a guess. Reckon on a weekend to something you can actually play — not to something that matches the 2 team-years Jupiter / Ape spent.
What makes Mario's Picross hard to rebuild?
Deriving the clues takes ten minutes; producing puzzles that solve by deduction alone needs a line solver run as a generation filter, and without it you are shipping grids that require a guess. That is why it sits at FIDDLY rather than a tier either side of it. If you want the idea without the project, the transferable part is drag painting with a locked axis — an evening of work.
How long does it take to build a Mario's Picross clone?
Wrong question, and it is worth saying why. Nobody rebuilds Mario's Picross — the original took Jupiter / Ape on the order of 2 team-years, released in 1995 on Nintendo. What you can do is reach something playable and genuinely yours in about a weekend, and then keep going for as long as it stays interesting. Any figure that claims otherwise is measuring a prototype and calling it a game.
What do I lose by building my own Mario's Picross?
Hundreds of hand-drawn puzzles whose solutions resolve into something you actually recognise. The Game Boy reveal chime and the little animation of a finished drawing. Nintendo's trademark on the word, which is why every clone on the store is called Nonogram something. Those are the parts a prompt will not hand you.
Which AI coding agent should I use to build it?
Any of Claude Code, Codex or Cursor will handle this prompt. Paste it as your first message, let the agent scaffold the project, then iterate on feel — the second, third and tenth prompts are where a game actually gets good. Work in an empty folder or a fresh git branch so you can throw it away cheaply.
One email when new games go on the list. No other reason to email you, ever.