Le bac à sable de FL#

Tes scripts FL# sont compilés en un seul module WebAssembly, scripts/client.wasm dans ton monde publié, le même pour toutes les plateformes. Le jeu des joueurs et les serveurs ne le transforment jamais en code machine : ils le font tourner dans leur interpréteur FL#, livré avec NodeWorld. Aucun code apporté par un monde ne tourne directement sur le processeur d'un joueur, quel qu'en soit l'auteur.

Ce que garantit l'interpréteur#

• Un script n'atteint que la mémoire du monde : l'interpréteur vérifie chaque lecture et chaque écriture, et un script ne peut pas inventer un pointeur qui en sort.
• Un appel par un pointeur calculé (un delegate C#, un appel virtuel ou d'interface, un switch) arrive sur une fonction du monde, avec les bons paramètres : l'interpréteur le vérifie à chaque appel.
• Un script n'appelle rien du système : il n'atteint le jeu que par l'API FL#, et Internet que par la porte réseau.
• Le même module tourne de la même façon sur Windows, Linux, le Quest et tous les serveurs, x86-64 ou ARM64.

Il n'y a rien à contrôler avant qu'un monde tourne, ni rien à désactiver : quoi que contiennent les fichiers d'un monde, l'interpréteur n'exécute rien hors du bac à sable.

Vitesse#

Un interpréteur exécute le code moins vite que le processeur. Le travail du jeu reste natif : l'affichage, la physique, le son, la voix et le lecteur vidéo. Seul le code de tes scripts est interprété, et un appel d'un script au jeu coûte peu. Garde les gros calculs hors d'Update : étale-les sur plusieurs images avec une coroutine, ou fais-les dans un thread.

Ce qu'il ne fait pas#

Le bac à sable tient le code d'un monde à l'écart de l'appareil du joueur. Il ne limite pas ce que font tes scripts dans le monde : tout le C#, les threads, autant de mémoire que le format 32 bits le permet, aucun budget de calcul par image. Les limites de ce qu'un monde atteint, Internet (la porte réseau), le menu et la sortie (ce qu'un script ne peut pas bloquer), sont décrites sur leurs propres pages.