Why the old workflow no longer worked
When Lunacia entered the polish phase, its UI moved from separate Photoshop files into a design system in Figma. The old workflow was straightforward: the designer handed off images, the Unity developer rebuilt each screen manually, then connected the code. It worked while the number of screens was small, but became increasingly expensive and could still drift from the design.
I began testing another approach: using AI to connect Figma to Unity. The idea sounds simple - let AI read the design, connect Unity MCP, and ask it to build - but that naive version quickly increases Figma-reading costs, revision loops, and token usage. I therefore split the problem into smaller flows, each with its own plugin or helper and a clear gate between stages.
The first MVP had three parts
1. Read the Figma archive once and cache it
Figma’s archive JSON has a structure that works well for tracing nodes, components, and design properties. I could not afford to let AI call Figma MCP and reread the entire document for every task. The new workflow reads the archive once, stores it locally, and reuses it across later tasks.
Figma remains where the designer works and remains the source of truth. The cache only helps AI query it more efficiently; it is not allowed to become a separate version of the design.
2. Map Figma elements to Unity prefabs
Each important Figma element maps to its corresponding Unity prefab. The mapping tells AI which components already exist, which are still missing, and prevents it from rebuilding something the team has already made.
The most important rule is simple: when AI encounters an element, it must trace the parent component all the way to the root, then implement shared components first. If it only sees an entire popup or screen through vision, it can easily decide the UI does not exist and reinvent the wheel.
3. Connect Unity MCP and let AI work inside a locked scope
Only after the archive, mapping, and component tree are clear is AI allowed to work in Unity. The task is no longer “build a popup that looks like this image.” It becomes a specific sequence: which prefab to use, where the source metrics live, which files may change, and which gates must pass before completion.
Example: splitting an NPC Shop module
An NPC Shop module in the game is separated into three layers:
- Screens are the entry points for the feature. Because the Shop opens as a popup, Screens mainly keeps the root prefab and the frame where the other parts connect.
- Popups are supporting panels and tooltips in the flow, such as item details, sale confirmation, cart, and sale-success messages.
- Atoms are the smallest reusable units, including item cards, buttons, price rows, icons, and individual control states.
AI does not build the whole screen as one block. It traces from the screen to the popup and then to each atom, checks existing Unity components, and creates only what is missing. When this structure is preserved, the Unity output remains a set of small prefabs instead of one huge UI tree that is difficult to maintain.
If the designer has completed the full UI and kept naming and components clean, I estimate AI could cut the rough interface for the whole game in approximately one week. Developers could then focus mainly on controllers, data binding, and logic instead of rebuilding each screen by hand.
That is the happy path. My current project does not have every design ready to process in one run. We work with what is available: when a feature arrives, I review its design, add or redesign whatever is missing, then run the pipeline and begin implementing controllers. The one-week figure is an estimate of the workflow’s capacity with complete input, not a milestone Lunacia has already reached.
The first runs got many things wrong
To be direct, my first runs were messy. The problem was not that AI could not build UI. My goals and gates were too loose, leaving too much room for it to choose its own solution.
Image diff cannot be the source of truth
Initially, I rendered the Unity UI, overlaid it on the Figma image, and calculated the difference. The gate was loose, sometimes accepting 1-5% or even 10% difference. AI repeatedly adjusted unit values to reduce the diff while the internal structure and design values began drifting.
I later changed the order: read the correct Figma metrics first, implement from those metrics, then use image diff only as a verification gate. For regions that must match, tolerance is tightened into the 0.00x% range. A small diff is no longer permission to alter source values; responsiveness, localization, and runtime state remain separate gates.
Components must be traced before using vision
Without mandatory component tracing, AI often sees a UI region and guesses how to build it. The same button, progress bar, or card can gain another implementation simply because AI does not know where the existing prefab lives.
I added rules requiring it to find the main component, variants, and nested dependencies first. A task may create a new component only when the mapping genuinely does not exist.
TMP padding and unit systems need explicit rules
Figma and Unity do not measure text in the same way. TextMesh Pro also has its own padding, font metrics, and preferred-size calculations. Without a clear contract, AI can fall into a loop adjusting font size, RectTransform, and padding just to force the text to match a reference image.
The current workflow separates typography metrics, cell layout, and overflow policy into distinct contracts. Text cannot be aligned by trying random numbers until the image looks close enough.
Responsiveness and localization are requirements from the beginning
The game supports both English and Vietnamese, so a screen that works for one short English sentence is not complete. Every text field needs a known data source, wrap or ellipsis behavior, width constraints, and a policy for the longest expected string.
These rules go into the specification before AI begins, avoiding the discovery at the end of a task that another language breaks the layout.
The MVP worked, then the economics became a problem
After several workflow iterations, a UI task that previously took two to three days could finish in approximately four to eight hours. Tasks with animation still took longer because motion and state required more adjustment, but total effort had fallen substantially.
The remaining problem was token usage. With the original naive approach, one popup could consume the equivalent of 120-140% of one Codex Plus account’s weekly usage. Based on how I converted the cost at the time, that was approximately 6-7 USD per task. The workflow was faster than manual implementation, but it could not scale comfortably at that burn rate.
The bottleneck was querying the archive
Whenever AI checked a detail, it reopened a heavy structural JSON file and searched through nodes again. Some calls had approximately 98% cached tokens, but the total context being processed was still too large. Caching the archive solved repeated Figma access; it did not stop AI from scanning a large file over and over.
I built a query-helper library between AI and the archive. Instead of giving AI the full file and asking “where is this background?”, it calls a focused query by node, semantic name, or component relationship. The helper searches the data and returns only the structure needed for the next decision.
The value is not only a shorter output. The query helper also creates a consistent access path: the same kind of question returns the same data shape instead of making AI explore the archive differently every time.
After optimizing the query layer
For the same type of task, usage dropped from approximately 120-140% to 40-70% of weekly usage in my measurements; the converted cost fell to approximately 2-4 USD. When the specification is prepared well, the remaining usage can cover server mapping and runtime states as well, not only a static UI frame without data.
This is the point where I consider the workflow usable for production: the output follows the source design, uses the correct prefabs, supports localization, binds real data, and passes the relevant gates. A screenshot that resembles Figma but has no lifecycle or real state is not complete.
A strict condition: the Figma file must be a real design system
This workflow is effective only when Figma uses clear components, variants, naming, and structure. If the designer draws elements ad hoc, creates components inconsistently, or copies elements without preserving relationships, AI cannot trace them and will rebuild from scratch. Token usage then returns to guessing and correcting.
What I built is not a button that turns Figma into Unity. It is a track made from a source of truth, archive cache, query layer, component mapping, execution boundary, and validation gates. AI moves quickly on that track; the hardest part is designing the track tightly enough that it does not go off course.