01
3D edits meant a full round-trip
One wrong texture meant a re-export from Blender, re-review, re-deploy — reprinting a book to fix one typo. Fine at a few assets a week. Brutal at dozens a sprint.
RT Studio — Scaling Game Development
Scaled RT Studio from a 0 to 1 pilot into the platform that now powers 12 active game studios, the backbone of the Terra games ecosystem.
200+
Games shipped
External studios shipping games on TERRA
62→78%
↑ +26% task completion
V1 → V2
23→8%
↓ −65% wrong panel clicks
Strongest IA signal
RT Studio was TERRA's native game-dev platform for Mac and Windows, where studios built, iterated, and shipped games to the Terra Platform. It bundled a 150k-asset catalog, 100+ no-code logic templates, prefabs, over-the-air deploy, version-controlled collaboration, and GenAI tooling for textures and code.
Note RT Studio ran as a private beta with 12 studios before TERRA pivoted to Flow, a Unity copilot chasing a different problem. What follows is the redesign that came before the pivot.
The Mandate
The business wanted to retain more players. That meant deeper games at higher fidelity.
Business requirement
Grow players on TERRA.
Growth runs through the studios: deeper games, longer retention.
Studio goal
Find where RT Studio caps what studios can ship. Then remove the cap.
Context
I joined as the product designer, co-owning V2’s direction with engineering and PM. Every pillar had to be negotiated through the people who controlled whether it could ship.
- Engineering owned the runtime and deployment. PM owned roadmap and studio relationships.
- V1 already worked: studios built whole games in it — drop-in assets, code-free logic, in-engine playtest, over-the-air publish.
- One bet sat at the center: a Basic/Advanced mode toggle, built on the hunch that beginners needed a simpler interface. The hypothesis we’d soon disprove.
- 01 A diverse asset library — 150k assets built in-house to cater to different games
- 02 Play · Publish — Test in-engine, then publish over-the-air to the Terra platform
- 03 Mode toggle — Basic vs Advanced, the simplified mode we later disproved
- 04 Logic templates — Pre-built behaviors like 'Collectable'. Drop-in properties, no code
- 05 Inspector — Per-object properties: sound, VFX, score, broadcast
How studios shipped on RT Studio
Start with an idea
A runner, a shooter, an obstacle course. No engine setup, no boilerplate.
Build the environment
Compose scenes from 150k drop-in 3D models, SFX, VFX, and UI components.
Add the logic
Attach templates to any object — collectables, spawners, win states. ECS underneath, no code.
Iterate & ship
Playtest in-engine, tune, publish over-the-air. No app-store review cycle.
Basic mode was a bottleneck for the team
Initial hypothesis
Beginners would drown in a full game-engine interface. A simplified Basic Mode would cut friction and grow the funnel.
~10%
of all sessions used Basic Mode
Two teams kept a second system alive that almost nobody used. Not value. Debt.
High Effort Low
Basic Mode
Low Impact High
Research: Where was V1 hitting its ceiling?
Four ceilings, one per layer — assets, catalog, logic, collaboration. None were bugs. Each was right for V1’s scope. The new ambition outgrew them all.
02
The library couldn't keep up
150k assets, built in-house for simpler games. Higher-fidelity titles outgrew the catalog, and we couldn't model fast enough to close the gap.
03
Templates couldn't carry depth
Templates are Lego: quick for a house, hopeless for a detailed spaceship. Pickups and doors worked. Multiplayer sync, AI, and physics needed real code.
04
Teamwork broke at scale
One shared scene, passed around like a single USB stick. Two editors meant a silent overwrite and a lost day. Fine for a trio, not for parallel teams.
V2: Four Pillars on One Foundation
V2 asked a different question: what made the platform rigid, and what would it take to bend? Four pillars, each a system built around how studios actually worked.
Material Template
3d → 1d
Average iteration cycle per asset
- Before
- One wrong texture restarted the pipeline: re-export, re-review, re-deploy.
- After
- Retexture, recolor, and tune materials on the placed asset — in-Studio.
- Impact
- The most-cited V2 improvement in follow-ups.
Asset Upload
A pipeline that brings studios' own assets into the TERRA catalog as first-class, searchable, placeable items.
- Before
- Studios were locked to TERRA's catalog. Their own finished work had no way in.
- After
- Uploads sit beside TERRA's assets — same metadata, same search, same placement.
- Impact
- The catalog grew without us owning 3D production — and killed the in-house modeler we'd nearly built.
V2 · Asset Upload · Approval queue
T#: Open Logic
A C# wrapper with hot reload. Studios write and run their own game logic — no template request, no waiting on TERRA.
- Before
- Any behavior we hadn't shipped meant waiting on us — engineering hand-forking near-identical templates per game, per studio.
- After
- Studios write logic in T# and watch it update live. Hot reload ships it over the air.
- Impact
- The maintenance backlog stopped growing. Studios took their own logic roadmap back.
JAM: Collaboration
Git-style sync for shared scenes: push/pull, per-object conflict resolution, scene locking.
- Before
- Two people in one scene meant a silent overwrite and a lost day — held together by "are you in the lighting file?" Slack threads.
- After
- The runtime ruled out real-time, so JAM borrowed from Git, not Figma: work local, pull before push, resolve per-object, lock for exclusive edit.
- Impact
- Default in every active studio with no announcement, no mandate. The workaround stack went quiet.
V2 · JAM conflict resolution
The Load-Bearing Wall
~40
Components, variant-complete across 4 surfaces
- Before
- No design system. Every panel looked designed in isolation, spacing and type drifting surface to surface.
- After
- Semantic tokens, 4 type scales, a documented library — version-controlled before any pillar code shipped.
- Impact
- Four pillars shipped in parallel without the interface fracturing. Not a feature, so not a pillar — the wall the other four rest on.
Did the redesign hold up?
A redesign is easy to ship and hard to prove. So I checked three things:
- What got built on V2.
- What the numbers moved.
- What the people using it daily actually said.
200+
Games shipped
Built on TERRA after V2 — from quick experiments to full productions.
Wrong-panel error rate Most trusted
−65%
23% → 8%
A spatial signal — users built the right mental model. The new IA worked.
Iteration cycle
−67%
3 days → 1 day
Material fixes land in place instead of round-tripping through a re-export.
Task completion rate
+26%
62% → 78%
Same tasks, same studios — measured before and after V2.
What users had to say
Our own packs sit right next to TERRA's, like they were always there.
3D artist, internal studio A wrong texture used to cost three re-dos. Now I fix it in place and move on.
Environment artist, internal team Behaviors we waited weeks for, we now write in T# and hot-reload the same day.
Developer, internal team Rebuilt our inventory in V2 fast — far more usable than before.
Developer, internal team The Platform Outgrew the Studio
TERRA pivoted to AI-built games. RT Studio’s architecture couldn’t run them, so the studio was shut down and the team moved to Flow, a Unity copilot. New question, and a commercial one: what could we build that made money?
The artifacts didn’t carry over. The methods did.
Three threads on Flow.
01 Pipeline audit
Mapping the production pipeline
Figma → Unity was the worst bottleneck: devs rebuilt every handed-off layout by hand. UI Builder closed that gap.
02 Persona demos
Building demo artifacts
One demo per persona. Not a feature tour — their pain, fixed, on screen.
03 Landing + analytics
Shipping the landing page
Designed, built, and shipped it myself, then wired the analytics to see what people did once they landed.
Cold outreach qualified two clients before Flow wound down in late 2025.
Reflections
The principle I design by now
Put the user first, inside what the business and the engine can actually carry. A design that ignores either constraint never ships — and one that only serves them isn't design.
What worked
Killing the right things early: the 3D modeler, Basic Mode, the templates strategy. Research pays most when it stops you building the wrong thing.
Designing inside the constraint
Anyone can design real-time collaboration when the runtime supports it. Designing it for a runtime that doesn't, in a quarter, is the harder test. JAM wasn't fashionable. It worked.