Party Roblox: Convites, Líder e Teleporte em Grupo
Gere um sistema profissional de grupos (party) para Roblox, com criação automática de grupo, convites com expiração, aceite/recusa, líder, limite de integrantes, saída voluntária, expulsão e dissolução segura da party. O sistema é projetado para operar com validação total no servidor.
O prompt solicita contexto do projeto antes de implementar, permitindo adaptar nomes de RemoteEvents, elementos de interface, PlaceId de destino e regras próprias do seu jogo. Também inclui teleporte conjunto para servidor reservado, tratamento de falhas e sincronização de estado para os clientes.
Ideal para desenvolvedores que estão criando lobbies, dungeons, raids, partidas cooperativas, matchmaking manual ou experiências multiplayer com squads persistentes durante a sessão.
Atue como um desenvolvedor Roblox sênior, especialista em Luau, arquitetura multiplayer, TeleportService e segurança server-authoritative. Crie um sistema completo de grupo/party com convites e teleporte conjunto, adaptado ao contexto do meu projeto que vou fornecer abaixo. Antes de escrever o código, leia e considere o contexto a seguir. Se algum dado indispensável estiver ausente, faça no máximo 5 perguntas objetivas antes de gerar a solução. Se eu não responder, assuma nomes seguros e deixe claramente documentados no topo do código os valores que devo alterar. CONTEXTO DO MEU JOGO (vou preencher): - PlaceId de destino para a party: [PLACE_ID] - Quantidade máxima de jogadores por party: [EX.: 4] - Onde ficam os RemoteEvents/RemoteFunctions existentes no Explorer: [CAMINHO] - Nomes e tipos dos remotes existentes, com direção esperada: [EX.: PartyAction RemoteEvent cliente > servidor; PartyState RemoteEvent servidor > cliente] - Elementos de UI e seus nomes/caminhos, se existirem: [CAMINHO] - Como o jogador seleciona o alvo do convite: [UserId, nome, botão de UI, ProximityPrompt etc.] - Regras extras (nível mínimo, mesma região, moeda, cooldown, permissões): [REGRAS] - O teleporte deve usar servidor reservado? [SIM/NÃO] - PlaceId é do mesmo universo Roblox? [SIM/NÃO] Entregue a implementação principal como UM Script de servidor Luau, para ser colocado em ServerScriptService, por exemplo com o nome PartyService.server.lua. O script deve ser autocontido na medida do possível: localizar ou criar com segurança uma pasta PartyRemotes em ReplicatedStorage e criar apenas os RemoteEvents necessários caso eles não existam. Se eu informar remotes já existentes, respeite exatamente seus nomes, caminhos e contratos. Não crie LocalScript nem UI completa, salvo se for estritamente necessário para demonstrar o contrato dos remotes; nesse caso, forneça somente um exemplo curto e separado após o script principal, deixando explícito que não é parte obrigatória da entrega. O Script deve implementar uma arquitetura robusta em memória no servidor usando tabelas tipadas quando fizer sentido, mapeando player/UserId para party e cada party para seus dados. Inclua: criação de party quando um jogador convida outro; líder da party; convite pendente com expiração configurável; aceite e recusa; prevenção de convites duplicados; bloqueio para jogadores que já estão em outra party; limite máximo de membros; saída voluntária; expulsão exclusiva do líder; transferência determinística de liderança quando o líder sai; dissolução ao ficar sem membros; limpeza completa em PlayerRemoving; e envio de atualizações de estado aos membros após toda alteração. Defina um protocolo claro e validado para o RemoteEvent recebido do cliente, preferencialmente uma ação string como "Invite", "AcceptInvite", "DeclineInvite", "Leave", "Kick" e "TeleportParty", acompanhada apenas dos dados mínimos necessários. Para cada ação, valide rigorosamente no servidor: tipo de todos os argumentos, existência do Player alvo, UserId válido, jogador conectado, autorizações do líder, party atual, convite ainda ativo, expiração, capacidade da party e cooldown anti-spam. Nunca aceite do cliente dados como lista de membros, líder, PlaceId, código de servidor reservado, valor de recompensa ou qualquer estado decisivo. Implemente o teleporte conjunto somente quando solicitado pelo líder. Antes de teleportar, revalide membros conectados, limite e consistência da party. Use TeleportService no servidor e TeleportOptions de forma apropriada. Quando servidores reservados estiverem habilitados, reserve um servidor e envie todos os membros válidos juntos; inclua TeleportData mínimo e não sensível, como partyId e UserIds, apenas para identificação no destino. Trate erros com pcall, notifique os membros afetados por um RemoteEvent de feedback e não destrua a party automaticamente se a tentativa falhar. Evite TeleportService no cliente e explique a limitação de testes de teleporte no modo Play Solo do Studio. O código precisa ser Luau válido, completo e pronto para colar, com comentários úteis em português, nomes consistentes, constantes configuráveis no início e sem pseudocódigo, trechos omitidos ou dependências invisíveis. Não use DataStore para esta party temporária, a menos que eu peça persistência explicitamente. Não use APIs obsoletas. Considere que o cliente é malicioso: toda regra de convite, liderança, membros e teleporte deve ser decidida no servidor. Sua resposta deve ter esta estrutura obrigatória: 1. Resumo breve da arquitetura e dos remotes usados/criados. 2. Uma seção "Local no Explorer" informando exatamente: Script em ServerScriptService > PartyService.server.lua e os remotes em ReplicatedStorage > PartyRemotes. 3. O código completo exclusivamente dentro de um bloco markdown ```lua. 4. Uma tabela curta documentando cada ação remota, argumentos esperados e validações aplicadas. 5. Instruções finais numeradas para testar no Roblox Studio com Start Server e múltiplos Players, incluindo como configurar acesso de API/teleporte publicado quando necessário e como simular convite, aceite, expulsão, saída e teleporte. Não invente objetos do meu jogo quando o contexto fornecido definir nomes diferentes. Priorize segurança, tolerância a falhas, legibilidade e comportamento correto em ambiente multiplayer real.