Creating an experiment

Register a new study on the Web Console — basic info, world bindings, session limits, consent form. Capture the eID to wire into Unity.

These pages are not yet fully reviewed. The LUIDA team is continuing to review and improve them. If you find anything wrong on these pages, or have questions that aren't resolved by reading them, please ask or report to the LUIDA team.

The Web Console is the registry for your study. Before any Unity scene can collect data, the experiment needs a row in the console: a title, a consent form, a world ID, and the rest of the bookkeeping that ties data downloads back to a real research project. Once registered, the experiment gets an eID (experiment ID), and that's what binds your Unity project to this row going forward.

You only do this once per study. Read once, then refer back when you need a refresher on a specific field.

Where the form lives

After signing in, the header has a green + New Experiment button on the top right. Or visit the route directly:

Path: /experiments/new
From the list: /experiments → + New Experiment

The form has four cards (sections). Most fields are optional; the only hard required ones are Title and the consent form's Contact field. You can save a minimal draft now and come back later to flesh out consent text and questionnaires.

Screenshot pending — the four-card New Experiment form, with the Basic Info card expanded showing title, description, and prerequisites.

Form sections

Below is a tour of the four cards in the order they appear. Each entry tells you what the field maps to in storage (the Prisma model name) and what it controls at runtime.

1. Basic Info

Field	Required	Type	Notes
Status	yes	enum: `TESTING` / `PUBLISHED`	Defaults to `TESTING`. See Status: TESTING vs PUBLISHED below.
Title	yes	string, ≤ 50 chars	Shown on the Recruitment World bulletin board and on the experiment list.
Description	no	string, ≤ 100 chars	One-line summary shown alongside the title.
Prerequisites	no	string, ≤ 300 chars	A short note about who should/shouldn't participate (e.g., "Must be over 18, no history of motion sickness"). Distinct from the consent form's `detailedPrerequisites` — this one is the recruitment-board version.
Reward	no	float ≥ 0	An optional cash/credit reward, shown on the recruitment board. `0` means no reward.
Image URL	no	URL	A thumbnail shown on the recruitment board. Must be a valid `https://` URL — host the image yourself (e.g., GitHub assets, Cloudinary).

The Title is worth a bit of thought — make it specific enough that participants know what they're signing up for. "VR Stroop study (Cluster Lab)" reads better than "Experiment 1".

2. World & Platform

Field	Required	Type	Notes
World ID	no	string	The Cluster world ID where this experiment runs. You get this after uploading the world via CCK. Recruitment uses this to deep-link participants into your world. Optional during the build phase; fill it in once your world is uploaded.
Allowed platforms	yes	multi-select: `VR`, `WINDOWS`, `MACOS`, `ANDROID`, `IOS`	Which devices can join. Defaults to all five. Sessions from disallowed platforms are rejected at the eligibility check.
Participant Avatar	yes	enum: `HIDE` / `DEFAULT` / `UNRESTRICTED`	Controls participant appearance — see below.

The Participant Avatar mode has three settings, each appropriate for different study designs:

HIDE (default) — Force the LUIDA transparent avatar. Participants are invisible to themselves and to each other. Use when your study needs a controlled visual environment with no avatar interference (e.g., perception studies, presence research where you provide custom embodiment via the Unity side).
DEFAULT — Force the standard LUIDA avatar. Every participant looks the same. Use for between-subject studies where avatar variability would confound results.
UNRESTRICTED — Participants keep their own Cluster avatar (UGC allowed). Use for naturalistic social studies where self-expression matters.

If your Unity-side experiment uses AssignAvatarToParticipant to give participants a researcher-supplied avatar, set this dropdown to HIDE — otherwise participants may end up wearing their Cluster avatar and your assigned avatar simultaneously, which looks broken. The form shows an inline warning when DEFAULT or UNRESTRICTED is selected for this reason.

For the deeper picture, see Web Console → Platform and avatars.

3. Session Limits

Field	Required	Type	Notes
Room Capacity	no	integer ≥ 1	The Cluster instance's max simultaneous participants. Defaults to `1`. For a single-participant study leave at `1`; for paired studies set to `2`; etc. This is enforced by Cluster (rejected joiners go to a waiting room).
Max Sessions	no	integer ≥ 0	Total sessions allowed across this experiment's lifetime. `0` means unlimited. Once reached, new join attempts are rejected with `eligible: false`.

Use Max Sessions defensively: pilot at 10 while you iron out bugs, bump to 50 for the actual run, set back to 0 if you decide to extend collection. Reaching the cap doesn't disrupt sessions in progress — they finish normally.

For multi-participant studies, also configure pNum on the Unity side (Connect to Web Console → pNum) — that's the minimum required for a session to start, while Room Capacity is the maximum it can hold.

For the full session-balancing story, see Concepts → Conditions, sessions, participants and Web Console → Sessions and balancing.

This is the longest card. It captures the informed-consent text participants see at the start of every session, plus the researcher contact info that goes into the consent record.

Field	Required	Limit	What it covers
Researchers (multiple)	no	—	Free-text list of collaborators and their affiliations. Used for the consent record header. Format is up to you — the form ships with a placeholder example like `Name / Affiliation`.
Consent Form Content	yes	≤ 1000 chars	The full consent text the participant agrees to. Defaults to a Japanese-language template covering the standard clauses; rewrite for your study.
Research Purpose	yes	≤ 300 chars	One paragraph: what is this study trying to find out?
Research Method	yes	≤ 1000 chars	What participants will actually do — task description, duration, any equipment they'll wear or use.
Detailed Prerequisites	no	≤ 300 chars	Specific exclusion criteria: medical conditions, age limits, prior experience requirements.
Voluntary Participation & Right to Withdraw	no	≤ 400 chars	Statement that participation is voluntary and the participant can stop at any time without penalty. The form pre-fills boilerplate; tailor for your IRB's wording.
Protection of Personal Information	no	≤ 200 chars	How you'll keep identifying info safe.
Publication of Research Findings	no	≤ 200 chars	Where results may be published.
Benefits and Risks	no	≤ 500 chars	Direct/indirect benefits to the participant or to research; risks (motion sickness, fatigue, etc.) and mitigations.
Information Handling Policy	no	≤ 300 chars	Retention period, anonymization, what happens to data after the study.
Others	no	≤ 200 chars	Catch-all for ethics-board approval numbers, funding statements, etc.
Contact	yes	≤ 200 chars	Researcher contact info — usually email, sometimes phone or institutional address.

The form pre-fills several of these with Japanese-language templates that match common university IRB wording in Japan. Replace these with your own institution's required language before publishing. The defaults are starting points, not legally compliant text.

All consent fields are stored in the ConsentForm model with a 1:1 link to the Experiment. They're versioned together with the experiment — editing the consent form after sessions have run does not retroactively change what previous participants agreed to.

Status: TESTING vs PUBLISHED

The Status dropdown is one of the form's more important fields:

TESTING (default) — The experiment is hidden from the public Recruitment World. You can run sessions yourself (e.g., from CSEmulator or a private Cluster test space), and data is collected normally, but participants browsing the bulletin board don't see it. Use this for the entire build/iteration phase.
PUBLISHED — The experiment appears on the Recruitment World bulletin board, ranked by getSortedExperiments. Participants can browse to it, accept consent, and join. This is the "go live" switch.

Practical workflow:

Create the experiment with TESTING. Iterate on the Unity scene; run pilot sessions from CSEmulator or a Cluster test space (with isTestMode=true on the Unity side). Data flows but stays segregated from the production analytics view.
When the experiment is ready for real participants, edit and flip Status to PUBLISHED. Also flip isTestMode to false in Unity — see Connect to Web Console → isTestMode — and re-upload the world. The two flags are independent: TESTING here gates Recruitment World visibility, while isTestMode over there gates whether data is tagged as test or production.
After data collection finishes, you can flip back to TESTING to remove the listing, but data stays collected.

A common LUIDA mistake is publishing an experiment whose Unity side is still in test mode. Result: real participants run the study, but their data is silently tagged as test data and excluded from analyses. Add a checklist item: "Flipped both Status to PUBLISHED and isTestMode to false?"

Saving and the eID handoff

When you click Create at the bottom of the form, the Web Console:

Validates all fields (Zod schema, with translated error messages).
Creates the Experiment row and the linked ConsentForm row.
Generates a fresh eID — a 24-character MongoDB ObjectId.
Redirects you to the experiment detail page at /experiments/<eID>.

On the detail page, the Experiment ID appears at the top, with a copy-to-clipboard icon. This is what you paste into Unity.

Screenshot pending — the experiment detail page with the Experiment ID label, copy button, and the Verify token field on the right.

The next step is wiring this eID into your Unity project: LUIDA › Configure experiment identifiers, then paste into the expID field. Full walk-through at Connect to your Web Console experiment.

What's not on this form (but you'll need it)

The New Experiment form is intentionally minimal. Several of the things you'll configure for a real study live elsewhere on the experiment detail page (or aren't web-console fields at all):

Verify token — generated in Unity, pasted into the experiment detail page (right-hand panel). See Connect to Web Console → token.
Questionnaires — added per-experiment after creation, on the detail page. See Concepts → Questionnaires for the binding model and Web Console → Questionnaires for the UI walk-through.
Avatars (per-world VRM uploads) — added under the avatar tab on the detail page if you're using the deprecated per-world avatar set. Most experiments don't need this; see Web Console → Avatars.
Excluded sessions / participants — entered later as you discover unusable runs. See Web Console → Sessions and balancing.
Data downloads — questionnaire answers, participant info, and custom logs all available from the detail page once data accumulates. See Web Console → Downloading data.

You can edit any field on this form later via the same detail page. The only one that's effectively immutable is the eID itself (it's the primary key).

Validation cheatsheet

The form uses Zod with translated error messages. The non-obvious limits:

Title must be 1–50 characters.
Description ≤ 100 characters; Prerequisites ≤ 300.
Reward must be ≥ 0; you can use decimals (e.g., 5.50).
Image URL must be a valid http(s):// URL or empty.
Room Capacity must be an integer ≥ 1.
Max Sessions must be an integer ≥ 0 (0 = unlimited).
Allowed Platforms must have at least one selection.
Consent Form Contact is required; Consent Form Content ≤ 1000 characters.
Per-section consent text fields each have their own caps (300, 400, 500, 1000 — see the table above).

If validation fails, the form shows red error text under each offending field plus a red banner above the submit button.

Common pitfalls

Copy-pasted World ID with whitespace. Cluster world IDs are short alphanumeric strings; trailing spaces from copy-paste break the recruitment deep-link. Trim before pasting.
Image URL pointing at a local file. file:///... and relative paths fail validation. Host the image somewhere public.
Default Japanese consent text shipped to an English-speaking IRB. The form's pre-filled boilerplate is in Japanese. Replace before publishing if your study is for non-Japanese-speaking participants.
Setting Status to PUBLISHED before the world is uploaded. Participants will get a broken Recruitment World link. Upload the world first, paste the World ID, then publish.

Where to go next

Connect to your Web Console experiment — paste the eID into Unity and generate the verify token.
Concepts → Questionnaires — how qID binding works between the Web Console and Unity.
Web Console → Sessions and balancing — manage maxSessionCount and exclude bad sessions.
Tutorial 0 — Hello LUIDA — full end-to-end smoke test using the experiment you just created.

Creating an experiment

On this page