A game whose 3D assets were 100% AI-generated to the first prototype — Bloom Garden
Starting with no pre-made resources, every 3D asset was generated in PicoBerry until the first playable prototype was standing. That took about two weeks. Systems, UI and optimisation came after — and this page covers what that actually required, including the parts AI did not solve.
Can you build a real mobile game with 3D assets that were generated by AI?
Bloom Garden shipped on Google Play, and every 3D asset in it — flowers, props, set dressing — was generated in PicoBerry by a developer with no illustration background. To the first playable prototype the assets were 100% AI-generated with nothing prepared in advance, and that took about two weeks. Past that point the honest answer gets more specific: generating assets is one job and finishing a game is another. UI needed repeated human feedback, and props that repeat across the scene turned into a performance problem that art direction and optimisation had to solve. Generation carries the asset stage a long way; scene budget, UI and the last stretch of polish are still yours.
What is Bloom Garden?
A garden management game about growing an empty field into a thriving flower business.
Plant, grow, harvest
Plant flowers, watch the garden come back to life, and harvest what you grow.
Craft and fill orders
Turn harvested flowers into products, complete villager orders, and fund the next expansion.
Clear, repair, expand
Cut back overgrowth, repair broken machines and buildings, and push the garden outward.
How did development actually go?
From planning to release, in the order it happened.
- Team size
- 1A game developer at UModeler
- Duration
- about 4 weeks20 working days · roughly 8 hours a day
- Prototype reached
- about 2 weeksProduction, selling, upgrades, quests, cinematics
- Pre-made resources
- none3D assets generated in PicoBerry wherever possible
The goal was explicit — start with nothing prepared and carry a management sim all the way through. After the prototype, the remaining time went into game systems, UI, release prep, and optimisation on real devices.
Planning and prototype
A proven genre was the testing ground for how far generated assets could go.
The plan was a management sim: produce, sell, reinvest to produce more, then automate. It is a genre that holds its ground on mobile, so it made sense to test the range of PicoBerry assets on top of a loop players already understand. Similar games were studied for their core loop and systems.
Nothing was prepared in advance — every prototype asset came from PicoBerry. About two weeks in there was a genuinely playable prototype with production, selling, upgrades, quests and cinematics in place.
Building the asset pipeline
Images first. Never straight to 3D.
Because every model was generated, the first challenge was the flow itself. Objects were generated as images first, matched to the concept, and only moved to 3D once the image already looked like something the game could use.
- What went wrong first — Some characters would not hold their shape from a single image. After that, those objects were generated with back and side views supplied together so the model had more than one angle to work from.
- Polygon rule — Generate low by default, and only raise the count for shapes that genuinely needed it.
Systems and UI
Logic could be delegated. UI could not.
Game systems and UI were built with a coding AI (Claude Code). The HUD in particular was built with Unity UI Toolkit, and this is where the AI was unexpectedly weak — at reading a reference image and turning a request into the layout that was actually asked for.
Even with reference images supplied, the proportions between elements never landed on the first pass, so it took repeated rounds of UI images and feedback. This still reads as a place where a person has to set the direction and spell the request out.
Release and external testing
Deferring optimisation was paid for at the very end.
SDK integration and optimisation were what bit at the end. Development testing happened on a fairly capable device, so meshes in the thousands of polygons never surfaced as a problem.
On real hardware the cost showed up immediately, and with SDK issues landing at the same time, the work piled into the last stretch before release and external testing.
How were the 3D assets made?
The loop that produced every flower, prop and background object in the game.
Generate flower shapes
Before any mesh, generate several image candidates for the flower and compare. Flowers get collected into bouquets in game, so the two shapes have to read as the same family.
Generate the bouquet
Use the chosen flower as reference to generate the bouquet image. Colour and shape are locked here, before anything becomes 3D.
Mesh + texturing
Take the settled bouquet image into 3D in PicoBerry, generating mesh and texture together. Rather than aiming for perfect in one shot, generate, compare, pick, repeat.
Assemble in Unity
Import, place, and wire into the game systems. This is where the scene budget is actually decided.
A generated asset is a starting point you refine, not finished game content. Every prop above earned its place in the scene only after selection and correction.
① Flower candidate A
Dense clusters of small blooms on fine stems.
② Flower candidate B — chosen
A clearer flower shape. This became the reference image.
③ Bouquet image
Generated using the chosen flower as reference.
④ Mesh + texturing
The result of taking that image into mesh and texture together.
Generating low-poly assets directly with the newer model
A newer generation model applied later in the project showed a clear improvement in output quality and in low-poly generation specifically. Instead of building high and cutting down, it opened a path to generating at the target polygon count from the start — which makes this the most practically useful part of this page.
The bouquet that keeps appearing on this page is the example. It is the prop placed most often in the game, so its polygon cost hurt the most.
The first approach generated at roughly 5,000 polygons and then remeshed straight down to 1,000. Cutting that hard in one step wrecked the shape — the wrapping and ribbon collapsed and the flowers clumped into blunt masses.
The second approach set a low polygon count at the image-to-3D stage instead. The result held its shape even at low poly, and UModeler X was then used to tidy the details into something the game could use.
Generating repeatedly was not a burden. At roughly two minutes per generation, changing the polygon setting and comparing results was a realistic loop.
What did you learn about developing a game with AI?
The practical instincts someone attempting the same thing can actually take away.
One thing stood out above everything else — AI output does not land on what you wanted if your approach is “give it references and it will figure the rest out.” Style, role and structure have to be stated up front, several candidates generated and compared, and the result actually run and checked. That loop is the precondition for usable output.
Generating 3D assets
Do not generate 3D directly. Images come first.
Generate the image, then build the 3D object from that image. Keeping image style consistent kept the 3D results in the same register, which is why it mattered to fix one shared reference image — or one prompt line — for the whole game.
Without accounting for the hyper-casual style, the request was simply “draw a machine.” What came back was far too complex — a machine that looked like it would actually function.
Strip the mechanical detail and state the hyper-casual tone in the prompt. Reusing that prompt for the other machines — asking for role differences without working mechanisms — cut the number of revisions sharply.
Texture and style consistency
Fixing on a single generation model was the first condition.
- One model Compare models, pick the one closest to the style you are after, and stay on it.
- Reference images for variance When the same model still drifted, reference images pulled it back. Instead of “a building” or “an object,” the request became “a building this character would live in,” “an object this character would use” — a fixed reference image combined with the prompt to supply context.
Working with a coding AI
Give it numbers and the code improves. UI did not work that way.
Most system development went through a coding AI. Because every mesh was generated, optimisation was mandatory.
- Optimisation — what worked Hand the profiler output to the AI verbatim, have it reason from those numbers to a cause and improve the code, then measure again to confirm. Repeat.
- UI — what did not The in-game HUD was built in UI Toolkit, and layout proportions and alignment never landed in one pass. Even with a reference image and a rough description, getting the composition asked for often meant repeating, editing USS/UXML by hand, or pointing at the wrong part directly.
Where a person has to look
“There are enough references, it will handle it” was the mistake.
- Role and structure first In hindsight that is exactly what went wrong with the UI. The role and structure of each element should have been made explicit before anything else.
- Runtime environment Code that looks correct algorithmically can still be a problem in the real runtime and under the characteristics of a Unity app. That part always came back to running it and fixing what the test showed.
If we built the same thing again
- Judge runtime performance properly at the start and set polygon and asset rules from there. This time it ran without accurate measurement, which meant fixing assets late and hitting performance that was not smooth in ways nobody predicted.
- Leave real room at the end for profiling and build testing. Small background objects could only be placed late in development, and once objects that had not existed all appeared at once, the load surfaced far too late.
- Generate images in batches of two to four and compare, not one at a time. AI output frequently misses on the first attempt, and this one change alone made the work noticeably easier.
How far did AI get, and where did it stop?
The useful part of this case is not the success story — it is this boundary.
What AI generation covered
- A game-sized volume of props without a dedicated artist. A developer with no illustration background could carry it.
- A prototype and an external test build that were genuinely playable.
- Fast iteration on impressions — no being locked to one expensive asset, generating candidates and choosing between them.
- The newer model applied later showed a clear improvement in output quality and in low-poly generation.
What still needed human hands
- UI design and layout took repeated human feedback. Intent, reference images and game context did not land accurately in one pass.
- Scene-level budget — polygons, shadows, textures, and objects that accumulate — is not something generation decides for you.
- Art direction across the stretch of quality a player actually feels.
- Performance review. A coding AI prioritises getting the feature on screen, so performance structure had to be stated by a person, or by a separate review loop, early.
- Minimum mesh and texture edits to fit the in-game staging were done by hand in UModeler X.
What did the polygon budget teach you?
The most widely applicable lesson from this project, and how it was solved inside PicoBerry.
Repetition multiplies quietly
A single bouquet with a high polygon count looks harmless on its own. But as the game progresses and the count climbs, the same asset is drawing hundreds of thousands of polygons at once. What got worse was not the asset — it was the scene.
Generate low, rather than remesh down
Building high and cutting down with a remesh risks wrecking the shape, and the time it takes swings unpredictably. What settled it was the newer generation model built for low-poly meshes: generating low from the start cut polygons to under a tenth of the previous count while holding the shape, and read better than the build-then-remesh path.
Small on screen can be drawn cheaply
Objects that repeat small on screen do not need their full 3D complexity. Compare texture-based treatment, simpler meshes, or a billboard swap before insisting on the precise version.
Set the budget before you build
Optimisation slid to the deadline, which left too little room to tune shadows, textures and accumulated objects. The fix is to set polygon and performance budgets at kick-off and to place profiling in the middle of the schedule, not at the end.
Measurements were taken on a budget Android device, a Galaxy A16 (2340×1080). Before the work, some scenes dropped to 10–30 FPS; after the changes below it held 60 FPS.
| Target | Before | After |
|---|---|---|
| 36 bouquets in storage | about 400,000 polygons | about 18,000 polygons |
| Rose field growth + harvest (25×6 = 150 roses) | about 750,000 polygons | about 75,000 polygons |
| Textures (merged into a colour palette) | dozens at 2048 | one at 512 |
The same object multiplies its polygon cost once dozens or hundreds of them stack up in a scene. Cutting per-asset polygons and merging many textures into a single colour palette settled the frame rate even on a budget device.
① Remeshing down — the first approach
Remeshing a roughly 5,000-polygon model straight to 1,000 collapsed the wrapping and the flower shapes.
② Generated low from the start
Setting a low polygon count at the image-to-3D stage held the shape even at low poly.
③ Tidied in UModeler X
The generated result was finished into a usable shape in UModeler X.
What did the work look like in the editor?
Placing generated assets into the Unity scene and wiring them into systems — the part that took human hands.
Working in the editor
Wiring inspector values for the town-hall objects in the Unity editor.
What does it look like running?
Gameplay from the shipped build. The generated assets running as they are in Unity.
Frequently asked questions
What is Bloom Garden?
A garden management game on Google Play, developed by UModeler. You plant and harvest flowers, turn them into the products villagers order, clear overgrowth, repair facilities, and expand the garden. The 3D assets were generated in PicoBerry and the game itself was built in Unity.
Which PicoBerry features were used for the assets?
Image generation to settle the reference impression, 3D model generation from those images, and texturing of the result. Later in the project a newer model with better low-poly output was used as well.
How many credits did it take to make all the assets?
Roughly 82,280 credits in total — but do not read that as a quote. It includes every candidate that was never used: 514 images and 153 3D models, more than three images per model. That number is the cost of the very method this page keeps recommending, which is to generate several and compare rather than aiming for perfect in one shot. For scale: one developer covered every 3D asset a game needed, over about a month, inside a single subscription month. It was a first pass at the pipeline, so the trial-and-error share was large; a second run would come in lower.
Did AI make the whole game?
No. What PicoBerry produced was the 3D assets. The systems, UI, scene assembly and performance work were done by the team in Unity. Reading generated output as finished game content is reading this case wrong.
Do you need to be an artist to work this way?
Not to reach a prototype or a test build. Developers with no illustration background produced a game-sized volume of props this way. Across the stretch of quality a player actually feels, though, art direction was needed. It lowers the barrier to entry; it does not remove judgement and review.
How do you keep AI-generated assets from wrecking performance?
Set the polygon budget before you generate, not after. Forcing a high-poly result down with a remesh can wreck the shape, so it is better to generate at the target count or use a model with good low-poly output. And objects that repeat have to be treated as a scene problem — screen coverage, quantity, shadows, textures and LOD or billboard swaps have to be designed together.
Can you not just remesh high-poly assets down?
Sometimes, but it was hard to rely on in this project. Large reductions risked wrecking the silhouette, and the time it took swung too much to schedule around. Generating at the target density from the start was more efficient.
What would you do differently on the next project?
Set performance and asset rules at kick-off, and place profiling and build testing in the middle of the schedule rather than at the end. Reserve independent time for pre-release optimisation and QA, and review UI and gameplay code for update cost and performance, not only for what appears on screen.
Your game assets, the same way
Generate 3D models from text or images, refine them, and export to the engine you use.