Tycoon Roblox Completo: Plots, Renda Automática e Upgrades
ESCOPO
Gere um sistema Tycoon robusto e pronto para produção no Roblox Studio, centralizando no servidor a posse de terrenos, economia, geração periódica de renda e progressão por upgrades. O prompt exige uma arquitetura configurável para se adaptar aos nomes, pastas, botões e RemoteEvents já existentes no seu projeto.
Ideal para desenvolvedores que desejam criar tycoons escaláveis sem confiar no cliente para dinheiro, compra de itens ou propriedade de plots. A resposta solicitada inclui um Script Luau completo, comentado, com validações anti-exploit, limpeza ao jogador sair, suporte a múltiplos terrenos e instruções práticas de instalação e testes.
Conteudo
Prompt principal
Atue como um desenvolvedor Roblox sênior, especialista em Luau, arquitetura servidor-autoritativa, segurança anti-exploit e sistemas Tycoon escaláveis. Gere um único Script Luau completo para o servidor que implemente compra e gerenciamento de plots, geração automática de dinheiro, coleta de caixa e upgrades de renda. TIPO E LOCAL DO SCRIPT: entregue um Script (não LocalScript e não ModuleScript) para ser inserido em ServerScriptService, com um nome sugerido como `TycoonService.server.lua`. O script deve ser autocontido e organizado em seções claras: configuração, descoberta/validação da hierarquia, controle de dados em memória, posse de plots, economia, produção, compras, limpeza e conexão de eventos. Use apenas APIs padrão do Roblox, sem dependências externas. Não gere código de interface local; a interação de compra deve funcionar pelo servidor usando ProximityPrompt ou ClickDetector presentes nos botões físicos do mapa. Se meu contexto já possuir um sistema de UI/RemoteEvent, integre-o apenas como camada opcional de atualização visual, sem transferir autoridade ao cliente. Antes de escrever o código, considere e respeite o contexto do meu jogo abaixo. Caso eu deixe algum dado ausente, não faça perguntas de acompanhamento: crie valores configuráveis no topo do Script, documente suposições em comentários e implemente fallbacks seguros. === CONTEXTO DO MEU JOGO (PREENCHEREI ANTES DE ENVIAR) === - Pasta dos plots no Workspace e estrutura interna de cada plot: - Como identificar cada plot (atributo, nome, ID etc.): - Peça/objeto de compra inicial do terreno: - Peça/objeto usado para coletar o dinheiro acumulado: - Pasta ou objetos dos botões de upgrade: - Formato de cada upgrade (Attributes, IntValues, nomes, custos e efeitos): - Leaderstats/moeda já existente (nome da moeda e onde fica): - RemoteEvents/RemoteFunctions existentes e respectivos locais: - Sistema de DataStore já existente, se houver: - Regras desejadas de preço inicial, renda base, intervalo de produção, limite de caixa e multiplicadores: - Outros detalhes relevantes: === FIM DO CONTEXTO === REQUISITOS FUNCIONAIS OBRIGATÓRIOS: 1. Ao jogador entrar, encontre um plot livre, atribua a posse exclusivamente no servidor e atualize um atributo `OwnerUserId` ou mecanismo equivalente. Se não houver plot disponível, informe de maneira segura via warn e/ou RemoteEvent opcional. 2. A compra do plot deve exigir saldo suficiente. O servidor deve validar jogador, plot, distância razoável do jogador ao gatilho, valor da moeda, estado atual de posse e cooldown anti-spam antes de descontar dinheiro. Nunca aceite preço, UserId, quantidade de dinheiro, plot ou upgrade enviados pelo cliente como verdade. 3. Após a compra, habilite os elementos do tycoon daquele dono. Itens desbloqueáveis devem iniciar ocultos/inativos quando aplicável, enquanto botões de upgrade só podem ser usados pelo proprietário do plot. Preserve uma estratégia configurável para transparência, colisão e prompts dos objetos. 4. Implemente geração automática de dinheiro por plot em intervalos configuráveis. A renda deve considerar uma renda base, upgrades de droppers/renda e multiplicadores. Acumule o valor em uma variável de caixa do plot, apresente-o em Attribute/IntValue configurável para integração visual e permita coleta apenas ao dono. 5. Implemente upgrades configuráveis por tabela no topo do código, incluindo ao menos: aumento de renda base, multiplicador de produção e aumento de capacidade de caixa. Cada upgrade deve ter custo inicial, crescimento de custo, nível máximo e efeito por nível. O servidor deve validar saldo, nível, propriedade e cooldown antes de aplicar qualquer alteração. 6. Ao jogador sair, liberar o plot, parar ou invalidar processos vinculados a ele, zerar dinheiro acumulado conforme configuração e restaurar o estado visual/funcional inicial. Trate também CharacterAdded para manter a segurança da interação. Não use loops infinitos por jogador sem controle; use `task.spawn`, `task.wait` e verificações de estado para loops de produção canceláveis. 7. Caso existam RemoteEvents no contexto, valide rigorosamente `typeof`, instâncias, ancestralidade, propriedade do plot, distância, limites numéricos e frequência antes de qualquer ação. RemoteEvents podem notificar cliente sobre saldo coletado, compra aceita ou falha, mas não podem conceder moeda, comprar upgrades ou definir posse sem nova validação integral no servidor. QUALIDADE E ENTREGA: use Luau idiomático, `--!strict` quando viável, `WaitForChild` com cuidado, `Attributes`, tipos quando agregarem clareza e funções pequenas com responsabilidade definida. Comente decisões críticas de segurança e os pontos que preciso adaptar no Explorer. Evite pseudocódigo, trechos omitidos, funções fictícias e dependências não fornecidas. O código deve estar integralmente dentro de um único bloco markdown ```lua. Após o bloco, forneça instruções objetivas para instalar o Script, configurar a estrutura esperada no Explorer, testar com dois jogadores usando o modo Start Server/Start Player no Roblox Studio e validar tentativas comuns de exploit.
