Roblox Party: Invites, Leader, and Group Teleport
ESCOPO
Generate a professional group (party) system for Roblox, with automatic group creation, expiring invites, accept/decline, leader, member limit, voluntary leave, kicking, and safe party dissolution. The system is designed to operate with full server-side validation.
The prompt requests project context before implementation, allowing you to adapt RemoteEvent names, UI elements, destination PlaceId, and your game's own rules. It also includes joint teleport to a reserved server, failure handling, and state synchronization for clients.
Ideal for developers creating lobbies, dungeons, raids, co-op matches, manual matchmaking, or multiplayer experiences with squads that persist during the session.
Conteudo
Prompt principal
Act as a senior Roblox developer, specialized in Luau, multiplayer architecture, TeleportService, and server-authoritative security. Create a complete group/party system with invites and joint teleport, adapted to the context of my project that I will provide below. Before writing the code, read and consider the context below. If any essential information is missing, ask at most 5 objective questions before generating the solution. If I do not answer, assume safe names and clearly document at the top of the code the values I should change. MY GAME CONTEXT (I will fill in): - Destination PlaceId for the party: [PLACE_ID] - Maximum number of players per party: [EX.: 4] - Where the existing RemoteEvents/RemoteFunctions are located in Explorer: [PATH] - Names and types of the existing remotes, with expected direction: [EX.: PartyAction RemoteEvent client > server; PartyState RemoteEvent server > client] - UI elements and their names/paths, if any: [PATH] - How the player selects the invite target: [UserId, name, UI button, ProximityPrompt etc.] - Extra rules (minimum level, same region, currency, cooldown, permissions): [RULES] - Should the teleport use a reserved server? [YES/NO] - Is the PlaceId from the same Roblox universe? [YES/NO] Deliver the main implementation as ONE server Luau Script, to be placed in ServerScriptService, for example with the name PartyService.server.lua. The script should be as self-contained as possible: safely locate or create a PartyRemotes folder in ReplicatedStorage and create only the necessary RemoteEvents if they do not exist. If I provide remotes that already exist, respect their names, paths, and contracts exactly. Do not create a LocalScript or full UI, unless it is strictly necessary to demonstrate the remote contract; in that case, provide only a short and separate example after the main script, making it explicit that it is not a required part of the delivery. The Script must implement a robust in-memory server architecture using typed tables where appropriate, mapping player/UserId to party and each party to its data. Include: party creation when one player invites another; party leader; pending invite with configurable expiration; accept and decline; prevention of duplicate invites; blocking players who are already in another party; maximum member limit; voluntary leaving; leader-only kicking; deterministic leadership transfer when the leader leaves; dissolution when no members remain; complete cleanup on PlayerRemoving; and sending state updates to members after every change. Define a clear, validated protocol for the RemoteEvent received from the client, preferably a string action such as "Invite", "AcceptInvite", "DeclineInvite", "Leave", "Kick", and "TeleportParty", accompanied only by the minimum data necessary. For each action, validate rigorously on the server: type of every argument, existence of the target Player, valid UserId, connected player, leader permissions, current party, active invite, expiration, party capacity, and anti-spam cooldown. Never accept from the client data such as member list, leader, PlaceId, reserved server code, reward value, or any decisive state. Implement the joint teleport only when requested by the leader. Before teleporting, revalidate connected members, the limit, and party consistency. Use TeleportService on the server and TeleportOptions appropriately. When reserved servers are enabled, reserve a server and send all valid members together; include minimal, non-sensitive TeleportData, such as partyId and UserIds, only for identification at the destination. Handle errors with pcall, notify affected members through a feedback RemoteEvent, and do not destroy the party automatically if the attempt fails. Avoid TeleportService on the client and explain the limitation of testing teleport in Studio's Play Solo mode. The code needs to be valid, complete, and ready-to-paste Luau, with helpful comments in Portuguese, consistent names, configurable constants at the beginning, and no pseudocode, omitted sections, or hidden dependencies. Do not use DataStore for this temporary party unless I explicitly ask for persistence. Do not use deprecated APIs. Assume the client is malicious: every invite, leadership, member, and teleport rule must be decided on the server. Your response must have this mandatory structure: 1. Brief summary of the architecture and the remotes used/created. 2. A section "Local no Explorer" stating exactly: Script in ServerScriptService > PartyService.server.lua and the remotes in ReplicatedStorage > PartyRemotes. 3. The complete code exclusively inside a markdown ```lua block. 4. A short table documenting each remote action, expected arguments, and applied validations. 5. Numbered final instructions to test in Roblox Studio with Start Server and multiple Players, including how to configure API access/published teleport when necessary and how to simulate invite, accept, kick, leave, and teleport. Do not invent objects in my game when the provided context defines different names. Prioritize security, fault tolerance, readability, and correct behavior in a real multiplayer environment.
