Obby Dinâmico: Plataformas, Armadilhas e Obstáculos Luau
ESCOPO
Gere um controlador robusto para obstáculos de obby no Roblox, incluindo plataformas com movimento entre pontos, plataformas que desaparecem, espinhos, lasers, peças rotativas, empurradores e zonas de dano. O sistema é orientado por pastas, Attributes e Tags, permitindo configurar mapas sem editar o código a cada novo obstáculo.
Ideal para desenvolvedores que querem uma base profissional, segura e escalável para obbies, towers e mapas de parkour. O prompt solicita o contexto específico do Explorer do projeto e força a IA a entregar um Script Luau de servidor comentado, pronto para colar, acompanhado de instruções objetivas de configuração e testes no Roblox Studio.
Conteudo
Prompt principal
Atue como um desenvolvedor Roblox sênior, especialista em Luau, Roblox Studio, sistemas multiplayer servidor-autoritativos, física de personagens e arquitetura escalável para obbies. Gere um único Script Luau completo, robusto, comentado e pronto para ser colado no Roblox Studio. O script deve ser do tipo **Script** e deve ser colocado em **ServerScriptService**, com o nome sugerido `ObbyObstacleController`. Ele será o controlador central de plataformas móveis, armadilhas e obstáculos dinâmicos. Não crie LocalScript como dependência obrigatória e não delegue decisões importantes ao cliente. Caso meu contexto mencione RemoteEvents ou RemoteFunctions, utilize-os somente se forem realmente necessários e valide integralmente no servidor qualquer dado recebido; nunca confie no cliente para dano, checkpoints, recompensa, inventário, moedas, teleporte ou estado de conclusão. Antes de gerar o código, considere e incorpore o contexto abaixo. Se algum campo estiver vazio, assuma uma estrutura padrão sensata e documente claramente essa suposição após o código: - Pasta principal do mapa/obby no Workspace: `[COLE_AQUI]` - Pasta das plataformas móveis: `[COLE_AQUI]` - Pasta das armadilhas: `[COLE_AQUI]` - Pasta dos obstáculos rotativos/dinâmicos: `[COLE_AQUI]` - Nomes ou caminhos de Models/Parts relevantes no Explorer: `[COLE_AQUI]` - RemoteEvents/RemoteFunctions existentes e finalidade: `[COLE_AQUI]` - Sistema de dano/vida já existente (se houver): `[COLE_AQUI]` - Checkpoints, spawn e regras de respawn: `[COLE_AQUI]` - Convenções de Tags via CollectionService já usadas: `[COLE_AQUI]` - Convenções de Attributes já usadas: `[COLE_AQUI]` - Restrições de desempenho, quantidade estimada de jogadores e dispositivos-alvo: `[COLE_AQUI]` Projete o sistema para ser configurável por **Attributes** nos Models ou BaseParts, evitando caminhos rígidos no código sempre que possível. Use `CollectionService` para detectar objetos por Tags e suporte, no mínimo, as seguintes tags e configurações. Caso os nomes conflitem com minhas convenções, priorize o contexto que forneci: 1. Tag `MovingPlatform`: move uma Part ou Model entre `PointA` e `PointB` (BaseParts filhos ou referências via ObjectValue), com Attributes `Speed`, `WaitTime`, `LoopMode` (`PingPong` ou `Loop`) e `EasingStyle` quando aplicável. 2. Tag `DisappearPlatform`: plataforma que detecta toque de personagem, aguarda `DisappearDelay`, fica sem colisão e invisível por `ResetTime`, e retorna de forma segura. Inclua proteção contra múltiplos toques concorrentes. 3. Tag `DamageTrap`: peça ou Model que causa dano configurável por `Damage`, com cooldown individual por jogador definido em `HitCooldown`. Se `InstantKill` for verdadeiro, elimine o Humanoid de maneira controlada no servidor. 4. Tag `RotatingObstacle`: haste, braço ou Model rotativo em torno de um pivô, configurado por `RotationSpeed`, `RotationAxis` e, se necessário, `Direction`. 5. Tag `PushObstacle`: obstáculo que aplica impulso físico seguro e limitado ao personagem, configurado por `PushForce`, `PushDirection` e `PushCooldown`. Use APIs modernas e evite `BodyVelocity` legado quando houver alternativa adequada. O controlador deve funcionar com Parts e Models. Para Models, use `PrimaryPart` ou `GetPivot`/`PivotTo` de maneira apropriada e explique no comentário de configuração como preparar cada Model. Movimentações contínuas devem usar `TweenService` quando isso for apropriado, com comportamento previsível no servidor. Para obstáculos físicos, considere ownership de rede, ancoragem e colisões para evitar resultados inconsistentes. Não use loops pesados por objeto com `while true do` sem controle; prefira conexões, tarefas gerenciadas, Tween callbacks e inicialização modular dentro do mesmo arquivo. Trate objetos adicionados dinamicamente por Tags durante a execução quando viável. Implemente funções utilitárias claras para: encontrar o Humanoid e Player a partir de uma peça tocada; aplicar dano com debounce por jogador e por armadilha; ler Attributes com valores padrão e validação de tipo/faixa; localizar pontos de movimento; registrar cada tipo de obstáculo; e emitir avisos úteis com `warn` para configuração inválida, sem derrubar todo o sistema. Previna vazamentos de conexões e garanta que personagens mortos, removidos ou respawnados não gerem erros. Entregue a resposta nesta ordem: 1. Uma seção breve chamada `Estrutura esperada no Explorer`, explicando pastas, Tags, Attributes e preparação dos pontos/pivôs. 2. O código integral em **um único bloco Markdown** exatamente no formato ```lua ... ```. Não use pseudocódigo, trechos omitidos, `...`, nem funções incompletas. Inclua comentários em português no código, especialmente nas áreas que o usuário poderá configurar. 3. Uma seção `Como testar no Roblox Studio` com passos práticos: criar Tags/Attributes, testar com Play e Start Server/Players, verificar Output, validar dano, movimento, reset e comportamento multiplayer. 4. Uma seção curta `Ajustes recomendados`, indicando quais Attributes alterar para mudar velocidade, dano, tempos e força. Priorize compatibilidade com APIs atuais do Roblox, legibilidade, tolerância a erros de configuração, desempenho para vários jogadores e segurança multiplayer. Não invente sistemas externos, assets ou RemoteEvents que não sejam necessários. Se o contexto fornecido estiver incompleto, entregue uma implementação funcional baseada na estrutura padrão e destaque todas as suposições feitas.