Loja Roblox Segura com Moeda, Estoque e Validação Server-Side
ESCOPO
Este prompt gera uma arquitetura profissional de loja para Roblox, preparada para compras de itens utilizando uma moeda interna do jogo. O sistema prioriza segurança server-side, impedindo que exploits no cliente alterem preços, saldo, estoque ou recompensas concedidas.
Ideal para desenvolvedores que já possuem ou estão criando um simulador, RPG, tycoon, survival ou qualquer experiência com economia. O prompt solicita o contexto específico do projeto — como nomes de RemoteEvents, pastas, moedas e itens — e devolve scripts Luau completos, comentados e prontos para posicionar no Roblox Studio.
Além da lógica de compra, o resultado deve incluir validações robustas, proteção contra spam de requisições, tratamento de falhas, sincronização de interface e instruções detalhadas de instalação e testes multiplayer.
Conteudo
Prompt principal
Atue como um desenvolvedor Roblox Luau sênior, especializado em sistemas econômicos seguros, arquitetura cliente-servidor e prevenção contra exploits. Crie uma implementação completa de uma loja de itens compráveis com moeda interna do jogo, adaptada ao contexto do meu projeto que fornecerei abaixo. O resultado deve ser código de produção, legível, modular quando necessário, comentado em português e pronto para colar no Roblox Studio. Antes de escrever o código, considere e utilize este contexto do meu jogo. Se algum campo estiver vazio, escolha uma convenção Roblox segura, declare explicitamente a suposição adotada e mantenha os nomes fáceis de substituir: - Moeda e localização: [ex.: leaderstats/Coins, ProfileService, atributo Coins no Player] - Nome da moeda exibida: [ex.: Coins, Gold, Gemas] - Itens vendidos e preços: [ex.: Sword=250, Potion=50, VIPTrail=1000] - Tipo de recompensa por item: [Tool no ServerStorage, atributo/valor no inventário, consumível, passe interno, cosmético] - Localização dos templates dos itens: [ex.: ServerStorage/ShopTools] - RemoteEvents/RemoteFunctions já existentes e suas localizações: [preencher] - Interface existente e hierarquia no Explorer: [ex.: StarterGui/ShopGui/Frame/ItemsList] - Como a loja é aberta: [ProximityPrompt, botão GUI, NPC, tecla] - Estoque: [ilimitado ou limitado; quantidade por item] - Recompra: [permitida ou compra única por jogador] - Persistência disponível: [DataStore próprio, ProfileService, nenhuma] - Nomes exatos de objetos/pastas que não podem ser alterados: [preencher] Implemente o sistema como um pacote organizado de scripts. Defina obrigatoriamente o TIPO e o local exato de cada arquivo no Explorer antes do código. Use esta arquitetura, salvo se o contexto acima exigir adaptação justificada: 1. ModuleScript `ShopCatalog`, em `ReplicatedStorage/Shared`, contendo somente a configuração pública e não sensível do catálogo para a UI: ID estável, nome de exibição, descrição, preço, ícone, categoria e dados de apresentação. O cliente pode ler preços para exibir, mas o servidor deve possuir ou importar uma fonte de verdade equivalente e nunca aceitar preço enviado pelo cliente. 2. Script `ShopServer`, em `ServerScriptService`, responsável por criar/encontrar os RemoteEvents necessários, validar compras, consultar saldo, debitar moeda, controlar estoque, conceder itens e responder com resultados estruturados. 3. LocalScript `ShopClient`, em `StarterPlayer/StarterPlayerScripts` ou dentro da `ShopGui` em `StarterGui` (escolha a opção mais adequada à hierarquia informada), responsável apenas pela interface, abertura/fechamento, renderização dinâmica da lista, envio do ID do item ao servidor e feedback visual. Ele nunca pode conceder item, alterar moeda nem decidir se uma compra é válida. 4. Se necessário, inclua um ModuleScript adicional de adaptador para moeda/inventário, explicando como conectá-lo ao meu sistema atual sem duplicar dados. A compra deve funcionar por RemoteEvent ou RemoteFunction com contrato claro. O cliente deve enviar apenas o `itemId`; não envie preço, quantidade de moeda, Tool, instância arbitrária ou qualquer dado de autoridade. No servidor, valide rigorosamente: jogador válido, tipo e tamanho do ID, existência do item no catálogo autorizado, preço inteiro não negativo, saldo atual obtido exclusivamente no servidor, limite de compra única, estoque disponível e possibilidade de entrega. Implemente cooldown/rate limit por jogador para evitar spam e compras duplicadas. Use uma trava por jogador durante a transação. Garanta uma ordem transacional segura: validar tudo, reservar/registrar estoque quando aplicável, debitar saldo, conceder a recompensa e realizar rollback coerente caso a entrega falhe. Nunca confie em valores de `LocalPlayer`, atributos editáveis pelo cliente ou argumentos de RemoteEvent para moeda, dano, inventário, preço ou estoque. Para Tools, mantenha templates exclusivamente no servidor, preferencialmente em `ServerStorage`, faça `:Clone()` somente após aprovação e entregue em `Backpack` e/ou `StarterGear` conforme eu indicar. Evite duplicatas em Backpack, Character e StarterGear quando a compra for única. Para consumíveis e itens de inventário, apresente um ponto de integração seguro e sinalize exatamente onde devo conectar meu DataStore/ProfileService. Não use DataStore em LocalScript. Não use `loadstring`, HTTP externo, loops desnecessários, `wait()` legado ou APIs depreciadas. A UI deve tratar respostas de sucesso e erro com mensagens como saldo insuficiente, item inválido, estoque esgotado, compra já realizada, solicitação muito rápida e erro interno. Inclua atualização visual do saldo e do estado do botão/item depois de uma compra. Se minha GUI não estiver pronta, crie uma estrutura mínima baseada em `ScreenGui`, `Frame`, `ScrollingFrame`, template de botão e labels, explicando os nomes obrigatórios. Não presuma que objetos existem sem usar `WaitForChild` com cuidado, verificações e mensagens de diagnóstico úteis. Entregue a resposta nesta ordem: (1) resumo da arquitetura e premissas; (2) árvore exata do Explorer; (3) cada arquivo completo, sem pseudocódigo, em blocos markdown separados no formato ```lua, com título contendo tipo e caminho; (4) tabela curta dos Remotes e seus argumentos; (5) passos de instalação; (6) plano de testes no Roblox Studio, incluindo Start Server com múltiplos Players, saldo insuficiente, tentativa de item/ID falso via cliente, spam de RemoteEvent, estoque final e falha de entrega; (7) checklist de segurança. Não omita trechos essenciais, não entregue código parcial e não utilize código fora dos blocos Lua, exceto pelas instruções solicitadas.
