Lorsqu'un utilisateur rejoint une expérience, Roblox le représente comme un joueur dans le modèlisationde données.L'objet contient des informations sur l'utilisateur qui sont universelles à travers les expériences, telles que son nom d'utilisateur, sa liste d'amis, son personnage d'avatar sauvegardé, et le taperde membre Roblox, ainsi que les propriétés, les méthodes et les événements qui affectent le cycle de vie de l'utilisateur entre le rejoindre et quitter votre expérience.
Le service Players contient toutes les instances Player dans une expérience.Chaque objet Player représente un utilisateur dans l'expérience, et il parent quatre conteneurs importants que vous pouvez utiliser pour personnaliser l'expérience d'un utilisateur : Backpack , StarterGear , PlayerGui et PlayerScripts .
Cycle de vie
Les scripts côté client et côté serveur peuvent tous deux se connecter aux événements Players.PlayerAdded et Players.PlayerRemoved pour effectuer des actions en réponse à la vie d'un objet Player.Ils peuvent également se connecter aux événements Player.CharacterAdded , Player.CharacterRemoving et Humanoid.Died pour effectuer des actions liées au jeu lorsque le personnage apparaît, disparaît et meurt.
Utilisez des scripts pour accéder aux services liés au serveur, tels qu'un magasin de données pour récupérer et enregistrer des données lorsqu'un utilisateur rejoint ou quitte.Utilisez des scripts locaux si le client doit créer et supprimer des instances de jeu liées au nouvel utilisateur, telles qu'un affichage GUI des statistiques de l'utilisateur sur un classement classements.
Rejoindre l'utilisateur
Lorsqu'un client se connecte à une expérience, son objet associé Player clone au service Players.Le Players.PlayerAdded représente les utilisateurs qui rejoignent l'expérience.Certains cas d'utilisation d'exemple incluent le chargement des données de l'utilisateur, l'attribution d'équipes et le changement des vêtements du personnage d'un utilisateur.L'événement Players.PlayerAdded passe l'objet Player de l'utilisateur qui se joint, que vous pouvez utiliser lors de l'appel d'autres fonctions, telles que le magasin de données et les objets RemoteEvent.
Chargement des données utilisateur lors de l'adhésion
Pour charger les données d'un utilisateur lorsqu'il rejoint une expérience, utilisez l'événement Players.PlayerAdded dans un Script.L'exemple suivant Script écoute l'événement et tente de récupérer les données d'un utilisateur en utilisant son ID d'utilisateur comme clé du stockage de données.Après avoir récupéré avec succès les données de l'utilisateur, vous pouvez l'utiliser pour charger la progression et les statistiques de l'utilisateur.
local DataStoreService = game:GetService("DataStoreService")
local playerDataStore = DataStoreService:GetDataStore("PlayerData")
game:GetService("Players").PlayerAdded:Connect(function(player)
local userId = player.UserId
-- Lire la clé du stock de données
local getSuccess, currentData = pcall(function()
return playerDataStore:GetAsync(userId)
end)
if getSuccess then
print(currentData)
end
-- Effectuer d'autres actions avec les données actuelles
end)
Le Instance.Name de l'objet Player est le nom de l'utilisateur.Si vous avez besoin d'une référence unique à un utilisateur, comme pour enregistrer des informations à son sujet dans un magasin de données , utilisez leur au lieu de leur car les utilisateurs ne peuvent pas modifier leur nom d'utilisateur et leur nom d'affichage, même s'ils peuvent modifier leur nom d'utilisateur et leur nom d'affichage.
L'utilisateur quitte
Lorsqu'un client se déconnecte d'une expérience, le serveur détruit son objet associé Player du service Players.L'événement Players.PlayerRemoving représente les utilisateurs qui quittent l'expérience.Certains cas d'utilisation d'exemple incluent la sauvegarde des données de l'utilisateur, le retrait de leurs statistiques d'un tableau de bord et la destruction de n'importe quel de leurs modèles, comme leur maison.L'événement Players.PlayerRemoving passe l'objet Player de l'utilisateur qui part, que vous pouvez utiliser lors de l'appel d'autres fonctions, telles que le magasin de données et les objets RemoteEvent.
Remarquez que l'événement est appelé Player.PlayerRemoving , pas Player.PlayerRemoved , car "supprimé" impliquerait que l'objet Player est déjà supprimé et est donc inaccessible aux scripts.
Enregistrer les données utilisateur lors de la quitter
Pour enregistrer les données d'un utilisateur lorsqu'il quitte une expérience, utilisez l'événement Players.PlayerRemoving dans un Script.L'exemple suivant Script écoute l'événement et tente de sauvegarder les données d'un utilisateur en utilisant son ID d'utilisateur comme clé du stock de données.
Script dans ServerScriptService
local DataStoreService = game:GetService("DataStoreService")
local playerDataStore = DataStoreService:GetDataStore("PlayerData")
game:GetService("Players").PlayerRemoving:Connect(function(player)
local userId = player.UserId
-- Obtenir l'état des données du joueur dans le jeu
local currentData = getCurrentData(player)
-- Enregistrer dans le boutiquede données
local setSuccess, errorMessage = pcall(function()
playerDataStore:SetAsync(userId, currentData)
end)
if not setSuccess then
warn(errorMessage)
end
end)
Apparition de caractères
Le modèle d'un utilisateur Player.Character représente son avatar.Par défaut, Player.CharacterAutoLoads est vrai, et le modèle de caractère d'un utilisateur apparaît automatiquement lorsqu'il rejoint l'expérience.Si Player.CharacterAutoLoads est faux, vous devez appeler Player:LoadCharacter() pour générer manuellement le personnage.
Lorsque la génération d'un utilisateur Player.Character apparaît, les scripts et les scripts locaux dans StarterCharacterScripts se transforment en modèle de caractère et l'événement Player.CharacterAdded se déclenche.L'événement Player.CharacterAdded passe le nouveau modèle de caractère à tous les écouteurs d'événements, que vous pouvez utiliser pour trouver l'objet du caractère Humanoid et modifier son comportement.Par exemple, vous pouvez utiliser Humanoid:ApplyDescription() pour changer la tenue de l'avatar et Humanoid.WalkSpeed ou Humanoid.JumpHeight pour modifier le mouvement de l'avatar.
Déspawnage du personnage
Lorsque les parties du corps du joueur Humanoid meurent, ses organes tombent au sol et l'événement Humanoid.Died se déclenche.Le serveur supprime automatiquement le modèle de caractère et tous les scripts à l'intérieur après un certain temps que la propriété Players.Respawntime détermine.Vous pouvez utiliser l'événement Player.CharacterRemoving pour réinitialiser d'autres objets associés au personnage, tels que la propriété réseau d'un véhicule qu'ils conduisaient.
Compter les décès de joueurs
Vous pouvez utiliser l'événement Humanoid.Died pour gérer le comptage des éliminations ou créer un modèlisationde ragdoll personnalisé.Le suivant Script se connecte à Player.CharacterAdded pour récupérer le modèlisationde caractère de chaque utilisateur, puis se connecte à l'objet du personnage Humanoid.Lorsque l'événement du humanoïde Humanoid.Died se déclenche, le script augmente le nombre de fois que l'humanoid de l'utilisateur est mort et produit ce nombre.
Script dans ServerScriptService
game:GetService("Players").PlayerAdded:Connect(function(player)
local deaths = 0
player.CharacterAdded:Connect(function(character)
local humanoid = character:WaitForChild("Humanoid")
humanoid.Died:Connect(function()
deaths += 1
print(player.Name .. " death count: " .. deaths)
end)
end)
end)
Bannir les utilisateurs
Pour assurer la civilité et le jeu équitable dans vos expériences, vous pouvez bannir les utilisateurs qui enfreignent les règles de votre expérience et les directives de la communauté.Vous pouvez modifier les durées des bans, les messages de bans et même étendre les bans à des comptes alternatifs potentiels.Lors de l'utilisation de cette fonctionalité, vous devez également suivre les directives pour interdire et messagerie.
Pour les instructions de mise en œuvre et d'utilisation, voir Players.BanAsync.
Lignes directrices sur le bannissement
Lors de l'application de bans dans votre expérience, respectez les directives suivantes :
- Les règles d'expérience ne doivent pas contradire les normes communautaires de Roblox et les conditions d'utilisation .
- Par exemple, vous ne pouvez pas créer une règle d'expérience qui exclut quelqu'un en raison de son genre car cela viole la politique de discrimination, d'insultes et de discours de haine de Roblox .
- Les créateurs doivent clairement indiquer leurs règles d'expérience quelque part accessible à tous les utilisateurs.
- Les créateurs doivent appliquer leurs règles d'expérience de manière équitable et non arbitraire et cibler certains utilisateurs spécifiques.
- Les utilisateurs peuvent faire appel aux créateurs directement s'ils estiment que leur ban était incorrecte.
- Roblox ne médiera pas ces appels, à moins que l'utilisateur ne pense que les règles d'expérience du créateur ou l'application de leurs règles enfreignent les normes de la communauté.
- Roblox peut modérer une expérience si il y a une raison de croire que les règles d'expérience d'un créateur ou leur application enfreignent les normes de la communauté .
Directives de message
Lorsqu'un utilisateur est banni, il reçoit une erreur affichant des informations telles que la durée et la raison de l'interdiction.Dans le message filtré par le texte, vous pouvez inclure des informations supplémentaires telles que l'appel ou les informations de contact tant que vous respectez les normes communautaires de Roblox Community Standards.
Par exemple, dans vos messages de bannissement, vous êtes autorisé à faire référence aux noms de marques et aux plateformes :
- « Visitez le Discord sur ma page de groupe/expérience »
- « Messagez-moi sur Twitter ou X »
Les mentions d'informations personnelles ou de liens directs ne sont pas autorisées dans ce champ de message.Cela inclut la publication d'un nom d'utilisateur ou d'une contrôleurspécifique, ou la fourniture d'un lien direct vers un serveur Discord ou un compte X.
Conteneurs
L'objet Player stocke plusieurs conteneurs importants :
Sac à dos
Le conteneur Player.Backpack stocke l'inventaire de l'utilisateur.Les objets Tool des utilisateurs dans leur affichage Backpack dans leur inventaire en bas de leur écran.Si un utilisateur sélectionne un Tool dans l'inventaire, il l'équipe et il se déplace du Player.Backpack au Player.Character .
Lorsque la génération d'un utilisateur Player.Character apparaît, le contenu du service StarterPack et ses clones Player.StarterGear sont transférés vers son Player.Backpack .Lorsque le personnage meurt, le client détruit son Backpack et le remplace par un nouveau.
Le Backpack stocke également et exécute Scripts et LocalScripts que le client et le serveur peuvent tous deux accès.
Roblox fournit une interface pour qu'un joueur accède à son Backpack et à son inventaire en bas de l'écran.Pour désactiver l'interface utilisateur par défaut du sac à dos Roblox et la remplacer par posséder, appelez StarterGui:SetCoreGuiEnabled() dans un script local.Pour plus d'informations, voir StarterGui .
Équipement de départ
Le conteneur StarterGear clone ses contenus au sein de l'utilisateur Player.Backpack lorsque son personnage apparaît.De plus, si votre lieu permet l'équipement et qu'un utilisateur possède de l'équipment, les objets de leur clone d'équipement se transforment en lorsqu'ils régénération, apparition.
Contrairement à StarterPack , Player.StarterGear n'est pas un service mais plutôt un enfant de chaque objet Player, ses contenus sont donc spécifiques à l'utilisateur.Chaque utilisateur peut avoir des objets différents Tool dans leur Player.StarterGear .Pour utiliser Player.StarterGear , activez le matériel dans la page des paramètres de votre expérience sous autorisations .Sur la page des permissions, vous pouvez activer par équipement par son taper.Pour désactiver l'équipment, désélectionnez son taper.
Testez toujours les jeux après leur avoir ajouté de l'équipement pour vérifier que les utilisateurs ne peuvent pas facilement les abuser là-bas.L'équipement inclut Script objets et permet au joueur d'effectuer des actions que vous pourriez ne pas envisager.Par exemple, un équipement de navigation peut permettre au joueur d'accéder à une partie de la carte que vous ne voulez pas qu'il ait.Les armes permettent aux joueurs avec du matériel de blesser d'autres joueurs, éventuellement sans rétribution ou représailles.
JoueurGui
Le conteneur PlayerGui stocke les objets qui créent l'interface utilisateur graphiquedu joueur.Si un ScreenGui est un descendant d'un PlayerGui , alors tout GuiObject à l'intérieur du ScreenGui s'affiche sur l'écran du joueur.Toute LocalScript s'exécute lorsqu'elle se clone à PlayerGui.Lorsque le spawn du joueur Player.Character apparaît pour la première fois, tous les contenus de StarterGui sont automatiquement copiés dans le dossier du joueur PlayerGui.
Si Players.CharacterAutoLoads est défini sur false, le personnage ne se régénération, apparitionpas et les contenus de StarterGui ne se copient pas jusqu'à ce que Player:LoadCharacter() soit appelé.Si StarterGui.ResetPlayerGuiOnSpawn est défini sur true, chaque fois que le personnage du joueur réapparaît, tous les contenus de ce joueur PlayerGui sont effacés et remplacés par les contenus de StarterGui.
Scripts de joueur
Lorsqu'un utilisateur rejoint l'expérience, le contenu du conteneur StarterPlayer.StarterPlayerScripts est cloné à PlayerScripts. Tous les scripts locaux et les modules sont exécutés lorsqu'ils sont clonés.
Contrairement aux conteneurs Backpack et PlayerGui, le conteneur PlayerScripts n'est pas accessible au serveur, et le conteneur d'un utilisateur PlayerScripts ne se réinitialise pas lorsque son personnage meurt et réapparaît.Les objets côté serveur Script ne s'exécutent pas non plus lorsqu'ils sont parentés à PlayerScripts.Le conteneur PlayerScripts est utile pour les scripts qui ne sont pas liés au cycle de vie du personnage d'un utilisateur, tels que le système de chat général ou les contrôles d'entrée du joueur.