Après avoir créé quelques scripts, il ne faut pas longtemps avant que vous souhaitiez réutiliser du code entre eux. En fonction de l'emplacement, ModuleScripts vous permet de réutiliser du code entre des scripts situés de chaque côté de la frontière client-serveur ou du même côté de la frontière.
Vous pouvez placer des scripts de module n'importe où où vous placez des scripts, mais ReplicatedStorage est un emplacement populaire ; stocker des scripts de module ici vous permet de réutiliser le code entre le serveur et les clients.
Anatomie d'un script de module
Dans Roblox Studio, ajoutez un script de module à ReplicatedStorage et renommez-le en PickupManager. Chaque ModuleScript commence par le code suivant :
Ce code crée une table Luau vide et la renvoie à tout script qui requiert le script de module.
La valeur de retour peut être n'importe quel type de données sauf nil, mais la plupart des scripts de module retournent une fonction, une table, ou une table de fonctions. Pour générer sa valeur de retour, les scripts de module peuvent bien sûr exécuter du code arbitraire, ce qui inclut la requête d'autres scripts de module.
Faites attention à ne pas avoir des scripts de module qui se requièrent mutuellement de manière circulaire, ce qui entraîne une erreur Requested module was required recursively.
L'exemple suivant retourne une table avec une seule fonction appelée getPickupBonus. Collez-le dans le nouveau script de module :
-- ModuleScript dans ReplicatedStorage
local PickupManager = {}
local defaultMultiplier = 1.25
local rarityMultipliers = {
common = 10,
uncommon = 20,
rare = 50,
legendary = 100
}
-- Ajouter la fonction getPickupBonus à la table PickupManager
PickupManager.getPickupBonus = function(rarity)
local bonus = rarityMultipliers[rarity] * defaultMultiplier
return bonus
end
return PickupManager
Ajouter la fonction à une table n'est pas strictement nécessaire — vous pourriez simplement retourner la fonction elle-même — mais c'est un bon motif à suivre ; cela vous donne une syntaxe facile à comprendre lorsque vous appelez la fonction depuis un autre script et vous permet d'ajouter facilement plus de fonctions au script de module au fil du temps.
Exiger des scripts de module
Pour charger un script de module, vous appelez la fonction require(). Dans ReplicatedStorage, ajoutez un nouveau script et changez son RunContext en Client. Ensuite, ajoutez le code suivant pour appeler la fonction PickupManager.getPickupBonus :
Script client dans ReplicatedStorage
Le motif Instance:WaitForChild() est une mesure de sécurité importante dans les scripts clients. Pour plus d'informations, voir Ordre de réplication.
Stocker des scripts de module dans ReplicatedStorage vous permet de partager du code entre le serveur et le client, vous pouvez donc utiliser le même code pour requérir le script depuis ServerScriptService :
Script dans ServerScriptService
Lorsque vous appelez require() sur un ModuleScript, il s'exécute une fois et retourne un seul élément en tant que référence. Appeler à nouveau require() retourne exactement la même référence, ce qui signifie que si vous modifiez une table ou une Instance retournée, les appels ultérieurs à require() retournent cette référence modifiée. Le module lui-même ne s'exécute pas plusieurs fois.
Si vous exigez un ModuleScript des deux côtés de la frontière client-serveur, comme dans l'exemple ci-dessus, le ModuleScript retourne une référence unique pour chaque côté.
Motifs
Les scripts de module ont quelques motifs communs que vous pouvez utiliser pour simplifier votre code et éviter les pièges à mesure que votre jeu grandit en taille et en complexité.
La plupart de ces motifs nécessitent une compréhension des événements. Si vous n'êtes pas familier avec eux, consultez Événements.
Partage de données
Pour associer des données à des objets individuels, vous pouvez leur attribuer des attributs ou créer des dossiers Configuration avec des objets de valeur tels que StringValue ou IntValue. Cependant, les deux approches sont problématiques si vous souhaitez ajouter ou modifier des dizaines d’objets ou de valeurs de données. Elles ne stockent également pas de tables ou de fonctions.
Si vous souhaitez modifier les mêmes données pour plusieurs copies du même objet ou réutiliser les mêmes données pour différents objets, stockez les données dans des ModuleScripts. C'est un moyen plus facile pour vous de réutiliser les données dans d'autres scripts, et vous pouvez y stocker des tables et des fonctions.
L'exemple suivant ModuleScript dans ReplicatedStorage stocke les valeurs de configuration pour une arme générique :
ModuleScript dans ReplicatedStorage
Événements personnalisés
Les événements personnalisés permettent aux scripts de communiquer entre eux, mais devoir suivre des références aux objets individuels BindableEvent peut encombrer votre code.
Vous pouvez utiliser ModuleScripts pour stocker des BindableEvents et fournir des gestionnaires d'événements personnalisés qui sont directement liés aux méthodes de ModuleScript.
Le ModuleScript suivant dans ReplicatedStorage a un événement personnalisé qui se déclenche lorsque l'interrupteur change d'état :
ModuleScript dans ReplicatedStorage
local Switch = {}
-- Création d'un bindable afin que tout script puisse écouter les changements d'état de l'interrupteur
local bindableEvent = Instance.new("BindableEvent")
Switch.Changed = bindableEvent.Event
local state = false
function Switch.flip()
state = not state
bindableEvent:Fire(state)
end
return Switch
Le script client suivant dans ReplicatedStorage connecte une fonction à appeler lorsque l'événement Switch.Changed est déclenché.
Script dans ReplicatedStorage
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local Switch = require(ReplicatedStorage:WaitForChild("Switch"))
Switch.Changed:Connect(function(newState)
print("L'état de l'interrupteur est maintenant", newState)
end)
-- Testez en inversant quelques fois
task.wait(1)
Switch.flip()
task.wait(1)
Switch.flip()
Encapsulation
L'encapsulation est la pratique de créer une couche d'abstraction autour des objets ou de la logique de script pour cacher la complexité. Vous pouvez utiliser ModuleScripts pour encapsuler des objets Roblox avec des fonctions Luau personnalisées afin de simplifier le code.
Par exemple, vous pouvez utiliser l'encapsulation pour :
- Simplifier la communication interréseau avec un seul objet RemoteEvent.
- Envelopper le code de gestion des erreurs autour de services sensibles tels que DataStoreService.
- Définir des méthodes personnalisées pour contrôler ou étendre les fonctionnalités des objets Roblox.
Il est difficile de suivre des dizaines d'objets RemoteEvent individuels pour mettre en œuvre la mise en réseau dans un jeu. Vous pouvez utiliser un ModuleScript pour encapsuler un seul RemoteEvent afin d'aider à simplifier ce problème. En incluant un argument id unique, vous pouvez toujours envoyer différents messages réseau tout en n'utilisant qu'un seul RemoteEvent.
Dans l'exemple ci-dessous, le ModuleScript nommé NetworkManagerClient encapsule la méthode RemoteEvent:FireServer() pour inclure cet argument supplémentaire id. De plus, ce ModuleScript fait référence à l'objet RemoteEvent lui-même afin que vous n'ayez pas à y faire référence dans d'autres parties de votre code. Vous n'avez besoin que de requérir ce ModuleScript pour envoyer des messages réseau et vous n'avez pas besoin de gérer des objets RemoteEvent dans le reste de votre base de code.
Le ModuleScript suivant dans ReplicatedFirst fournit une fonction encapsulée que vous pouvez appeler sur vos scripts clients pour envoyer un message réseau :
Module Réseau
-- ModuleScript dans ReplicatedFirst nommé NetworkManagerClient
local NetworkManagerClient = {}
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local remoteEvent = ReplicatedStorage:WaitForChild("RemoteEvent")
-- Encapsuler la fonction FireServer de l'objet distant
function NetworkManagerClient.FireServer(id, ...)
remoteEvent:FireServer(id, ...)
end
return NetworkManagerClient
Le ModuleScript suivant dans ServerScriptService utilise des BindableEvents pour que chaque script puisse se connecter à un ID spécifique. Lorsqu'un client envoie un message réseau, chaque BindableEvent associé à l’ID spécifié se déclenche.
-- ModuleScript dans ServerScriptService nommé NetworkManagerServer
local NetworkManagerServer = {}
local networkSignalList = {}
function NetworkManagerServer.GetServerEventSignal(id)
local bindableEvent = Instance.new("BindableEvent")
-- Lier le nouveau BindableEvent à l'id
table.insert(networkSignalList, {
id = id,
bindableEvent = bindableEvent,
})
return bindableEvent.Event
end
-- Connexion à
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local remoteEvent = ReplicatedStorage:WaitForChild("RemoteEvent")
remoteEvent.OnServerEvent:Connect(function(player, id, ...)
-- Trouver chaque bindable event qui correspond à l'ID de l'événement distant reçu
for _, signal in networkSignalList do
if signal.id == id then
signal.bindableEvent:Fire(player, ...)
end
end
end)
return NetworkManagerServer
Le LocalScript suivant envoie un message avec l'ID RequestA avec un argument optionnel Hello.
Le Script suivant se connecte à l'ID de message réseau RequestA et imprime une déclaration avec tous les paramètres supplémentaires lorsqu'il reçoit la requête.
-- Script dans ServerScriptService
local ServerScriptService = game:GetService("ServerScriptService")
local NetworkManagerServer = require(ServerScriptService:WaitForChild("NetworkManagerServer"))
NetworkManagerServer.GetServerEventSignal("RequestA"):Connect(function(player, ...)
print("Reçu RequestA de", player, ...)
end)