El siguiente contenido cubre varios conceptos y tácticas para mejorar la seguridad y mitigar el engaño en tus experiencias en Roblox. Se recomienda encarecidamente que todos los desarrolladores lean esto para garantizar que tus experiencias sean seguras y justas para todos los usuarios. Consulta la barra lateral para temas de seguridad adicionales.
Esta sección asume que ya validas entradas y contexto (consulta secciones anteriores). Este artículo cubre qué hacer después de que una solicitud sea técnicamente válida pero su comportamiento parezca abusivo, además de cómo responder sin perjudicar a los jugadores legítimos.
Filosofía
- El servidor decide. La detección y las consecuencias residen en el servidor. Intenta nunca banear en base a detecciones del lado del cliente, ya que los explotadores pueden eludirlas fácilmente.
- Prevén el daño primero. Neutraliza silenciosamente el impacto de un exploit. Por ejemplo, si un jugador está usando un hack de velocidad, simplemente devuélvelo a su última posición válida en lugar de expulsarlo inmediatamente. Castiga solo cuando sea necesario para proteger la experiencia u otros jugadores.
- Sé proporcional y reversible. Supone que pueden ocurrir falsos positivos. Prefiere acciones que puedas revertir, como suspensiones temporales o eliminación de recursos, en lugar de prohibiciones permanentes.
- Diseño > detección. Tu seguridad primaria proviene de una validación robusta y limitación de tasa (cubierto en Asegurando el límite cliente-servidor y otras secciones). Los métodos de detección a continuación están destinados a complementar esas defensas, no a reemplazarlas.
Heurísticas
Las heurísticas son verificaciones de comportamiento que flagran acciones que son técnicamente posibles pero altamente improbables para un jugador legítimo. Son "reglas generales" para atrapar actividad sospechosa que se escapa de la validación básica. Una heurística efectiva compara la acción de un jugador contra un máximo teórico o una línea base razonable.
Por ejemplo, si un jugador de repente afirma haber ganado 1 billón de monedas en tu juego de simulación, tu validación remota podría confirmar que la solicitud está estructurada correctamente. Pero una verificación heurística en el servidor sabría que ganar tanto debería tomar semanas, no segundos, y marcaría la transacción como sospechosa.
Aquí hay tres ejemplos clásicos de heurísticas del lado del servidor. Cada una valida el comportamiento del jugador contra las reglas y limitaciones físicas de la experiencia, creando una defensa sólida contra exploits comunes.
| Heurística del lado del servidor | Descripción | Ejemplo |
|---|---|---|
| Tiempo de finalización más rápido | Calcula el tiempo teórico más rápido posible para completar una tarea, como un curso de obstáculos. Esto implica encontrar el camino óptimo y asumir la velocidad máxima del jugador. | En un obby, si el récord mundial es de 30 segundos, un tiempo de finalización de 5 segundos es una fuerte señal de teletransportación o exploits de velocidad. |
| Tasa de ganancia | Rastrear la tasa máxima legítima a la que un jugador puede ganar un recurso (moneda, experiencia, artículos). | Si un jugador puede ganar legítimamente 100 monedas por minuto, una ganancia repentina de 10,000 monedas en un segundo debería ser marcada. |
| Cadencia de acción | El servidor analiza los intervalos de tiempo entre las acciones repetidas de un jugador. Las entradas humanas tienen variaciones naturales y ligeras en el tiempo, mientras que los scripts de automatización simples (como los auto-clickers) a menudo realizan acciones con consistencia robótica. | En un minijuego de pesca, un jugador hace clic para lanzar su línea. El servidor registra la marca de tiempo de cada lanzamiento. Si el jugador lanza su línea 100 veces seguidas con el mismo intervalo exacto (por ejemplo, precisamente 2.500 segundos) entre cada acción, es un fuerte indicador de un macro o bot. El tiempo de un humano fluctuaría naturalmente. |
Cualquiera de estos ejemplos puede no ser suficiente por sí solo para condenar a un tramposo. Cada uno debe ser tratado como una señal, no como prueba definitiva. Una buena práctica es implementar un puntaje de sospecha. Cuando un jugador falla en una verificación heurística, incrementas su puntaje. Acciones severas como expulsar o banear deberían ocurrir solo después de que múltiples detecciones variadas hayan empujado el puntaje de un jugador más allá de un umbral alto.
Por ejemplo, supongamos que un jugador habilidoso termina tu obby con un tiempo récord impactante, activando tu heurística de "Tiempo de finalización más rápido". ¿Deberían ser baneados? Es posible que estén haciendo trampa, pero también podrían haber descubierto un atajo legítimo pero no intencionado. Banjarlos basado en esta única señal sería arriesgado y podría castigar a uno de tus jugadores más dedicados.
Sin embargo, si la carrera de ese mismo jugador también activó la heurística de "Cadencia de acción" por entradas inhumanamente consistentes, y una hora después activan la heurística de "Tasa de ganancia" en tu vestíbulo, el caso se vuelve mucho más fuerte. La combinación de estas diferentes señales pinta un cuadro mucho más confiable de tramposos. La fuerza de este sistema radica en correlacionar múltiples puntos de datos para construir un caso confiado antes de tomar acción.
Honeypots
Una forma de detectar tramposos que intentan sondear los RemoteEvents de tu experiencia es usar un señuelo llamado honeypot. Un honeypot es un RemoteEvent o RemoteFunction que parece legítimo para un explotador pero que nunca es utilizado por ninguno de tus scripts de cliente legítimos. Dado que ningún jugador normal debería poder activar este remoto, cualquier tráfico que reciba debe ser de un explotador. Cuando el servidor detecta que este remoto es activado, es una señal de muy alta confianza de que el cliente está interfiriendo. La mejor acción inmediata es registrar el incidente y expulsar al jugador de la sesión.
Otra variación es diseñar RemoteEvents con propósitos direccionales específicos: algunos exclusivamente para la comunicación cliente → servidor y otros exclusivamente para la comunicación servidor → cliente. Aunque los nombres de los eventos no revelan su dirección pretendida, el servidor rastrea en qué dirección debe usarse cada remoto. Si un explotador intenta activar un remoto servidor → cliente desde el cliente, esto sirve como un método de detección confiable, ya que el juego legítimo nunca activaría comunicación en la dirección equivocada.
Aplicación de consecuencias
Cuando los sistemas de detección flagran comportamientos sospechosos, considera cuidadosamente tu estrategia de respuesta. Diferentes experiencias requieren diferentes enfoques en función de su comunidad, las apuestas competitivas y la tolerancia a la interrupción.
La escalera de consecuencias - La mayoría de las experiencias se benefician de respuestas escalonadas en lugar de saltar directamente a prohibiciones permanentes:
- Registro silente - Construir evidencia sin impacto en el jugador
- Mitigación silenciosa - Bloquear el efecto del exploit (rechazar solicitudes, limitar valores, sincronizar el estado correcto)
- Restricciones temporales - Limitar capacidades específicas (comercio, tablas de clasificación, emparejamiento)
- Ejecutar medidas visibles - Expulsiones, suspensiones temporales o prohibiciones permanentes
Consideraciones para tu estrategia
- Retrasa las consecuencias visibles para evitar enseñar a los explotadores exactamente qué desencadenó la detección
- Iguala la gravedad a la respuesta - exploits económicos menores pueden requerir un tratamiento diferente a los cheats físicos que rompen el juego
- Considera tu comunidad - experiencias competitivas pueden necesitar una aplicación más estricta que experiencias casuales
- Planifica para errores - preferir acciones reversibles cuando la confianza de detección es más baja
Para infractores persistentes, considera utilizar la API Ban en lugar de confiar únicamente en las expulsiones. La API de baneo evita que los jugadores baneados vuelvan a unirse y proporciona un mejor rastreo a través de tu universo. Versiona tus reglas de detección y rastrea tasas de consecuencias para que puedas identificar sistemas problemáticos. Monitorea la retroalimentación de los jugadores para evaluar si tu aplicación se siente justa para la comunidad. El equilibrio adecuado depende completamente de las necesidades de tu experiencia y de las expectativas de tus jugadores.