Giving world creators the option to disable flight in their world can be useful for certain gameplay experiences. However, relying primarily on a global disable tag creates an architectural incentive that may unintentionally encourage restrictive world design.

When the easiest solution available to world creators is a global toggle that disables avatar mechanics, many worlds will naturally default to using it rather than designing systems that work alongside avatar capabilities. Over time this can encourage a pattern where mechanics like flight, vertical movement, lighting utilities, and other avatar side tools are simply blocked instead of being integrated into world design.

VRChat is a platform built around expressive avatars and user generated worlds. Historically it has succeeded because creators and users have a high degree of freedom in how they build experiences together. Avatar capabilities are an important part of that ecosystem.

Many communities rely on mechanics like flight for legitimate purposes such as:

• filming and cinematic capture

• assisting other players

• accessibility or mobility needs

• immersive avatar identities (birds, dragons, flying species)

• creative social experiences

• event hosting and moderation

These uses are not edge cases; they are part of how the platform’s social ecosystem functions.

Gameplay-focused worlds should absolutely have the tools needed to protect their mechanics; the goal is to provide flexible systems that allow those protections without requiring avatar capabilities to be broadly disabled.

The architectural challenge is that a simple global toggle solves an immediate gameplay problem for a world, but it does so by disabling capability from avatars rather than allowing creators to manage it contextually.

Feature Suggestion

Consider expanding world creator tools so that avatar mechanics like flight can be managed through contextual world rules rather than primarily through a global disable tag.

One useful addition would be a platform-level spectator mode for instances that world creators can leverage through the SDK. This would allow worlds to shift users into spectator mode when appropriate while preserving avatar capabilities.

For example, the platform could provide Unity-accessible systems that allow world creators to:

• detect avatar states such as flight or large vertical displacement

• disable gameplay progression or scoring while flight is active

• allow users to manually enter spectator mode

• automatically shift flying users into spectator mode when appropriate

• optionally hide spectators in flight from active players or gameplay systems

• prevent flying avatars from entering specific gameplay zones

• provide triggers that allow creators to define custom interaction rules between avatar mechanics and gameplay objectives

Instance hosts or moderator roles could also be given optional controls to enable or disable certain mechanics (such as flight or spectator mode) for their instance. This would provide session-level flexibility without requiring world creators to globally disable avatar capabilities.

These types of tools would allow creators to protect gameplay mechanics while still preserving avatar expression and supporting diverse avatar designs.

Design Consideration

In a platform centered around user generated worlds, capability control tends to work best when it follows a layered model:

• Avatar layer - defines what an avatar is capable of

• World layer - defines how those capabilities interact with the world

• Instance layer - manages behavior within a live session

Providing richer world level interaction tools for avatar mechanics would help maintain this balance while supporting both gameplay focused worlds and social experiences.