Lorsqu'un utilisateur rejoint une expérience, Roblox le représente comme un joueur dans le modèlisationde données. L'objet Player contient des informations sur l'utilisateur qui sont universelles dans toutes les expériences, telles que son nom d'utilisateur, sa liste d'amis, son enregistrement d'avatar et le taperde son abonnement, ainsi que des propriétés, des méth
Le service Players contient toutes les Player instances dans une expérience. Chaque Player objet représente un utilisateur dans une expérience, et il parents quatre conteneurs importants que vous pouvez utiliser pour personnaliser l'expérience d'un utilisateur :
Vie du cycle
Les scripts côté client et serveur peuvent tous deux se connecter aux événements Players.PlayerAdded et Players.PlayerRemoved pour exécuter des actions en réponse au cycle de vie d'un objet Class.Player</
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 les données lorsqu'un utilisateur rejoint ou quitte. Utilisez LocalScripts si le client doit créer et supprimer des instances de jeu liées au nouveau utilisateur, telles qu'un affichage GUI pour les statistiques de l'utilisateur sur un tableau de classementspersonnalisé.
L'utilisateur rejoint
Lorsqu'un client se connecte à une expérience, son objet associé Player clone au service Players. Le Class.Players.PlayerAdded
Chargement des données de l'utilisateur au moment 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 . Le suivant de l'exemple Script écoute l'événement et essaie de récupérer les données d'un utilisateur en utilisant son ID d'utilisateur comme clé de la base de données. Après
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 magasin de données
local getSuccess, currentData = pcall(function()
return playerDataStore:GetAsync(userId)
end)
if getSuccess then
print(currentData)
end
-- Faites d'autres actions avec les données actuelles
end)
Le Instance.Name du Player objet est le nom de l'utilisateur. Si vous avez besoin d'une référence unique à un utilisateur, comme enregistrer des informations sur eux dans un Class.Player.Storage données, utilisez leur 2>Class.Player.UserId</
Quitter l'utilisateur
Lorsqu'un client se déconnecte d'une expérience, le serveur détruit son objet associé Player de l'expérience Class
Remarquez que l'événement est appelé Player.PlayerRemoving, non Player.PlayerRemoved, car «removed» impliquerait que l'objet Player est déjà supprimé et est donc inaccessible aux scripts.
Enregistrement des données de l'utilisateur lors de la fermeture
Pour enregistrer les données d'un utilisateur lorsqu'il quitte une expérience, utilisez l'événement Players.PlayerRemoving dans un Script . Le suivant de l'exemple Script écoute l'événement et essaie de sauvegarder les données d'un utilisateur en utilisant son ID utilisateur comme clé de la sauvegarde.
Script dans ServerScriptService
local DataStoreService = game:GetService("DataStoreService")
local playerDataStore = DataStoreService:GetDataStore("PlayerData")
game:GetService("Players").PlayerRemoving:Connect(function(player)
local userId = player.UserId
-- Obtenez 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)
Génération de personnages
Le modèle d'un utilisateur de Player.Character représente son avatar. Par défaut, Player.CharacterAutoLoads est vrai, et le modèle de caractère d'un utilisateur est automatiquement généré lorsqu'il rejoint l'expérience. Si Player.CharacterAutoLoads est faux, alors vous devez appeler 1> Class.
Lorsqu'un avatarappara
Déspawning des personnages
Lorsque le joueur est mort, ses parties du corps tombent au sol et l'événement Humanoid déclenche. Le serveur supprime automatiquement le modèle de caractère et tous les scripts à l'intérieur après le temps que la propriété Humanoid.Died détermine
Compter les morts de joueurs
Vous pouvez utiliser l'événement Humanoid.Died pour gérer le classement pour un kill ou créer un modèlisationde ragdoll personnalisé. Le suivant Script se connecte à Class.Player.Character
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 juste dans vos expériences, vous pouvez interdire les utilisateurs qui enfreignent vos règles d'expérience et directives de la communauté. Vous pouvez modifier la durée des interdictions, les messages d'interdiction et même étendre les interdictions à des comptes potentiels. Lors de l'utilisation de cette fonctionalité, vous devez également suivre les lignes directrices pour interdire et envoyer des messages .
Pour les instructions d' implementation et d'utilisation, voir Players.BanAsync .
Lignes directrices sur les bans
Lors de l'application de bans dans votre expérience, adhérez-vous aux lignes directrices suivantes :
- Les règles d'expérience ne doivent pas contradre les normes de la communauté et conditions d'utilisation de Roblox.
- 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 tout à fait et non pas arbitrairement cibler certains utilisateurs.
- Les utilisateurs peuvent appeler les créateurs directement s'ils croient que leur interdiction est incorrecte.
- Roblox ne médiera pas ces demandes, à moins que l'utilisateur ne croie que les règles d'expérience du créateur ou l'application de leurs règles viole les normes de la communauté.
- Roblox peut modérer une expérience si il y a des motifs de croire qu'une expérience de créateur viole les normes de la communauté.
Lignes directrices pour les messages
Lorsqu'un utilisateur est banni, il reçoit une erreur modale d'avertissement affichant des informations telles que la durée de la ban et la raison. Dans le message filtré par texte, vous pouvez inclure des informations supplémentaires telles que des informations d'appel ou de contact tant que vous respectez les normes de la communauté de Roblox.
Par exemple, dans vos messages de ban, vous êtes autorisé à référencer des noms de marques et des plates-formes :
- « Visitez le Discord dans ma page de groupe/expérience »
- « Messagez-moi sur Twitter ou X »
Les références à des informations personnelles ou à des liens directs ne sont pas autorisées dans ce champ de message. Cela inclut la publication d'un nom d'utilisateur spécifique ou 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 dans un conteneur utilisateur affiché dans leur inventaire en bas de leur écran. Si un utilisateur sélectionne un Backpack dans l
Lorsque un utilisateur apparaît, le contenu du service Player.Character et ses clones StarterPack dans son Player.StarterGear . Lorsque le personnage meurt, le client détruit son 1>Class.Backpack1> et le remplace par un nouveau.
Le Backpack stocke et exécute également Scripts et LocalScripts que le client et le serveur peuvent tous les deux accès.
Roblox fournit une interface pour qu'un joueur accéde à leur Backpack et à leur inventaire en bas de l'écran. Pour désactiver l'interface de Roblox par défaut et la remplacer par la posséder, appelez StarterGui:SetCoreGuiEnabled() dans un LocalScript. Pour plus d'informations, voir StarterGui.
Équipement de démarrage
Le conteneur StarterGear clone son contenu dans le Player.Backpack de l'utilisateur lorsqu'il apparaît. De plus, si votre lieu autorise l'équipement et qu'un utilisateur possède l'équipment, les objets Tool de son équipement cloné dans son 1>Class.Player.StarterGear1> lorsqu'il régénération, apparition.
Contrairement à StarterPack, Player.StarterGear n'est pas un service, mais plutôt un enfant de chaque
Tester toujours les jeux après avoir ajouté de l'équipement à eux pour vérifier que les utilisateurs ne peuvent pas facilement les abuser là-bas. L'équipement inclut Script objets et permet au joueur de faire des actions que vous pourriez ne pas considérer. Par exemple, un équipement de navigation peut permettre au joueur d'accéder à une partie de la carte que vous ne voulez pas qu'ils accèdent. Les armes permettent aux
JoueurGui
Le conteneur PlayerGui stocke les objets qui créent l'interface utilisateur du joueur. Si un interface utilisateur graphiqueest un descendant d'un Class.PlayerGui</
Si Players.CharacterAutoLoads est réglé sur false, le personnage n'apparaît pas et les contenus de StarterGui ne sont pas copiés jusqu'à ce que Player:LoadCharacter() soit appelé. Si Class.StarterGui.
Scripts de joueur
Lorsqu'un utilisateur rejoint l'expérience, le contenu dans StarterPlayer.StarterPlayerScripts conteneur de clonage d'expérience dans PlayerScripts . Tous les scripts locaux et scripts de module s'exécuteront lorsqu'ils cloneront.
Contrairement aux conteneurs Backpack et PlayerGui, le conteneur PlayerScripts