O conteúdo a seguir abrange vários conceitos e táticas para melhorar a segurança e mitigar trapaças em suas experiências no Roblox. É altamente recomendável que todos os desenvolvedores leiam isso para garantir que suas experiências sejam seguras e justas para todos os usuários. Confira a barra lateral para tópicos adicionais de segurança.
A propriedade da rede é um dos aspectos mais sutis e comumente mal interpretados do motor Roblox. Quando um jogador tem a propriedade da rede de uma parte ou assembly, ele tem total autoridade sobre a simulação de física para esses objetos. Por padrão, o servidor concede a propriedade da rede de partes não ancoradas a clientes com personagens jogadores nas proximidades para distribuir a carga da simulação de física. Este sistema melhora a responsividade, mas cria implicações significativas de segurança que todo desenvolvedor deve entender.
Compreendendo a propriedade da rede
Quando um cliente tem a propriedade da rede sobre partes (incluindo seu personagem), ele tem acesso a:
Manipulação de assembly:
- Teleportar para qualquer posição.
- Isso pode ser usado para rapidamente obter propriedade e controle de quantas partes e assemblies não ancorados o servidor permitir.
- Manipular seu movimento e estado, como voar ou alterar sua velocidade.
- Exploradores podem definir sua Humanoid WalkSpeed para qualquer valor. As propriedades podem ser modificadas localmente sem disparar eventos no cliente local, e sem que tais alterações de propriedades possam ser lidas por scripts locais.
- Executar animações arbitrárias e manipular o estado da animação.
- Ignorar obstáculos físicos e alterar sua colisão.
Manipulação de física
- Controlar a posição e rotação de qualquer parte ou mecanismo não ancorado, incluindo replicar componentes Inf ou NaN em CFrames. Definir velocidades da parte para valores extremos (incluindo Inf ou NaN), o que pode interferir na física de outras partes/assemblies não ancoradas, mesmo aquelas que não são de propriedade do explorador. Isso é frequentemente usado para lançar outros personagens jogadores e partes próximas. Manipular a ativação de eventos Touched, incluindo não disparar Touched de forma alguma.
Caso sua experiência necessite de partes ou assemblies totalmente não ancorados e críticos para a jogabilidade, considere usar a API de propriedade da rede para configurar a propriedade manualmente ou desligar a propriedade automática.
Validação de movimento
Em experiências competitivas, a validação do movimento do jogador no lado do servidor é crucial para a integridade da simulação, uma vez que os clientes controlam o movimento e a física do personagem. No entanto, uma solução universal não existe devido à mecânica de gameplay variável.
Métodos tradicionais muitas vezes falham em cenários complexos. Cálculos simples de distância ao longo do tempo podem ser suficientes para tiros competitivos, mas falham em experiências intensivas em física que envolvem veículos, voo ou interações intrincadas. A validação também deve considerar a latência de rede.
A autoridade do servidor está atualmente em beta e será lançada em breve. A solução mais confiável para prevenir explorações de física e movimento é a autoridade do servidor, que move a simulação de física e a validação de movimento inteiramente para o servidor. Isso elimina a fraqueza de segurança fundamental do movimento controlado pelo cliente, garantindo que todas as decisões de movimento sejam tomadas no servidor com validação autoritativa.
Até que a autoridade do servidor se torne disponível, desenvolvedores que implementam validação do lado do cliente devem entender que abordagens eficazes variam drasticamente. Heurísticas básicas podem sinalizar jogadores inocentes com conexões instáveis, e cálculos de velocidade diretos falham em experiências com sistemas de movimento complexos. As atualizações de posição estão sujeitas à latência da internet, exigindo a média ao longo do tempo. Muitos desenvolvedores descobrem que acumuladores estilo balde furado funcionam bem para lidar com movimentos explosivos enquanto previnem violações sustentadas.
A implementação prática muitas vezes requer projetar o movimento em planos específicos (por exemplo, XZ para movimento no solo) para evitar penalizar o movimento vertical legítimo enquanto detecta teletransportes horizontais. Experiências com mecânicas legítimas de teletransporte precisam de sistemas de isenção explícita. A frequência de validação, níveis de tolerância e estratégias de aplicação devem ser ajustadas às necessidades específicas de cada experiência.