Sistema de Prestígio Tycoon com Bônus Permanentes
ESCOPO
Gere um sistema robusto de prestígio para tycoons Roblox: ao atingir um requisito de dinheiro, o jogador pode resetar sua base e receber níveis de prestígio com bônus permanentes. O resultado prioriza autoridade do servidor, persistência confiável e integração flexível com a arquitetura já existente no seu jogo.
O prompt solicita primeiro o contexto do Explorer, objetos, módulos e RemoteEvents do projeto, para evitar nomes inventados e dependências quebradas. Ele é indicado para desenvolvedores que já possuem um tycoon funcional e precisam adicionar uma camada de progressão avançada, segura e preparada para produção.
A resposta esperada inclui código Luau completo, comentado e pronto para colar no Roblox Studio, além de um roteiro prático para configuração e testes em ambiente local e publicado.
Conteudo
Prompt principal
Atue como um desenvolvedor Roblox Luau sênior, especializado em sistemas tycoon seguros, persistência com DataStoreService e arquitetura servidor-autoritativa. Quero implementar um sistema de prestígio/reset para o meu tycoon, no qual o jogador reseta o progresso atual da base ao cumprir um requisito financeiro e recebe bônus permanentes escaláveis. Antes de escrever o código, leia e use estritamente o contexto que vou colar abaixo. Não invente nomes de objetos, caminhos no Explorer, APIs de módulos, valores, RemoteEvents ou estruturas de dados que não estejam informados. Se algum dado essencial estiver ausente, faça primeiro uma lista objetiva de perguntas técnicas; somente após eu responder, gere a solução. Caso o contexto esteja completo, prossiga diretamente para o código. CONTEXTO DO MEU JOGO (vou preencher): - Onde o dinheiro do jogador é armazenado e qual é o nome exato do Value/atributo/leaderstats: [PREENCHER] - Estrutura e caminho dos tycoons no Explorer, incluindo como identificar o dono de cada base: [PREENCHER] - Como o reset atual da base funciona, se existir (funções, ModuleScripts, BindableEvents ou objetos destruídos/recriados): [PREENCHER] - RemoteEvents/RemoteFunctions existentes e respectivos caminhos: [PREENCHER] - Interface de prestígio existente, se houver, e caminho do botão/labels: [PREENCHER] - Sistema atual de salvamento, módulos de DataStore e formato do perfil: [PREENCHER] - Requisito inicial de dinheiro, crescimento do requisito por prestígio e fórmula desejada para bônus: [PREENCHER] - Quais bônus permanentes devem existir (ex.: multiplicador de renda, dinheiro inicial, velocidade de construção, desconto): [PREENCHER] - Limite máximo de prestígio, se houver: [PREENCHER] - Demais regras, restrições e nomes obrigatórios: [PREENCHER] Gere a implementação principal como um Script de servidor, a ser colocado em ServerScriptService, com um nome sugerido como PrestigeService.server.lua. Se o meu contexto exigir comunicação de interface, use exclusivamente os RemoteEvents já existentes; se nenhum RemoteEvent adequado existir, instrua exatamente como criar um RemoteEvent em ReplicatedStorage com um nome sugerido e deixe claro que ele serve apenas para solicitar a tentativa de prestígio. Não delegue nenhuma decisão de saldo, requisito, bônus, inventário, reset ou salvamento ao cliente. O Script deve implementar: carregamento e salvamento do número de prestígios e dos bônus permanentes; cálculo centralizado e configurável do requisito para o próximo prestígio; função pública ou local clara para obter multiplicadores do jogador; tentativa de prestígio acionada por RemoteEvent ou integração com o fluxo informado; validação de Player, estado de carregamento, valor monetário, propriedade da base, requisito financeiro, limite de prestígio e prevenção contra solicitações repetidas/spam; dedução ou reset do dinheiro conforme a regra fornecida; reset seguro da base chamando a integração real descrita no contexto; incremento atômico do prestígio; atualização imediata dos atributos/Values replicados necessários para UI; e notificação de sucesso ou falha usando apenas os canais existentes no projeto. Use DataStoreService com proteção por pcall, chaves por UserId, atualização segura com UpdateAsync quando apropriado, tentativas limitadas de retry e salvamento em PlayerRemoving e BindToClose. Evite sobrescrever dados carregados por outro sistema: se eu informar um ProfileService, DataStore wrapper ou módulo de dados existente, integre-se a ele em vez de criar um DataStore paralelo. Trate falhas de carregamento de modo conservador: um jogador sem dados confirmadamente carregados não pode prestigiar. Não use DataStore em loops, não faça yield dentro de callbacks críticos e não use waits arbitrários como mecanismo de sincronização. Siga rigorosamente segurança Roblox: o cliente pode apenas pedir uma tentativa; o servidor recalcula o requisito e confirma todo o estado real. Nunca aceite do cliente valores de dinheiro, nível de prestígio, multiplicador, nome de tycoon, quantidade de bônus ou indicação de que o reset foi concluído. Aplique rate limit por jogador para o RemoteEvent e limpe tabelas de estado quando o jogador sair. Proteja chamadas a módulos externos com validações e mensagens de warn úteis para desenvolvimento, sem expor dados sensíveis ao cliente. Entregue a resposta nesta ordem: 1) resumo curto da arquitetura e premissas adotadas; 2) lista de pré-requisitos e objetos que preciso criar ou conectar; 3) o código Luau integral, funcional e comentado, obrigatoriamente dentro de um único bloco markdown ```lua; 4) uma seção de integração indicando os pontos exatos em que devo adaptar chamadas ao reset do meu tycoon e à aplicação do multiplicador de renda; 5) instruções detalhadas para testar no Roblox Studio, incluindo teste com Start Server/Players, habilitação de API Services apenas em experiência publicada de teste, verificação de DataStore, spam do botão e reconexão do jogador. Não entregue pseudocódigo, trechos incompletos, placeholders de lógica crítica ou código de cliente inseguro. Quando houver uma dependência não especificada no contexto, marque-a em comentário com "ADAPTAR AO SEU PROJETO" e explique precisamente o que conectar, mantendo o restante do Script executável e coerente.
