Users and players

When a Roblox user joins a game, they are represented as a Player in the DataModel. This Player object contains information about the user that's universal across games, such as their username, friend list, and saved avatar character, as well as properties, methods, and events that affect the user's lifecycle between joining and leaving the game. Each Player object also parents four important containers that you can use to customize a user's experience: Backpack, StarterGear, PlayerGui, and PlayerScripts.

Each Player also exposes a Player.User property, which is a User value representing the player's domain-scoped identity within the current game. For more information on how user identification works, including domain-scoped user IDs and the User type, see Users and domain-scoped user IDs.

Lifecycle

The Players service contains all the Player instances in a game. Client and server-side scripts can both connect to the Players.PlayerAdded and Players.PlayerRemoved events to perform actions in response to the lifecycle of a Player object. Scripts can also connect to the Player.CharacterAdded and Player.CharacterRemoving events to perform gameplay-related actions for when the character spawns or despawns.

User join

When a user client connects to a game, the Players.PlayerAdded event fires and passes the Player object of the user who joins; you can use this object for numerous purposes such as loading user data from a data store or assigning the player to a team.

For example, to load a user's data when they join a game, use the PlayerAdded event in a Script to retrieve the user's data stored in a data store under their user ID:

Script in ServerScriptService

local DataStoreService = game:GetService("DataStoreService")
local Players = game:GetService("Players")
local playerDataStore = DataStoreService:GetDataStore("PlayerData")
Players.PlayerAdded:Connect(function(player)
local userId = player.UserId
-- Read data store key
local getSuccess, currentData = pcall(function()
return playerDataStore:GetAsync(userId)
end)
if getSuccess then
print(currentData)
end
-- Do further actions with currentData
end)

Character spawn

By default, a user's Player.Character model represents their platform avatar and Players.CharacterAutoLoads is true, meaning the character model automatically spawns when the user joins a game.

When a user's Player.Character spawns, Scripts and LocalScripts in StarterCharacterScripts clone into the character model and the Player.CharacterAdded event fires. This event passes the new character model to its listeners which you can use to find the character's Humanoid object and modify its behavior. For example, you can use Humanoid:ApplyDescription() to change the outfit of the avatar.

Character despawn

When the player's Humanoid dies, the server automatically removes the character model after the amount of time specified by Players.RespawnTime. You can then use the Player.CharacterRemoving event to reset other objects or update data associated with the character.

User leave

When a user client disconnects from a game, the server destroys its associated Player object inside the Players service. At this point, the Players.PlayerRemoving event fires and passes the Player object of the user who disconnected. You can use this for numerous purposes such as saving user data, removing player stats from a scoreboard, or destroying player‑created models in the game.

The following example Script listens to the PlayerRemoving event and attempts to save the user's data in a data store under their user ID:

Script in ServerScriptService

local DataStoreService = game:GetService("DataStoreService")
local Players = game:GetService("Players")
local playerDataStore = DataStoreService:GetDataStore("PlayerData")
Players.PlayerRemoving:Connect(function(player)
local userId = player.UserId
-- Get the player's data state in the game
local currentData = getCurrentData(player)
-- Save to data store
local setSuccess, errorMessage = pcall(function()
playerDataStore:SetAsync(userId, currentData)
end)
if not setSuccess then
warn(errorMessage)
end
end)

Containers

Each Player object representing a user's client stores several important containers: Backpack, StarterGear, PlayerGui, and PlayerScripts. At game runtime, several containers in the "edit" data model copy their contents over to these Player containers, including StarterGui to PlayerGui, StarterPack to Backpack, and StarterPlayerScripts to PlayerScripts.

A diagram that maps objects between 'edit' and 'runtime' data models.

Tool objects in the Backpack make up the player's inventory and display as icon buttons at the bottom of the screen. See in‑game tools for more information.

As illustrated above, the contents of StarterPack and the player's StarterGear clone to Backpack when a player's Character spawns. When the character dies, the client destroys the Backpack and replaces it with a new one.

To disable the default Roblox inventory GUI and replace it with your own, call StarterGui:SetCoreGuiEnabled() in a LocalScript as outlined in disable default UI.

Ban users

To ensure civility and fair play in your games, you can ban users who violate rules or community guidelines. You can modify ban durations, ban messages, and even extend bans to potential alternate accounts. When using this feature, you must follow banning guidelines and messaging.

You have several options for working with bans:

Device blocking

In addition to banning an account, Players:BanAsync() supports device blocking through the ApplyDeviceBlock field in its config table. When you ban a user who is currently connected to your game with ApplyDeviceBlock set to true, the device associated with that user is also blocked from rejoining for 24 hours. This option adds friction against ban evasion; banned players can't immediately rejoin the game from a new account on the same device.

  • Device blocking currently only applies to players on desktop (Windows and macOS). It does not apply to mobile devices or consoles.
  • The device block does not propagate as a ban to any other accounts that have used the device.
  • Calling the unban API on the affected user immediately removes any active device block associated with that user's device, allowing them to rejoin the game.

Ban guidelines

When implementing bans in your game, adhere to the following guidelines:

  • Game rules must not contradict Roblox's Community Standards and Terms of Use. For example, you cannot create a game rule that excludes someone because of their gender, as this violates Roblox's Discrimination, Slurs, and Hate Speech policy.
  • Creators must clearly state their game rules somewhere accessible to all users.
  • Creators must apply their game rules fairly and not arbitrarily target certain users.
  • Users can appeal to creators directly if they believe their ban was incorrect. Roblox will not mediate these appeals, unless the user believes the creator's game rules or enforcement of their rules violate the Community Standards.
  • Roblox can moderate a game if there is reason to believe that a creator's game rules or enforcement of their rules violate the Community Standards.

Message guidelines

When a user is banned, they receive an error modal displaying information such as the ban length and reason. In the text-filtered message, you can include additional information such as appeal or contact information as long as you meet Roblox's Community Standards.

For example, in your ban messages, you are allowed to reference brand names and platforms:

  • "Visit the Discord in my group/game page"
  • "Message me on Twitter or X"

Mentions of personal information or direct links are not allowed in this message field. This includes posting a specific username or handle, or providing a direct link to a Discord server or X account.

©2026 Roblox Corporation. Roblox, the Roblox logo and Powering Imagination are among our registered and unregistered trademarks in the U.S. and other countries.