01
3D edits meant a full round-trip
Fix one texture and you re-exported from Blender, re-reviewed, re-deployed: reprinting a whole book to fix one typo. Fine at a few assets a week, brutal at dozens a sprint.
TERRA · 2024 – Q1 2025 Lead Product Designer
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.
TL;DR
RT Studio was TERRA’s native game-development platform for Mac and Windows, the surface where studios built, iterated, and shipped games to the Terra Platform. The platform bundled a curated catalog of 3D models, SFX, VFX, and UI components, 100+ logic templates, a prefab system, over-the-air deployment (no app-store updates), version-controlled collaboration, and GenAI tooling: a procedural texture generator and a T# code generator.
200+
Games shipped
External studios shipping games on TERRA
62→78%
↑ +26% task completion
V1 → V2, HEART study n=15+
23→8%
↓ −65% error rate
Wrong-panel clicks, strongest IA signal
RT Studio scoped to a private beta with 12 studios before TERRA pivoted to Flow, a Unity copilot solving a different problem (game-dev velocity and deployment reach). The work below is the platform redesign that came before the pivot.
01
The Mandate
The business wanted to retain more players on the games platform, which meant deeper games at higher fidelity.
Business requirement
Grow players on TERRA.
Growth runs through the studios: deeper games, higher fidelity, longer retention.
Studio goal
Lift the fidelity and depth ceiling. Find where RT Studio caps what studios can ship. Then remove it.
02
Context
I joined as lead designer, co-owning V2’s direction with engineering and PM. Engineering owned the runtime and deployment; PM owned roadmap and studio relationships. Every pillar in V2 had to be negotiated through the people who controlled whether it could ship.
V1 was already a working product: studios built whole games inside it — drop-in assets, code-free logic templates, playtest in-engine, publish over-the-air. But one bet sat at the center of the layout — 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 — RT Studio starts at the concept.
Build the environment
Compose one or more scenes from the curated catalog — 150k drop-in 3D models, SFX, VFX, and UI components.
Add the logic
Attach logic templates to any object — collectables, spawners, win states. Entity-Component-System underneath, no code required.
Iterate & ship
Playtest in-engine, tune, then publish over-the-air to the Terra platform. No app-store review cycle.
03
Basic mode was a bottleneck for the team
Initial hypothesis
Beginners would be overwhelmed by a full game-engine interface. A simplified Basic Mode would reduce friction and grow the top of the funnel.
Before touching a single panel, we took a glance at the usage data.
~10%
of all sessions used Basic Mode
Design and Engineering had to keep a second system alive that almost no one used. That's not value, it's debt.
Impact × Effort
High Effort Low
Basic Mode
Low Impact High
04
Research: Where was V1 hitting its ceiling?
We found four ceilings, one in each layer of the platform — assets, catalog, logic, collaboration. None were bugs. Each was the right call for V1’s smaller scope. The new ambition just outgrew them all.
02
The library couldn't keep up
150k assets, built in-house for simpler games. Bigger, higher-fidelity titles outgrew the catalog, and we couldn't model fast enough to fill the gap.
03
Templates couldn't carry depth
Drop-in templates are Lego: quick to snap a house together, 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 people editing meant a silent overwrite and a lost day. Fine for a trio, not for parallel teams.
05
V2: Four Pillars on One Foundation
V2 answered a different question: what made the platform rigid, and what would it take to make it flexible? Four pillars each representing a system architected to how studios actually worked.
04 · Signature 01
/ 05
Material Template
3d → 1d
Average iteration cycle per asset
- Before: a wrong texture or off-tone color on a placed asset meant a re-export from Blender, a re-review, a re-deploy. The whole pipeline restarted.
- After: artists retexture, recolor, and tune material properties on the placed asset in-Studio.
- Impact: the most-cited improvement in V2 follow-ups. This also heavily complemented users uploading assets. Scroll to know more
04 · Pillar 2 02
/ 05
Asset Upload
A pipeline that let studios' bring their own assets into the TERRA catalog as first-class, searchable, placeable items.
- Before: studios were locked to TERRA's catalog. Finished work from their own pipelines had no way in, and we'd nearly answered that by scoping an in-house 3D modeler.
- After: a studio uploads its own asset and it sits alongside TERRA's with the same metadata, search, and placement flow. No second-class citizenship.
- Impact: the catalog grew without the platform ever owning 3D production completely.
V2 · Asset Upload · Approval queue
04 · Pillar 3 03
/ 05
T#: Open Logic
A C# wrapper with hot reload that lets studios write and run their own game logic on the platform, with no template request and no waiting on TERRA.
- Before: a behavior the platform didn't ship meant waiting on us, with engineering hand-forking near-identical templates per game, per studio, per release.
- After: studios write logic in T# and watch it update live; hot reload ships it over the air, with no app-store roundtrip.
- Impact: the platform stopped trying to own every behavior, the maintenance backlog stopped growing, and studios took control of their own logic roadmap.
04 · Pillar 4 04
/ 05
JAM: Collaboration
Push/pull collaboration with per-object conflict resolution and scene locking: Git-style sync for multiple people editing the same scene.
- Before: two people in one scene meant a silent overwrite and a lost day of work, held together by file-sharing and "are you in the lighting file?" Slack threads.
- After: real-time was off the table, so JAM borrowed from Git, not Figma: work locally, pull before you push, resolve conflicts per-object, and lock a scene when you need exclusive edit.
- Impact: adopted as the default across every active studio without a single announcement or mandate. The workaround stack just went quiet.
V2 · JAM conflict resolution
Foundation 05
/ 05
The Load-Bearing Wall
~40
Components, variant-complete across 4 surfaces
- Before: V1 had no design system. Every panel looked designed in isolation; spacing and type drifted surface to surface.
- After: semantic color tokens, 4 type scales, and a documented component library, version-controlled before any pillar code shipped.
- Impact: four pillars shipped in parallel without the interface fracturing. Not a user-facing feature, which is why I don't count it as a pillar. It's the wall the other four rest on.
07
The Platform Outgrew the Studio
TERRA was pivoting toward AI-built games and experiences — and RT Studio’s architecture couldn’t run them. So the studio was shut down, and the team moved to Flow, a Unity copilot, carrying the studio learnings with us. The new question was commercial: what could we build that actually generated revenue? What carried over wasn’t the artifacts. It was the methods: the Claude Code prototyping habit that collapsed design-to-test loops, and the research approach I’d refined on RT Studio.
On Flow, I worked across three threads.
01 Pipeline audit
Mapping the production pipeline
Traced the studio workflow looking for the bottleneck worth automating. The Figma → Unity handoff was the worst of them — designers handed off mockups, then devs rebuilt every layout in Unity by hand. That gap is what UI Builder was built to close.
02 Persona demos
Building demo artifacts
Built demos that put Flow in front of each persona and solved the one problem they actually felt. Not a feature tour — their pain, fixed, on screen.
03 Landing + analytics
Shipping the landing page
Designed it, built it, and shipped it myself — then wired up the analytics so we could see who showed up and what they did once they landed.
We ran cold-outreach acquisition and qualified two prospective clients before Flow wound down across September and October 2025 as company priorities shifted.
08
Reflections
The principle I design by now
Rigidity isn't always visible. It hides in the workarounds people build around a platform's hard edges: the Slack threads, the re-exports, the "are you in the file?" rituals. Every pillar of V2 was an answer to a rigidity the platform had imposed. Find the rigidity. Replace it with a system flexible enough to bend without breaking.
What worked
Killing the right things early: the 3D modeler we never built, the Basic Mode we removed, the templates strategy we abandoned before it broke us. Research is most valuable when it stops you from building the wrong thing.
Designing inside the constraint
Anyone can design real-time collaboration when the runtime supports it. Designing the right model for a runtime that didn't, and shipping it in a quarter, is the harder test. JAM wasn't fashionable. It worked.
The workaround is the signal
Professionals don't complain about recurring friction. They build coping infrastructure around it. The "are you in the file?" Slack threads, the manual re-exports, the muscle memory for the wrong panel. The friction you find in tickets is the friction users have learned to articulate. The friction worth fixing is the one they've already stopped reporting.
What I'd do differently
Instrument from day one. The 3-day→1-day Material Template improvement is the metric I trust least, not because I doubt it, but because I can't defend it with a number I built. Qualitative validation is necessary. It isn't sufficient.