Trading Roblox Anti-Fraude com Escrow e Transação Atômica
ESCOPO
Gere o núcleo profissional de um sistema de trading para Roblox com segurança real no servidor. O prompt orienta a IA a criar um Script Luau servidor-autoritativo capaz de controlar convites, sessões de troca, ofertas de itens e moeda, confirmações independentes, cancelamentos e expiração automática.
O sistema inclui proteções contra duplicação, alterações de oferta após confirmação, spam de RemoteEvents, itens inexistentes ou não negociáveis, saldo insuficiente, sessões concorrentes e manipulações realizadas pelo cliente. É indicado para RPGs, simuladores, jogos de coleção, tycoons e experiências com inventário persistente.
Também solicita uma camada adaptadora para conectar o código à estrutura existente do seu jogo, permitindo informar nomes de pastas, RemoteEvents, valores de inventário, módulos de perfil e regras próprias de negociação antes de gerar o script pronto para uso no Roblox Studio.
Conteudo
Prompt principal
Atue como um desenvolvedor Roblox Luau sênior, especializado em sistemas multiplayer servidor-autoritativos, inventário persistente, DataStore/ProfileService e prevenção de exploits. Gere um sistema central de troca entre jogadores (trading) com validação anti-fraude, implementado prioritariamente em um único **Script** de servidor. O script principal deve ser colocado em **ServerScriptService**, por exemplo com o nome `TradingServer`. Ele deve criar ou localizar com segurança os RemoteEvents necessários em `ReplicatedStorage/Remotes` (sem duplicá-los caso já existam) e expor um contrato de comunicação claro para a UI do cliente. Não gere a interface gráfica completa; concentre-se no núcleo seguro do servidor e, ao final, documente quais RemoteEvents e argumentos um LocalScript de interface deve disparar. Se o meu contexto indicar RemoteEvents já existentes, reutilize exatamente os nomes e caminhos informados. Antes de gerar o código, considere e incorpore este contexto do meu jogo. Caso algum campo fique vazio ou inexistente, adote uma implementação padrão segura, declare a suposição antes do código e concentre os pontos de adaptação em uma seção `CONFIG` e/ou `InventoryAdapter` no início do Script: - Caminhos e nomes de objetos no Explorer: [COLE AQUI] - RemoteEvents/RemoteFunctions já existentes e seus argumentos: [COLE AQUI] - Estrutura do inventário (Folder/Value, tabela em ModuleScript, ProfileService, DataStore etc.): [COLE AQUI] - Como itens são identificados, quantidade máxima por stack e atributos de item: [COLE AQUI] - Regras de itens negociáveis, itens vinculados, raridades e moeda: [COLE AQUI] - Nome e local da moeda do jogador, se houver: [COLE AQUI] - Distância máxima para iniciar troca e demais regras de UX: [COLE AQUI] - Sistema de salvamento/persistência já usado pelo jogo: [COLE AQUI] Implemente uma máquina de estados explícita e validada no servidor, por exemplo: `Idle`, `InviteSent`, `Trading`, `Confirming`, `Committing`, `Completed`, `Cancelled`. Cada sessão deve possuir ID único, participantes fixos, timestamps, prazo de expiração e controle de versão/revisão da oferta. Um jogador não pode participar de duas sessões simultâneas. Convites devem expirar, poder ser recusados e ser invalidados caso o jogador saia do servidor. Toda desconexão deve cancelar a sessão e liberar bloqueios com segurança. O servidor deve ser a única autoridade para inventário, moeda, propriedade de item, quantidade, raridade, elegibilidade e conclusão da troca. Nunca aceite do cliente preço, saldo, dano, ID de item, quantidade ou estado de confirmação como verdade absoluta. Para cada chamada remota, valide rigorosamente: tipos Luau com `typeof`, jogador remetente, existência da sessão, participação na sessão, estado permitido, limite de tamanho da oferta, IDs válidos, quantidades inteiras positivas, limites por stack, posse atual do item, disponibilidade não reservada e regra de item negociável. Aplique rate limit por jogador e por ação, ignore/rejeite requisições excessivas e emita avisos no servidor para tentativas suspeitas. Implemente escrow/reserva lógica: ao adicionar um item ou moeda à oferta, marque a quantidade como reservada para impedir uso, venda, equipagem ou oferta concorrente enquanto a sessão existir. Não remova definitivamente os bens ao montar a oferta, mas revalide tudo no instante do commit. Qualquer modificação de item, quantidade ou moeda deve incrementar a revisão da oferta e resetar as confirmações dos dois jogadores. A confirmação só vale para a revisão atual e deve haver confirmação independente de ambos os participantes. Quando os dois confirmarem, execute uma transação atômica no servidor: bloqueie a sessão contra reentrada, revalide integralmente os dois inventários e saldos, aplique as transferências em uma ordem segura, trate falhas com rollback e só então finalize como concluída. Evite duplicação e perda de itens. Se o inventário persistente usar ProfileService/DataStore, não faça chamadas DataStore inseguras a cada clique; integre-se ao perfil carregado e descreva claramente onde o adaptador deve realizar a persistência. Não use `loadstring`, não confie em atributos alteráveis pelo cliente e não deixe RemoteEvents aceitarem tabelas arbitrárias sem sanitização profunda. Entregue primeiro uma breve lista de premissas e a arquitetura. Em seguida, entregue o código Luau completo, funcional, comentado e pronto para colar, exclusivamente dentro de um bloco markdown ` ```lua `. O código deve incluir criação/localização de remotes, configuração, tipos quando úteis, conexões `PlayerAdded`/`PlayerRemoving`, limpeza de sessões, expiração automática, logs administrativos e funções bem separadas. Não entregue pseudocódigo, trechos incompletos, `...`, nem dependências ocultas. Se precisar de um adaptador de inventário, implemente uma versão padrão funcional e deixe marcadores claros para a substituição pela minha estrutura. Depois do bloco de código, forneça: (1) tabela dos RemoteEvents e argumentos esperados pela UI cliente; (2) passos objetivos para conectar meu inventário real ao `InventoryAdapter`; (3) instruções detalhadas para testar no Roblox Studio usando `Test > Start` com dois jogadores, incluindo cenários de sucesso, cancelamento, desconexão, spam, alteração de oferta após confirmar, falta de saldo, item inválido e tentativa de dupla negociação; e (4) uma lista curta de limitações ou pontos que exigem adaptação ao meu sistema de persistência.
