Types et emplacements des scripts

Pour de nombreux développeurs, le défi fondamental de l'adaptation à la programmation Roblox est l'importance de l'emplacement des fichiers et de la propriété Script.RunContext. Selon le type de script, son emplacement dans l'Explorateur et le contexte d'exécution, les scripts peuvent se comporter très différemment. Certains appels de méthode peuvent échouer, des objets dans votre jeu peuvent être inaccessibles, ou les scripts peuvent ne pas s'exécuter du tout.

La raison de cette complexité est que les jeux Roblox sont multijoueurs par défaut. Les scripts doivent avoir la capacité de s'exécuter uniquement sur le serveur, uniquement sur le client, ou d'être partagés entre les deux. L'évolution de la plateforme Roblox au fil du temps a encore compliqué la situation.

Types de scripts

Roblox a trois types de scripts :

• Script - Code qui s'exécute soit sur le serveur, soit sur le client, selon son emplacement et la propriété Script.RunContext.
• LocalScript - Code qui s'exécute uniquement sur le client. N'a pas de contexte d'exécution.
• ModuleScript - Code que vous pouvez réutiliser dans d'autres scripts. N'a pas de contexte d'exécution.

Lorsque vous créez un Script, son contexte d'exécution par défaut est Legacy, ce qui signifie qu'il a) s'agit d'un script côté serveur et b) ne s'exécute que s'il se trouve dans un conteneur serveur, tel que ServerScriptService ou Workspace.

• Si vous changez le contexte d'exécution du script en Server, il peut maintenant également s'exécuter dans ReplicatedStorage, mais nous ne le recommandons pas. Le contenu de cet emplacement est répliqué aux clients, donc c'est un mauvais emplacement pour les scripts côté serveur.
• Si vous changez le contexte d'exécution du script en Client, il peut s'exécuter dans ReplicatedStorage. Il peut également s'exécuter dans StarterCharacterScripts et StarterPlayerScripts. Les conteneurs de démarrage sont copiés aux clients, donc le script original et la copie s'exécutent, ce qui n'est pas souhaitable.

Pour changer le contexte d'exécution d'un script, sélectionnez-le dans l'Explorateur et changez la valeur dans la fenêtre Propriétés.

Recommandations

• Mettez un seul Script avec un RunContext de Client dans ReplicatedStorage.

• Mettez un seul Script avec un RunContext de Server dans ServerScriptService.

• Utilisez ModuleScripts pour autant de code client et serveur que possible. Exigez ces modules dans votre script client et votre script serveur.

  Cette approche donne à votre code un point d'entrée unique côté client et serveur, ce qui simplifie l'organisation et facilite l'isolement ou la désactivation de modules problématiques. Ajoutez une fonction start() à chaque ModuleScript afin que tous les modules puissent se charger avant que vous ne commenciez à exécuter leur code :

  Exemple de script serveur

  --!strict
  local ServerScriptService = game:GetService("ServerScriptService")
  local SampleModule = require(ServerScriptService.SampleModule)
  local AnotherSampleModule = require(ServerScriptService.AnotherSampleModule)
  SampleModule.start()
  AnotherSampleModule.start()

  Exemple de module

  --!strict
  local CollectionService = game:GetService("CollectionService")
  
  local NPC_TAG = "npc"
  
  local SampleModule = {}
  
  local function setUpNpc(npc: Instance)
      -- initialiser chaque NPC
  end
  
  local function cleanUpNpc(npc: Instance)
      -- exécuter lorsque l'événement se déclenche
  end
  
  function SampleModule.start() -- ajouter la fonction à la table
      -- boucle d'exemple pour la configuration basée sur les tags
      for _, npc in CollectionService:GetTagged(NPC_TAG) do
          setUpNpc(npc)
      end
  
      -- exécuter des fonctions lorsque des événements se déclenchent
      CollectionService:GetInstanceAddedSignal(NPC_TAG):Connect(setUpNpc)
      CollectionService:GetInstanceRemovedSignal(NPC_TAG):Connect(cleanUpNpc)
  end
  
  return SampleModule

• Pour partager du code, utilisez ModuleScripts dans ReplicatedStorage et exigez-les dans votre script client et votre script serveur.

• Si nécessaire pour votre jeu, répétez le même modèle dans ReplicatedFirst avec un seul script client et un nombre minimal de ModuleScripts pour implémenter un écran de chargement. Pour en savoir plus sur ReplicatedFirst, consultez Ordre de réplication.

• Utilisez LocalScripts avec parcimonie. Si vous devez les utiliser, placez-les dans StarterCharacterScripts, StarterPlayerScripts, StarterGui ou StarterPack.

  Les scripts dans ces conteneurs se clonent dans les conteneurs des joueurs plutôt que de s'exécuter à partir d'un seul emplacement, ce qui peut compliquer le débogage. Utiliser ReplicatedStorage pour le code client vous permet de cliquer sur des lignes dans la fenêtre Sortie et d'aller à ReplicatedStorage.YourScript (l'emplacement stable du script) plutôt qu'à Players.YourName.PlayerScripts.YourLocalScript (l'emplacement éphémère où le script a été copié à l'exécution).

• Évitez d'attacher des scripts directement aux instances dans Workspace. Au lieu de cela, taguez les instances et utilisez CollectionService pour travailler avec elles à partir d'un seul ModuleScript.

  L'exception clé est si vous distribuez des modèles ou des packages sur le Creator Store. Dans ce cas, vous pourriez avoir besoin d'inclure des scripts dans la hiérarchie des instances ; spécifiez un RunContext pour chaque script afin d'éliminer toute ambiguïté sur la façon dont il s'exécute. Définir explicitement cette propriété rend les modèles et les packages plus susceptibles de fonctionner correctement à partir de divers emplacements.

Exemple de structure de projet

Le projet de référence Plant montre comment vous pourriez organiser votre code dans un grand jeu complexe. Il stocke la grande majorité de son code sous forme de ModuleScripts réutilisables.

Emplacements des scripts

Cette image montre quels emplacements de la fenêtre Explorateur peuvent contenir des scripts clients. N'oubliez pas que ReplicatedFirst et ReplicatedStorage peuvent contenir des Scripts avec un RunContext de Client, tandis que les conteneurs Starter[] devraient utiliser LocalScripts.