RitzDeli Games · Client Project for Meta — Newton’s Playground

Building a creator ecosystem in VR

Client: Meta · client work delivered through RitzDeli Games
My role: UX/UI Design · VR UX · Creator Tools · Systems Design
Collaboration: PM · Engineering · Art · Production
My focus: UX Flows · Interaction Design · Information Architecture · UI Systems · Prototyping
Discipline: VR UX · Creator Tools · Engagement Systems · Systems Design

Client project for Meta through RitzDeli Games. Product goals and requirements for creator tools, progression, and economy came from PM documents and team discussions, which I translated into UX flows, interaction models, prototypes, and production UI.

Newton’s Playground key art titled Building a Creator Ecosystem in VR, showing a VR rooftop scene with a Buy Apples panel selected by a controller laser

The challenge

Newton's Playground is a physics VR sandbox full of objects, characters, vehicles, and builds other players made. All that freedom meant players often didn't know what to do next — and as more content shipped, the library got harder to browse and there was no clear path from building something to sharing it.

Product goal: Add progression, an economy, and creator publishing to an open-ended sandbox.
My design goal: Make those systems point players toward what already makes the sandbox fun, instead of sitting on top of it as separate menus.

What I did

I put Daily Tasks on the player's wrist, so goals are always there without taking up space in the world or interrupting play.
I mixed the task difficulty on purpose — quick wins to get people started, bigger goals to keep sessions going, and varied types to push players into parts of the sandbox they usually skip.
We tied gameplay to the economy by paying out Golden Apples for tasks. I designed earning and buying into one screen instead of splitting them into a separate store.
I rebuilt Spawn Gun navigation with persistent category icons, secondary tabs, and one reusable item card that handles owned, locked, new, selected, buyable, and favorite states.
I designed everything for point-and-select: big targets, room between them, high-contrast selection, and a controller laser that connects your hand to what you're picking.
I went through the two screens players hit most — the tool wheel and the community build browser — and rebuilt each one to be readable at a distance, obvious about its current state, and able to handle more content later.

How the work moved

PM goals & requirements
UX analysis
User flows
Design exploration
UI system & visual design
Engineering & art handoff

01 · Challenge

Turning an Open Sandbox Into a Repeatable Experience

The game gave players a lot of freedom, which is the point of a sandbox — but it also meant a lot of people opened it and didn't know what to do.

As more objects, tools, characters, weapons, and creator features shipped, several problems piled up at once. My direction was to connect these systems into one loop players could actually follow.

Goals: players needed clearer direction without losing sandbox freedom
Discovery: large content libraries needed organization and browsable states
Creation: building → saving → publishing → sharing had to be one path
Cohesion: progression and monetization had to feel connected to gameplay
VR legibility: every interface had to stay readable and easy to target

02 · System

Daily Tasks and Golden Apples as One Engagement Loop

Daily Tasks live on the player's wrist, so goals are there when you want them without sitting in the world or interrupting play. They come from a reusable pool — drop the weight, grab the cubes, rotate the gear, break the wall, find a new area — and each one shows its progress and Golden Apple reward right there.

Tasks pay out Golden Apples, which ties playing directly to what you can unlock. Instead of a separate store, I put earning and buying on one screen, side by side.

Wrist menu → Task progress → Reward → Daily reset

Wrist menu — objectives are summoned by the player instead of pinned to the world.
Reset and rewards — the panel states what refreshes and what the currency is for.
Earn and buy in one panel — the free path is never hidden behind the paid one.

03 · Key Design Decisions

Content Discovery, Tool Clarity, and Point-and-Select Input

As more spawnable content shipped, the Spawn Gun had to hold a lot more categories without burying the player. I built a structure that grows: persistent category icons on the left, secondary tabs, and one reusable item card that works for NPCs, weapons, wearables, objects, vehicles, and saved builds.

Since you point instead of clicking, I used big targets, plenty of space between them, and selection feedback you can't miss. A controller laser keeps the link between your hand and what you're pointing at obvious.

The sandbox also has several specialized tools — Joint, Connection, Modify, Size, Physics, and Spawn Guns — that were genuinely hard to tell apart mid-play.

Persistent categories: the left rail never moves as the library grows
Reusable cards: one card handles every content type and state
Saved builds inline: player creations sit alongside first-party content

Point → Highlight → Confirm

Tool selection — silhouette and color carry recognition before the label is read.

04 · Creator Loop

From Private Build to Community Content

Players build their own creations out of physics objects, so saving had to be a real step, not an afterthought. The flow goes from building, to saving, to naming, to spawning it again later from the Spawn Gun.

Saving is only the start, so I designed publishing as a visible path from private build to public content. Build Details shows likes, downloads, part count, and published status before anything goes out.

The Community browser turns other players' builds into a steady supply of things to do. It's split into My Builds, Community, and Downloaded, with Newest, Top Rated, Trending, and My Uploads filters inside Community.

Create → Save → Name → Respawn from Spawn Gun

Naming — the preview stays present so the asset and the creation stay connected.
My Builds — part count, date, and upload status live on the card itself.
Every step is its own screen — nothing about publishing happens invisibly.
Community — the same card structure, now credited to other players.

05 · Before vs After

Auditing the Two Screens Players Used Most

Two screens carried almost all the repeat traffic: the tool wheel players opened dozens of times a session, and the build browser they used to find something to play with. Both worked. Both were also costing players time for reasons that had nothing to do with the features themselves.

I went through each one asking the same three questions: can you read this from a normal VR distance, can you tell what state you're in, and will this layout still hold when we add more content? The redesigns below are the answers, and every change points back to something specific that was wrong.

01Tool selection
Before
Before — six transparent rings on top of live geometry, with no equipped state and labels at uneven distances.
After
After — contained targets, a symmetrical grid, and colour-coded silhouettes readable at a glance.
What was breaking
The old tool wheel drew six thin grey rings straight onto the live physics scene. With ragdolls and furniture behind it, the UI had no surface of its own — the tools sat on top of whatever you were looking at and read as scene clutter, not controls. Labels floated in white chips at uneven distances, so you had to re-match each name to each tool. Nothing showed which gun was equipped. And the usage hint ran across the middle of the world in italic cyan, competing with the options it was explaining.
What the redesign does
I gave every option its own contained, evenly spaced target and let the tool's silhouette and color do the work — so once you know the tools, you stop reading labels. Labels sit at one fixed offset under each icon, the grid is symmetrical so muscle memory can form around position, and the instruction line drops to a footnote instead of floating over the scene.
Contained targets
each tool sits on its own surface instead of over live geometry
Color as identity
tool silhouette and color carry recognition before the label is read
Fixed label pairing
one offset for every option removes the re-pairing cost
Positional memory
a symmetrical grid keeps each tool in the same place every time
Demoted instruction
the control hint reads as a footnote, not a competing element
02Build browser
Before
Before — three competing button treatments, illegible attribution, and a library split across pages.
After
After — one active treatment per level, a scrolling grid, and status carried on the card.
What was breaking
The old browser used three different button styles in one row: low-contrast grey plates for the tabs, a mix of bare text and filled chips for the sort filters, and one blue fill as the only active state. You couldn't tell what was clickable, and you couldn't tell how the list was sorted. The content had problems too — thumbnails were small next to their padding, creator names squashed into unreadable strings, and every card looked the same whether it was published, private, or still loading. Worst of all, the library was paginated behind a Page 1 / 2 control, so browsing meant a round trip instead of a scroll.
What the redesign does
I split it into two clear levels — three full-width tabs above one row of sort pills — with exactly one active treatment per level. I replaced pagination with a scrolling grid, so the view grows with the library instead of chopping it up. And I added a status layer to the cards: a green Uploaded badge, a cyan selection frame, creator name with likes and downloads, and a real loading state. Now you can read a build's standing without opening it.
Two clear levels
destination tabs above sort pills, each with one active treatment
Scroll over pages
one scrolling grid grows with the library, no round trips
Status on the card
uploaded, selected, and loading states are visible before opening
Legible attribution
creator, likes, and downloads sit in a fixed row on every card
Bigger thumbnails
the build itself becomes the primary identifier, not the title

06 · Design System

One Visual Language Across the Experience

A big part of the work was getting systems with very different jobs to behave the same way. Shared surfaces, selection colors, action colors, and reward cues make Daily Tasks, the economy, Spawn Gun content, creator tools, and community publishing feel like one game instead of five features.

Surfaces: dark blue panels with card-based information hierarchy
Selection: bright blue selected states and cyan VR interaction highlights
Actions: green for purchase and confirmation, red reserved for destructive steps
Rewards: the Golden Apple as a single, consistent value cue
States: shared loading, confirmation, selected, locked, and success patterns

07 · Outcome

A Connected Player and Creator Loop

The final concept links systems that used to sit apart, using progression to push players toward more of what already makes the sandbox fun instead of stacking structure on top of it.

Players get a reason to come back, a way to find content, a path from building to publishing, and an economy that pays out for playing — without losing the open-ended feel that makes the game work.

Complete Tasks → Earn Apples → Unlock Content → Publish Builds → Discover Community Builds → Create More

The loop as designed — every system hands off to the next one.