Limites et performances

La mémoire#

NodeWorld ne fixe pas de plafond : le module de ton monde grandit selon ses besoins, jusqu'à 4 Go, la limite du WebAssembly 32 bits. Un Meta Quest a bien moins de mémoire qu'un PC : sur Quest, Android peut fermer le jeu quand un monde en prend trop.

Le temps#

• Pas de budget par image : tes scripts finissent toujours leur image. L'image les attend : un Update lent fait baisser la fréquence d'images du joueur, en VR aussi. Passe le travail lourd sur des threads.
• Chaque appel à l'API traverse la frontière entre ton module et le jeu. Quelques centaines par image ne comptent pas ; pour déplacer, colorer ou dessiner des milliers d'objets, utilise les lots d'objets et le dessin par instances, qui la traversent une seule fois.

Le chien de garde#

Un appel du jeu à tes scripts (Update, un événement, un pas de coroutine) dans lequel ton code tourne plus de 10 secondes, ou 60 secondes pendant le chargement du monde, est arrêté, avec tous les threads du monde ; le temps que le jeu passe à son propre travail pendant l'appel (un chargement, l'affichage, un disque lent) ne compte pas. Le monde reste affiché sans ses scripts, et le joueur voit Les scripts de ce monde étaient bloqués depuis 10 s : ils sont arrêtés. Tes propres threads ne sont pas surveillés, mais une attente du thread principal après l'un d'eux compte (threads et asynchrone). Sur un serveur, l'hébergeur règle cette durée (FluxWatchdogSeconds, configuration du serveur).

Le réseau#

Les autres limites#

• Données du joueur : 256 clés, de 128 caractères, des valeurs de 4 096 caractères.
• Threads : pas de limite à leur nombre ; l'appareil peut en refuser un.
• Textures de données : 1 à 1024 texels de côté.
• Rayons et sphères : RaycastAll donne 64 impacts au plus, OverlapSphere 128 colliders.

Sur le serveur#

Le serveur fait tourner tes scripts (ceux sans [ClientOnly]) sur sa copie de la scène, telle qu'un joueur sur PC la voit. Là-bas, chaque objet a son transform, son nom, sa couche et son état actif, et rien d'autre : ni physique, ni rendu, ni joueur local, ni commandes, ni son, ni vidéo, ni interface, ni données du joueur. Les appels à tout cela sont refusés, avec la raison (World.isServer is true: there is no physics, rendering nor local player on the server).

Ce que font les scripts du serveur : déplacer les objets de leur copie, lire les joueurs (Players), recevoir les événements réseau des joueurs et les changements de propriétaire, ouvrir des portails, faire apparaître des objets pour la salle, et contacter le web avec toutes les adresses permises (web). Ils n'envoient ni état synchronisé ni événement aux joueurs.

Le Play mode#

Le Play mode fait tourner ton monde comme le jeu d'un joueur, seul dans la salle :

• tu es le maître, la propriété est accordée à l'image suivante, et rien ne passe par le réseau ;
• les scripts [ServerOnly] ne sont pas créés, et Portals.Spawn renvoie false (seul un serveur ouvre des portails) ;
• toutes les adresses web sont permises, sans la fenêtre que voient les joueurs (web) ;
• l'horloge du serveur est celle de l'éditeur, et le nom et le compte du joueur sont le Play Mode Display Name et le Play Mode Account Id de la NW World Config.