Limits and performance

Memory

No cap of NodeWorld's: the module of your world grows as it needs, up to 4 GB, the limit of 32-bit WebAssembly. A Meta Quest has much less memory than a PC: on Quest, Android may close the game when a world takes too much.

Time

  • No budget per frame: your scripts always finish their frame. The frame waits for them: a slow Update lowers the player's frame rate, in VR too. Move heavy work to threads.
  • Each call to the API crosses the boundary between your module and the game. A few hundred a frame do not matter; to move, color or draw thousands of objects, use object batches and drawing by instances, which cross it once.

The watchdog

A call from the game into your scripts (Update, an event, a coroutine step) in which your code runs for more than 10 seconds, or 60 seconds while the world loads, is stopped, with every thread of the world; the time the game spends on its own work during the call (a load, drawing, a slow disk) does not count. The world stays shown without its scripts, and the player sees This world's scripts were stuck for 10 s: they are stopped. Your own threads are not watched, but a wait of the main thread for one of them counts (threads and async). On a server, the host sets this time (FluxWatchdogSeconds, server configuration).

Network

Limit
Messages a player sends to the network of the scripts (synced states, events, spawned objects)120 a second; the server drops the rest
A synced state, the arguments of an event16 KB
An event's name1 to 128 characters
A Network Id256 characters
Networking.SyncTransform60 times a second
A portal's id128 characters

Other limits

  • Player data: 256 keys, of 128 characters, values of 4 096 characters.
  • Threads: no limit on their number; the device may refuse one.
  • Data textures: 1 to 1024 texels a side.
  • Rays and spheres: RaycastAll gives 64 hits at most, OverlapSphere 128 colliders.

On the server

The server runs your scripts (those without [ClientOnly]) on its copy of the scene, as a PC player sees it. There, each object has its transform, its name, its layer and its active state, and nothing else: no physics, no rendering, no local player, no input, no sound, no video, no UI, no player data. Calls to these are refused, with the reason (World.isServer is true: there is no physics, rendering nor local player on the server).

What the server's scripts do: move objects of their copy, read the players (Players), hear the players' network events and the changes of owner, open portals, spawn objects for the room, and reach the web with every address allowed (web). They send no synced state and no event to the players.

Play mode

Play mode runs your world as one player's game, alone in the room:

  • you are the master, ownership is granted at the next frame, and nothing goes over the network;
  • [ServerOnly] scripts are not created, and Portals.Spawn returns false (only a server opens portals);
  • every web address is allowed, without the window players see (web);
  • the server's clock is the editor's own clock, and the player's name and account are the Play Mode Display Name and Play Mode Account Id of the NW World Config.