Skip to content

Rules & limits

SocialScape runs every creator's world and avatar on shared servers, so the platform is a sealed sandbox with firm boundaries and limits. Designing within these keeps your content from being trimmed or rejected.

What you build — and what you don't touch

Your job is to design your world/avatar and write your own scripts. Nothing in the platform itself needs changing.

  • You edit: your own NexusScript files, and your scene — placing/configuring objects, authoring triggers & logic and interactables, and running the SDK's build & upload tools.
  • You don't modify the platform's own files — the engine, the scripting bindings, the runtime, or the SDK's editor tools. Editing them doesn't help: the platform runs the real validation and server code regardless, SDK updates overwrite local changes, and the sealed API + limits are what keep every world safe to run. If it feels like you need to change a binding to do something, either there's a supported API for it or it's intentionally not allowed.

Compiling & signing in

Compiling your scripts requires a signed-in SocialScape SDK account.

  • It compiles automatically when you save a script, and on demand from NexusVM ▸ Compile Script (Ctrl+Shift+C), Compile Scene Scripts, or Compile All Scripts.
  • You must be signed in to your SocialScape SDK account (authenticate in the SDK Control Panel) — compilation won't work while signed out.
  • Compiling is where errors are reported: an unknown API, a forbidden System.* import, or over-limit code is rejected there.

Enforced limits

These are enforced automatically at build/upload, when content loads, and while scripts run. Over-limit content is trimmed, clamped, or rejected — you can't exceed them.

Performance rating. From these metrics the SDK also computes a performance rating for each avatar and world — Excellent → Medium → Poor (lighter content rates better), with Very Poor meaning it exceeds the limits and is rejected. Click Analyze Performance on the descriptor to see it; in-game it shows on the nameplate badge, and players can cap the ratings they download — so a lighter, better-rated avatar reaches more people. See Avatars ▸ Performance.

Avatars

Allowlisted components only (meshes, Animator, Light, AudioSource, ParticleSystem, colliders, Rigidbody, joints, Cloth, DynamicBone, AvatarDescriptor, and the Avatar Dynamics family — Social Bones, Contacts, Constraints, Grab IK) — no cameras, UI/canvas, custom scripts, video, or networking. Caps: 8 audio sources · 24 clips · 4 lights · 8 particle systems (20,000 particles total) · 64 colliders · 32 spring bones · 160 components (rig transforms don't count) · 1,000 GameObjects · height ≤ 30 m · radius ≤ 30 m from the root (so up to ~60 m wide) · scale 0.2–2.5 · exactly one avatar descriptor. Upload also caps the mesh budget: ≤ 1,000,000 triangles, ≤ 700 bones, ≤ 30 materials, ≤ 2,500 MB textures. Over a count → excess stripped; egregious (audio flood, oversized, missing descriptor) → rejected (shown as a placeholder capsule).

Avatar Dynamics budgets (over → the excess is trimmed on upload): Social Bones — 32 bone chains, 32 bone colliders, 256 total simulated transforms, 512 collision checks/frame; Contacts — 32 components (senders + receivers), 256 local-only, 16 tags each, radius ≤ 3 m; Constraints — 40 (yours + built-ins).

Worlds

Player capacity 1–200. Structural budgets (over → your upload is blocked so you can fix it): ≤ 20,000,000 triangles · ≤ 400 materials · ≤ 8,192 MB textures · ≤ 1,500 rigidbodies · ≤ 10,000 colliders · ≤ 75,000 GameObjects · ≤ 150,000 components. Trimmed automatically (excess is removed at load): ≤ 500 realtime lights (baked lights are free and don't count — bake what you can), ≤ 50 cameras, ≤ 128 particle systems, ≤ 192 audio sources. Custom MonoBehaviours — worlds use NexusScript for logic; a compiled custom component is flagged at build with a one-click Strip Scripts (and removed at load). Allowed alongside the SocialScape components: engine components (renderers, colliders, LODGroup, probes, terrain), world-space UI (Canvas / uGUI / UI Toolkit / TextMeshPro), and URP render data. Networking libraries are banned (Mirror, FishNet, Netcode, UNET). A Speaker's hearing range is clamped to ≤ 50 m at load (so one speaker can't blanket a whole world).

These caps are the world total — including objects your scripts spawn at runtime. Every runtime spawn (NexusScript Instantiate / new GameObject / primitives, world-trigger Spawn actions, NPC world_spawn) is admitted against the same budget, so a script can't flood a world past these limits — a spawn that would exceed a cap is rejected. Players don't count against them.

Worlds are validated at upload and again on both the client and the game server when they load — a world that fails is rejected. At build the SDK also auto-strips shader variants your scene can't use (a world bundle carries its own shaders — URP/Lit alone is 100k+ variants); bake lighting and disable unused fog to keep the build and download smallest (see Worlds ▸ Build & upload).

Scripts

Enforced live while your scripts run. Per script: 1,000,000 instructions/frame · 10 ms/frame · 20 instantiations/s · 500 RPCs/s (burst 200 per 100 ms, and each individual RPC method has that same 500/s ceiling of its own) · 25,000 live object handles · 10,000-element collections (500 of them) · 10 KB strings. Per world (all scripts): 400 active scripts · 2,500 RPCs/s · 120 audio plays/s (one shared bucket for the whole world) · 1,000,000 instructions/frame. Script-spawned objects count against the world's GameObject budget (75,000, above), not a separate limit. These are the same for every world. The per-world 2,500 RPCs/s is a shared bucket, so in a busy world it — not the per-script 50 — is usually what you hit first. You may only Destroy objects your own script created; Physics.gravity and Time.timeScale are read-only; DontDestroyOnLoad is disabled. The per-frame soft budget (the 1,000,000-instruction / 10 ms limits above) does not interrupt a running method — the method it's in runs to completion; a script that keeps overrunning is then throttled so it runs on fewer future frames (roughly 1 frame in 4), never cut off mid-method. A separate hard guard (~10,000,000 instructions per call, or ~2 s of wall-clock) is what actually aborts a call: any side effects it already applied are kept — there's no rollback — and the call is re-run from the top on the next frame. So keep per-frame state changes idempotent (safe to re-apply), or a rare abort-and-retry can double them. Calls over a rate cap quietly no-op. These limits are fixed by the platform — hard-capped in its code, so nothing you ship can raise them.

You can't work around them

Avatars are re-checked when they load on each client, and worlds + scripts are re-checked on both the client and the game server — not just at upload. Editing files locally to dodge a limit has no effect on what actually runs.