---
title: "We built the game in six days. The store review took fifteen."
search_title: "How We Shipped ChitraYatra: AI Art, Music and Play Review"
description: "We built ChitraYatra in six days — 25 windows to 169, five ways to play, 72 AI-generated scenes and four generated scores — and then Google Play's review took 15 days and we missed RevenueCat Shipaton by three. This is how the whole game was made, including the rule we broke on day two."
author: "Prajjwal Pathak"
published: 2026-10-04
canonical: https://cybiqon.in/lab/shipped-the-game-missed-the-deadline
tags: [Games, Shipaton, Flutter, RevenueCat, Generative AI, Indian Art]
---
# We built the game in six days. The store review took fifteen.
*By Prajjwal Pathak · 2026-10-04 · [https://cybiqon.in/lab/shipped-the-game-missed-the-deadline](https://cybiqon.in/lab/shipped-the-game-missed-the-deadline)*
Three weeks ago we published [the first post in this series](/lab/kolam-rangoli-mandala-indian-art-puzzle-game), about the Indian art traditions we had chosen for a puzzle game, and ended it with a promise: "The RevenueCat integration, the release and what the judges need from us are later posts in this series."
This is that post, and it is the last one in the series, because there is no entry to write about. The game is live on Google Play. It is called **ChitraYatra** now — *a journey of pictures* — and it was never submitted to RevenueCat Shipaton 2026. Google's production review of the first public release finished on **3 October**. The Devpost deadline was **30 September, 11:45 pm PDT** ([Shipaton rules](https://revenuecat-shipaton-2026.devpost.com/rules)). We were three days late to a contest we had been building for, and not one of those three days was spent on the game.
The game itself was finished early. Between 13 and 19 September it went from 25 windows on a prototype branch to **169 windows in 18 collections**, five ways to play, 72 painted scenes, four pieces of music and a complete store catalogue, across **23 build bumps**. The build that went for review went up on 18 September, twelve days before the deadline.
So this is a making-of rather than an engineering post: how a one-person studio built a whole game in six days, where the art and the music actually came from, and what a store review costs when you treat it as paperwork instead of a dependency. It also has to correct the first post in public, because the rule that post was proudest of was relaxed the day after it was published.
## TL;DR
- **The game shipped: 169 windows in 18 collections, five ways to play, 72 Artisan scenes, four generated scores and seven yatras**, built between 13 and 19 September across 23 build bumps, from a 25-window prototype. Five of those builds went to Google Play.
- **A store review is a dependency, not paperwork.** Our own planning document said there was "no publishing gate to plan around" because an earlier app "was reviewed in a day". Build 34 went to production review on 18 September and cleared on **3 October — 15 days**, three days past the deadline. Count back two weeks, not two days.
- **We broke our own rule 24 hours after publishing it.** The first post said we would not prompt an image model to imitate a living tradition. On 14 September that rule was relaxed: **23 windows were drafted with AI assistance** and **72 Artisan scenes are AI-generated**, every one disclosed in the game, in the credits and on the store listing. The eight most figurative traditions were then drawn by our own code instead, on the Stories shelf.
- **The art cost about $13.35 and the music was generated too.** 72 scenes came to roughly twenty cents and two minutes each; the four scores were generated from our own prompts, then looped and mastered by a Python script that treats the loop as a circle so no filter clicks at the seam.
- **The listing is already out of date.** It says 145 windows, four modes and 24 scenes. The game ships 169, five and 72, because the description was written on 15 September and the game kept growing for four more days.
## What actually shipped
ChitraYatra is a calm puzzle of stained glass. A drawing is cut into hexagonal panes; you turn, trade or carry panes home until the lead lines meet, and each closed shape lights in its own colour. The first post covered that mechanic and the traditions behind it. What it could not cover is how much game got built around it in the week after it was written.
| | 13 September | 19 September |
|---|---|---|
| Windows | 25 | **169** |
| Collections | 5 | **18** |
| Ways to play | 1 | **5** |
| Artisan scenes | 0 | **72** |
| Music | a synthesised drone | **4 scores** |
| States and union territories on the map | 0 | **36** |
| Journeys (yatras) | 0 | **7** |
Windows in the game, 13 to 19 September. Almost the whole jump is one day: the day the map of India arrived and every state needed its own art. The dip is two AI-drafted windows being thrown away.
The shape of the game is a map. Every state and union territory opens its own art — kolam from Tamil Nadu, pookalam from Kerala, mandana from Rajasthan, phulkari from Punjab, the woven puan of Mizoram — and a test fails if two states share one. The boundaries are [DataMeet's India maps](https://github.com/datameet/maps) under CC BY 4.0, checked against the Survey of India's political map. Around that sit a gallery of shelves, seven **yatras** (journeys that stamp a passport once every window on the route is lit), a festival almanac that opens the game on a festival's own window, and **Artisan**, a second game entirely: a painted scene of a place, cut into hexagons, that you drag back together.
There are five ways to play a window, and the fifth arrived on the last day: **Line**, where one pane starts lit and light spreads along the lead, so only glass the light has reached can be turned. 168 of the 169 windows qualify for it. The exception is the tutorial, which says so on screen.
## Six days
The pace is the story, so here it is as a table. Every row is a day's commits in the game's repository.
| Day | What happened |
|---|---|
| **13 Sep** | The old mechanic is deleted — engine, painters, gallery, editor, 73 figures. The map of India lands and every state needs art, so the count goes 25 → 139 in a day. A title screen replaces the menu. |
| **14 Sep** | Four ways to play, in the owner's order. Windows are cut ahead of time because cutting 139 at launch took about 12 seconds. The billing library is swapped for RevenueCat. Four generated scores replace the drone. Artisan is invented. |
| **15 Sep** | Artisan ships with 24 scenes. A three-phase polish pass — trust, then feel and flow, then comfort — finds most of the bugs in this post. |
| **17 Sep** | Night windows, settings inside a window, the first paid window pack, and the rename: Curvved becomes ChitraYatra. The backdrops start moving. |
| **18 Sep** | A new upload key, tablet screenshots, **build 33 to internal testing, build 34 to production review**. Then offerings, Patron, yatras and the almanac. |
| **19 Sep** | Two agent worktrees in parallel: Monsoon (a window pack) and Stories (eight traditions drawn by code). Then Line mode, five more scene packs, and build 37. 3,347 tests pass. |
Then nothing. The repository has no commits between 19 September and today, because everything after the 19th was waiting.
Two things in that table are worth pulling out, because they are the reason six days was possible at all.
**The engine never imports Flutter.** That is the same rule that kept [a previous game's level generator](/lab/puzzle-generator-random-walk-doesnt-work) testable, and it means every window can be cut, solved and checked in bulk from the command line before anyone plays it. 169 windows are not 169 decisions; they are one validator run.
**Two agents worked in separate git worktrees on the 19th**, one on Monsoon and one on Stories. Both finished, and both wrote in their own notes that the game now had 161 windows — each had counted correctly from the same 153-window base, and neither knew about the other. The merge made it 169. The documents still say 161, which is a fair summary of how the week went.
## Drawing a country in code
The quickest way to describe the art pipeline is that **most of this game is drawn by Python scripts that emit SVG**, and the SVG is imported as lead lines and coloured facets. Kolams come from a mirror-curve generator; rangoli and mandalas from a ring generator; jaali screens from Hankin's [polygons-in-contact construction](https://cs.uwaterloo.ca/~csk/publications/Papers/kaplan_2005.pdf); mehndi, alpana, mandana and pietra dura from a motif library of butas, vines, lotuses and fish.
The piece that unlocked the paid packs is a class called `Scene`. A window used to be a figure on paper. A pack had to be richer than that, so a scene is built in layers — sky at the back, water, then figures in front — and then flattened:
> Flattening is what makes layers possible at all: the importer leads every facet's edges, so a sky facet drawn under a kite would lead straight through the kite. `Scene.faces` splits every edge where it meets another, drops the stretches hidden inside a figure in front, and walks the faces that remain, each coloured by the topmost layer under its middle.
It also reports what the cut will punish: faces thinner than about half a tile, and points where five or more pieces meet. The result is windows with 29–59 lit regions where the free shelves have 13–28 — denser glass, which is what a player can see they paid for.
Rain on the Lotus Pond, from the Monsoon pack, emitted by the game's own drawing tool. Shading stands in for the glass colours. The rain is lead with no glass of its own — long slanting lines, spaced so the glass between them stays a pane and never a sliver.
When the drawing could not be done by code, it was done by hand in code anyway. The Andaman and Nicobar Islands were meant to come from an AI draft; the dugong came out looking like a shark and the hornbill was unreadable, so that state's windows were plotted by hand instead.
## The rule we broke on day two
The first post was published on 13 September. Its clearest promise was this:
> **Gond, Madhubani and Warli wait for commissioned artists.** … We will not generate these styles, and we will not prompt an image model to imitate them.
On 14 September that rule was relaxed, and it was relaxed twice in one day.
The first change was the owner's argument, and it is correct: **an art style is not property.** Copyright protects particular artworks, not a style — that is the idea–expression line — and a Geographical Indication protects a *name* on goods, not a manner of drawing. So "commission-only" had been a brand choice rather than a legal requirement. The policy now allows **original compositions drawn by our own code** in a tradition's visual grammar, labelled *"inspired by X, Region"* and never presented as the thing itself. That is defensible, and it is what most of the map is.
The second change is the one that contradicts the post. Later the same day, the figurative traditions — Madhubani, Gond, Kalamkari, Warli, Sohrai-Khovar, Rogan, Kalighat's secular subjects — were **drafted in Google Stitch**, an AI design tool, as vector panels that our importer turns into windows. **23 windows in the game carry an AI-assisted provenance.** The policy document still contains, a few lines above that decision, a bullet saying AI image models are "still out, whatever the law allows" for exactly these traditions. Both rules are in the same file. Nobody reconciled them, and the second one shipped.
Here is what was actually done about it, which is not nothing:
- **Every AI-assisted window says so.** Its lore card reads "Inspired by X · design AI-assisted", the prompt is kept verbatim in the level's data with its date, and a row goes into the credits file. A test fails the build if an AI-assisted window lacks its prompt, its date or its "inspired by" line. Google Play itself asks only for a [self-declaration of AI-generated store-listing assets](https://support.google.com/googleplay/android-developer/answer/17262077); everything above is inside the game, where no policy required it.
- **The prompts forbid the sacred.** No deities, no religious symbols or ritual squares, no text, original compositions only.
- **Weak drafts were thrown away rather than shipped.** Of the first eleven, three were redone and one twice. In the second round, 15 of 17 shipped. The two that did not are the most useful detail in this post: **Twin Blossoms** was dropped because its centre — a blue flame on a yellow pedestal — reads as a butter lamp, a Buddhist ritual object, in a Buddhist community's tradition; and **Covered Pot** was dropped because the black pot, cut into white slivers, read as cracked.
- **The eight most figurative traditions were then drawn by our own code anyway.** On 19 September a shelf called **Stories** added a free window each for Madhubani, Sohrai, Kalamkari, Rogan, Gond, Warli, Pattachitra and Kalighat — not AI-assisted, drawn in a Python tool, each lore card crediting the community and saying the window is inspired by the tradition rather than an example of it. A test bars ten words from their names and lore: Jagannath, Durga, Krishna, Ganesha, Shiva, Lakshmi, Kali, puja, kohbar, chauk.
And here is what did not change, because it never depended on the law: **no deity, no ritual diagram, no yantra, no Warli marriage chauk, no swastik, no script, and no images of the Andaman and Nicobar peoples.** Those are still refused outright.
The risk is written down in the repository in one sentence, and it is worth quoting exactly as it stands:
> The risk, stated plainly: artists broadly object to AI imitation of their work, and tribal art drawn by AI is the kind of thing that draws criticism. … Disclosure and the commissioning plan are the answer, not concealment.
I think that is the right answer and I am not certain of it. Commissioned packs are still the stated goal, with the artist's name on every window, and no artist has been commissioned yet. The honest status is that the first post described a standard we then did not hold, and the version of it we did hold — original compositions, disclosed, with the sacred refused — is a weaker standard that we can at least show our work for.
## Artisan: 72 scenes for about $13
Artisan is the second game inside the game. A painted scene of an Indian place — Hampi at dusk, the tea hills of Munnar, Varanasi's ghats — is cut into whole hexagons and you drag them home; pieces that belong together fuse and move as one, which is a [union-find](https://en.wikipedia.org/wiki/Disjoint-set_data_structure) over the board after every move. You can choose 54, 77 or 126 pieces.
Those scenes are AI-generated images, and that is the decision the art policy carved out explicitly: **landscapes and monuments seen from outside only**, never a tradition's grammar, never a living artist's style. Every scene says "AI-generated scene" when it is finished, on the About page and in the credits, and its prompt and date stay in the data.
They share one hand because they share one sentence. Every prompt is built from a fixed style string:
> A luminous stained-glass painting, tall portrait 3:4, filling the frame edge to edge. Bold flat shapes of glowing colour separated by thin dark lead lines… No text or lettering, no signatures, no borders or frames, no people's faces, no deities, idols or religious icons, no temple interiors. An original artwork, not a copy of any photograph or existing painting. Subject: {subject}, {light}.
The economics are the part worth reporting. The first five scenes were made by hand in ChatGPT; the next nineteen were generated through an API for **$3.73**, back in about ten minutes, and none needed redoing. Hill Stations added eight for **$1.57**. Five more packs added forty for **$8.05**, one redo included. That is **72 scenes for roughly $13.35** — about twenty cents and two minutes each — against a quote from a human illustrator that would have ended the feature before it started. The art budget was not the constraint; the checking was.
Because every scene *is* checked, by eye, for text, faces, idols and wrong landmarks. Konark was regenerated because the first image was a wooden cart rather than the temple. The Temples pack prompts say "no carved figures" and show every sacred place from outside only.
Three production bugs from Artisan are worth keeping, because none of them was in the generator:
- **White seams down every vertical edge.** Pieces are cut 2.5% large so that neighbours overlap, but the texture atlas cell was sized to the plain hexagon, so each piece lost its overlap. The test for it is a flat red scene: any white in it is a gap.
- **The hint drew underneath the pieces.** The board in Artisan is always completely covered, so the hint outline was never once visible. The owner's verdict was "the hint does nothing in artisan". Anything meant to be seen is drawn over the pieces now.
- **The finish had nothing left to finish.** The completion animation was the seams melting — but a scene is assembled seam by seam, so by the last move almost every seam had already melted. "No animation or any sense of achievement," as the playtest put it. The light now plays over whatever state the board ended in.
## The music was generated too, and then it was engineered
The game had four layers of synthesised drone, written in Python, that faded up as a window filled. On 14 September they were replaced by four instrumentals generated with Google's [Lyria](https://deepmind.google/models/lyria/) from the owner's own prompts — one for each quarter of the country. Lyria's output carries an inaudible [SynthID](https://deepmind.google/technologies/synthid/) watermark, and the original renders keep their [C2PA Content Credentials](https://c2pa.org/); our own Opus encode drops those credentials, so the originals are kept beside the shipped files for provenance. The Morning Kolam (south) is veena, bamboo flute and tanpura; Drawing at First Light (west) is sarangi and kamaicha-inspired strings.
Generating them took an afternoon. Making them usable took a Python mastering script, and that script is the most genuinely technical thing in this post.
A game loop has to be seamless, and each render was a ~174-second piece with a quiet opening and a long fade-out. You cannot simply cut it:
> **The loop is an overlap, not a cut.** The piece's own fade-out is laid over its own opening… so both voices are continuous across the seam by construction — the ending simply rings on as the piece begins again, the way a musician would join it.
Why the music does not click. The tail is not discarded and it is not crossfaded at playback; it is added onto the head once, offline, so that the first sample of the loop already contains the last.
That alone is not enough, because everything you do afterwards can put the click back:
> **Every later stage treats the loop as a circle**, because a filter, a compressor or a resampler run over the file from one end to the other starts from a different state than it ends in, and that difference is a click at the seam.
So the EQ and the reverb are applied as a single FFT over the whole loop — circular convolution, so the reverb tail of the last bar wraps onto the first — and the compressor and the resampler are run over the loop padded with its own ends, which are cut away afterwards. The reverb itself is synthesised in numpy: decorrelated stereo noise in four bands, each with its own decay so low frequencies ring longest, 20 ms of pre-delay, mixed quietly because the renders are already reverberant and this is glue rather than a hall. Loudness is **one linear gain** to −18 LUFS with the true peak held under −1 dBTP, because a dynamic normaliser would ride the gain and break the loop. The −1 dBTP ceiling and the gated measurement come from [EBU R 128](https://tech.ebu.ch/publications/r128); the −18 target does not. R 128 normalises broadcast programmes to −23 LUFS, and −18 is our own choice for a phone speaker under a layer of chimes.
The four loops ship as [Opus](https://opus-codec.org/) at 64 kbps, about 1.5 MB each. The script refuses to write a file that fails its own checks: the decoded length must equal the written length, the step across the seam must be no worse than an ordinary sample step, and the spectral change at the seam must be no larger than at 400 random joins elsewhere in the piece. Those seam numbers are in the repository for all four scores.
Two details I like more than I should:
**The music is the progress bar.** There is no progress bar. The score plays only while a window is being made — the title, the map and the gallery are silent — and it sits behind a low-pass filter that opens from 1.4 kHz to 16 kHz on a log scale as the window fills, swelling as it goes, always under the chimes. You hear yourself getting closer. The first build ran it too loud and the playtest said so.
**The chimes are retuned by playing them faster.** The eight chime samples are C pentatonic, and the mastering script also detects each score's best-fitting pentatonic key, so the chimes are pitch-shifted into the current score's key by changing playback speed — no new audio files for four regions. The fit is only 0.70–0.78, so an Indian mode with a komal note will sometimes rub against a chime, which is recorded as a known compromise rather than a solved problem.
One open item, stated as the repository states it: **the seams have not yet been confirmed on a phone.** They pass every measurement on this machine.
## Packs, journeys and a calendar
The content that is sold is new content. Two window packs, six Artisan scene packs, and a set of cosmetic finishes for the lead and the glass. **Nothing that was already free was ever moved into a pack** — a checking tool refuses to import a scene into a pack if that scene is free in the committed data — and a scene you have already started playing never locks, whatever you own.
The free structure around it is deliberately unmeasured. Progress is shown as things made rather than percentages: a ring per shelf, a passport stamp per yatra, a cabinet of keepsakes that are earned and never bought. There are no counts on the gallery screen and a test asserts that none appear. The one-move Hint is free and unlimited and "Show me how" plays its first three steps free, so a stuck player is never charged to get unstuck.
The festival almanac is the piece I would defend hardest to a product manager. On Sankranti, Margazhi, Holi, Onam, Diwali, the Pushkar Fair and the Hornbill Festival, the game opens on that festival's window with a line of story. It is a calendar that knows what is being celebrated — not an event, nothing timed, nothing missed if you do not play. The dates are a hardcoded table for 2026–2028 checked against published panchangs, with a note in the code to extend it before 2029, because there is no lunar arithmetic anywhere in this game and there should not be.
## RevenueCat, offerings and Patron
This is the part the first post promised, so here is the structure, without the prices.
The billing library was swapped for RevenueCat on 14 September, four days before the first upload. The app does not hold a hardcoded list of things to sell: **the shelf is fetched from RevenueCat's current offering**, and a purchase goes through that offering's package, so a price experiment can attribute it. That is the documented way to use the product: an offering is "the selection of products that are 'offered' to a user on your paywall", and RevenueCat [strongly recommends](https://www.revenuecat.com/docs/offerings/overview) referencing the current offering rather than a hardcoded identifier, so the shelf can change without an app update. Offering metadata can carry the words shown on the upgrade sheet — but any metadata string containing a currency symbol is dropped before it is displayed, because a price written by hand is a price that will eventually be wrong in some country.
The rule the whole store client exists to enforce came from a previous game of ours that shipped a "Remove Ads" button for a product that did not exist in the console, where it does nothing, forever, with no error anywhere:
> **No button is drawn for a product the store did not return.**
So an unresolved product is null, every call site draws nothing when it is null, buying an unresolved id is a no-op, and there are tests for all three. The same code path covers a sideloaded build, an emulator, a device with no Play Store, a country the game is not sold in and a network outage: no purchase UI, whole game.
There is also a **Patron** product that covers everything including packs that do not exist yet, and it is shown *only* to a player who owns nothing paid — someone who already bought a pack goes on buying item by item, because a bundle priced for everything would charge them twice for what they have.
The least glamorous and most useful piece: **the store catalogue is a JSON file and a script.** It declares every product, entitlement and offering across both the Play console and RevenueCat, and the script prints what would change before it changes anything. Its dry runs read like a build log — "36 already right, 65 changes to make", then after applying, "96 right, 0 to change", then "85 already right, 8 changes, all of them Monsoon", and finally **"159 items right, 0 changes"**. Setting up nineteen products by hand across two dashboards, twice, is exactly the task that produces the SKU typo the rule above exists to catch.
## The fifteen days
Here is the sentence from our own planning document, written before any of this:
> There is no publishing gate to plan around. Confirmed from this account's own history: four apps published, the 12-tester / 14-day closed-testing requirement does not apply, and Orbitone was reviewed in a day. **The build is the critical path and the store is about a day behind it.**
Every clause of that is true except the last one, and the last one is the only one that mattered.
Build 33 went to internal testing on 18 September. Build 34 went to **production** review the same day. Those are not the same queue. Google's own documentation says that [app updates on internal test tracks "are not subject to reviews"](https://support.google.com/googleplay/android-developer/answer/9859654) and that a build published to an internal track reaches testers ["within minutes"](https://support.google.com/googleplay/android-developer/answer/9845334) — which is exactly the experience that taught us the store was a day behind the build. The first *public* release is a different animal, and ours sat in review until **3 October**.
The whole story in one picture. The game was finished twelve days before the deadline. The review was not, and nothing in the review was ours to speed up.
Google does not publish a median review time or a service level. What it publishes is a ceiling and a warning: processing "can take a few hours or up to seven days (or longer in exceptional cases)", and the same page recommends "a buffer period of at least a week between submitting your app and going live". Fifteen days is our own measured outcome, not a number Google quotes, and it is well outside the range the ceiling implies.
Nothing dramatic happened in those fifteen days. There was no rejection, no policy strike, no appeal: the app was simply in review, and there is no way to buy a faster one. The deadline required a live store URL inside the submission window, so when the review cleared, the window had closed.
The worst part is that the contest rules said so. Reading them again afterwards: "Software applications … must be **fully published** … by the submission deadline. Note: The App Review process can take multiple days or more. We recommend submitting to the store early to get through the review process and make updates as you add more to your app." That is the exact failure, printed in advance, in the rules we had read for everything else.
The repository records the conclusion in one line:
> **A store review is a dependency with a tail of its own — count back two weeks, not two days, from any deadline that needs an app to be live.**
What that would have meant in practice: the 18 September upload should have been a 15 September upload, and the "finished" version would have been the build from that day — 145 windows instead of 169, and no yatras, no almanac, no Patron, no Stories, no Monsoon and no Line mode. Everything added after the 17th was an update, and updates were never the problem. The entry needed version one to be *public*, not good.
The honest second conclusion is that nothing about the contest changed what got built. The deadline was never allowed to decide the game — the first post said that in September and it held — and the launch kit that was assembled for the judges (the screenshots, the shot list, the description, the store catalogue) is now just the game's launch kit.
## What the listing still says
One more paragraph, because a post like this does not get to stop at the flattering parts.
The live store listing, which I checked while writing this, says the game has **145 windows** and **four modes**, and that Artisan has **24 scenes**. It ships 169 windows, five modes and 72 scenes. The description was written on 15 September — and it even carries a note to itself saying "before submitting: update the window and scene counts if they have changed" — then the game grew for four more days and nobody read the note. The Hindi description says the same wrong numbers.
The repository is worse. `CLAUDE.md`, the README and the knowledge bundle's own index all still read "**Pre-release; nothing has shipped**", two weeks after it shipped. The note recording that the Shipaton entry was never made is not even committed. A tree whose first ground rule is "if you build it, it gets a knowledge-bundle entry the same day" went quiet on the day the waiting started, which is exactly when the record is least interesting to write and most useful to have.
Neither is hard to fix, and both are on the list. They are here because the gap between what a project knows and what its own files say is the cheapest kind of debt to acquire and the easiest to forget you are carrying.
## Verdict
The game is good, and six days is a real number: 169 windows, five ways to play, a map of 36 states and union territories, 72 scenes, four scores and 3,347 passing tests, built by one person with agents working in parallel worktrees, from a prototype that had 25 windows and one mechanic.
The three things I would carry to the next launch are smaller than that.
**A store review is a dependency, and the only one you cannot pay to accelerate.** We budgeted a day because an earlier app took a day, and the first public release of a new app is a different animal from an update to an old one. Two weeks, every time.
**A policy that contradicts itself ships the permissive half.** The art-sourcing document held both "no AI image models for these traditions" and "figurative traditions are drafted in Stitch" on the same day, in the same file. The one that got implemented was the one that let the map be finished. If a rule matters, the moment it is relaxed is the moment to delete the old sentence rather than leave it as decoration.
**Generated assets move the bottleneck, they do not remove it.** The music took an afternoon to generate and a day to master; the scenes cost $13.35 to make and every one still had to be looked at by a person who knows what Konark looks like. What generation bought was not cheap art. It was a game with four scores and 72 painted scenes existing at all, at a scale where a one-person studio would otherwise have shipped neither.
---
*All figures here are first-party: the window and scene counts from the game's own data files, the builds from the version history, the image-generation costs from the runs recorded in the repository, and the review dates from the launch file written on 3 October. The store-listing counts were read from the live Google Play page on 4 October 2026. The window in this post is emitted by the game's own drawing tool; the diagrams are drawn by hand. Nothing here is legal advice, and the view that a style cannot be owned is our reading, not a lawyer's.*
## FAQ
### How long does Google Play review take for a new app?
Google does not publish an average. Its documentation says processing "can take a few hours or up to seven days (or longer in exceptional cases)" and recommends a buffer of at least a week between submitting and going live. ChitraYatra's first production release went for review on 18 September 2026 and cleared on 3 October 2026 — fifteen days — on an account that had already published four apps, one of which was reviewed in a single day. Budget two weeks.
### Is internal testing reviewed as slowly as a production release?
No, and conflating the two is how we missed a deadline. Google's documentation says updates on an internal test track are not subject to review and reach testers within minutes, which makes the store feel like it is a day behind your build. A first public production release is reviewed properly: ours took fifteen days while the internal track had been live throughout.
### Can you use AI-generated art in a game on Google Play?
Yes, and ChitraYatra does: its 72 Artisan scenes are AI-generated images and 23 of its windows were drafted with AI assistance. What matters is what you generate and what you tell people. We keep every prompt and date with the asset, say "AI-generated scene" on the scene itself, disclose it on the About page, in the credits file and in the store description, and refuse deities, ritual diagrams, script and any living artist's style.
### Is it acceptable to imitate Indian folk art like Madhubani or Warli with AI?
Legally, a style is not owned — copyright protects particular artworks, not a manner of drawing, and a Geographical Indication protects a name on goods. Ethically it is contested, and artists broadly object to AI imitation of their work. ChitraYatra's answer is partial: original compositions labelled "inspired by", the sacred refused outright, the eight most figurative traditions redrawn by our own code rather than generated, full disclosure, and commissioned artists still the stated goal.
### How do you make a music loop that does not click?
Do not cut the file — overlap it. Lay the piece's own fade-out over its own opening so the first sample of the loop already contains the last, and then treat the loop as a circle for everything that follows: apply EQ and reverb as one circular convolution, and pad the compressor and resampler with the loop's own ends. A filter run from one end of a file to the other starts in a different state than it ends in, and that difference is the click.
### What is ChitraYatra?
ChitraYatra is a puzzle game for Android, free to download with optional purchases, in which stained-glass windows drawn from Indian art traditions are cut into hexagonal panes that you turn, trade or carry home until the lead lines meet and the glass lights. It has 169 windows across 18 collections, a map with one art for every state and union territory, five ways to play, and a second mode called Artisan that assembles painted scenes of Indian places.
### What was RevenueCat Shipaton 2026?
Shipaton 2026 was RevenueCat's app-building competition on Devpost. It required an app's first public release to land on the App Store, Google Play or the Galaxy Store inside the submission period, to be fully published by the deadline, and to use the RevenueCat SDK to power at least one purchase. Submissions closed on 30 September 2026 at 11:45 pm PDT. ChitraYatra met every requirement except being published in time, because its Play review cleared on 3 October.
### How much does it cost to generate 72 images for a game?
ChitraYatra's 72 Artisan scenes cost about $13.35 in total through an image API — roughly twenty cents and about two minutes each at 1152 × 1536. The generation is the cheap part: every scene still had to be reviewed by a human for text, faces, idols and misidentified landmarks, and one was regenerated because the model drew a wooden cart instead of the temple at Konark.
## Sources
- [ChitraYatra on Google Play](https://play.google.com/store/apps/details?id=com.cybiqon.chitrayatra) — the live listing, read 4 October 2026
- [RevenueCat Shipaton 2026 — official rules](https://revenuecat-shipaton-2026.devpost.com/rules) — Devpost
- [Announcing Shipaton 2026](https://www.revenuecat.com/blog/company/announcing-shipaton-2026) — RevenueCat, July 2026
- [Control when app changes are reviewed and published](https://support.google.com/googleplay/android-developer/answer/9859654) — Play Console Help
- [Publish your app](https://support.google.com/googleplay/android-developer/answer/9859751) — Play Console Help
- [Set up an open, closed, or internal test](https://support.google.com/googleplay/android-developer/answer/9845334) — Play Console Help
- [Declaring AI-generated content in Play Console](https://support.google.com/googleplay/android-developer/answer/17262077) — Play Console Help
- [Understanding Google Play's AI-Generated Content policy](https://support.google.com/googleplay/android-developer/answer/14094294) — Play Console Help
- [Offerings](https://www.revenuecat.com/docs/offerings/overview) — RevenueCat documentation
- [Experiments](https://www.revenuecat.com/docs/tools/experiments-v1) — RevenueCat documentation
- [Lyria](https://deepmind.google/models/lyria/) — Google DeepMind
- [SynthID](https://deepmind.google/technologies/synthid/) — Google DeepMind
- [C2PA — Content Credentials](https://c2pa.org/) — Coalition for Content Provenance and Authenticity
- [Opus codec](https://opus-codec.org/) — Xiph.Org / IETF RFC 6716
- [EBU R 128: Loudness normalisation and permitted maximum level of audio signals](https://tech.ebu.ch/publications/r128) — European Broadcasting Union, V5, November 2023
- [Islamic Star Patterns from Polygons in Contact](https://cs.uwaterloo.ca/~csk/publications/Papers/kaplan_2005.pdf) — Craig S. Kaplan, Graphics Interface 2005, on E. H. Hankin's 1925 method
- [Disjoint-set data structure](https://en.wikipedia.org/wiki/Disjoint-set_data_structure) — Wikipedia
- [DataMeet India maps](https://github.com/datameet/maps) — India boundary data, CC BY 4.0
- [Ten Indian art traditions made the mood board. Two made the game.](/lab/kolam-rangoli-mandala-indian-art-puzzle-game) — the first post in this series