Estoy desarrollando un juego de cartas simple, donde habrá un sistema de emparejamiento que te pondrá en contra de otro jugador humano. Este será el único modo de juego disponible, un 1vs1 contra otro humano, sin IA.
Quiero evitar las trampas tanto como sea posible. Ya he leído muchas preguntas similares aquí y ya sé que no puedo confiar en el cliente y tengo que hacer todas las verificaciones del lado del servidor. Tengo la intención de tener un servidor (de todos modos necesito uno para el emparejamiento) y tengo la intención de hacer algunas verificaciones del lado del servidor, pero si quiero verificar todo el lado del servidor, esto hace que mi servidor pueda realizar un seguimiento del estado de todos los juegos actuales y verifico cada acción, y no tengo el dinero / infraestructura para soportar ese servidor.
Mi idea es hacer que los clientes verifiquen y verifiquen algunas de las acciones realizadas por su oponente * y, si encuentran alguna acción ilegal, notifiquen la posible trampa al servidor y hagan que el servidor lo verifique. Esto aún requerirá que mi servidor haga un seguimiento de todos los juegos actuales, pero ahorrará recursos solo al verificar algunas cosas que no se pueden verificar en el lado del cliente (como el orden de las cartas en el mazo) y solo verificar otras cosas cuando realmente están mal.
* (¡solo aquellos que pueden verificar sin permitirse hacer trampa! por ejemplo: no pueden verificar si la carta jugada estaba en la mano porque necesitarán que sepan todas las cartas en la mano)
En resumen, mis preguntas son : ¿es este un enfoque viable? ¿realmente ahorraré recursos al hacer esto o la complejidad adicional en el servidor y el cliente para intercambiar estos mensajes no vale la pena? ¿Conoces algún juego que haya probado con éxito o sin éxito un enfoque similar?
Gracias a todos por leer y responder
fuente
Respuestas:
Dependiendo de la complejidad de su juego, verificar si una acción es legal o no puede requerir retroceder grandes partes del juego. Un ejemplo: el jugador A dice que el jugador B no puede jugar esa carta en este momento porque no tiene ResourceX. PlayerB dice que tiene muchos recursos ResourceX. ¿Quién tiene la razón? Para descubrirlo, simularía todo el juego nuevamente de principio a fin para contar el ResourceX que tiene el PlayerB en este momento. Por lo tanto, solo verificar las acciones de los jugadores cuando uno grita "falta" podría no ser una gran optimización.
¿Pero realmente vale la pena el esfuerzo?
Creo que podría tener un caso de optimización prematura aquí. Aunque no sé exactamente qué estás haciendo, un juego de cartas no suele ser tan costoso desde el punto de vista del servidor.
Los juegos de cartas suelen estar diseñados para jugar sin soporte informático, por lo que su mecánica de juego suele ser lo suficientemente simple como para ser realizada por humanos *. Además, los jugadores humanos suelen tardar varios segundos en hacer un movimiento, lo que parece una eternidad para el servidor. Eso significa que su servidor solo tiene una tarea ligera que realizar cada pocos segundos por juego. No sé cuántos jugadores simultáneos esperas, pero mientras sigas en la escala de un proyecto de afición no comercial, dudo que incluso el servidor más barato que puedas encontrar no pueda manejarlo. En la premisa, por supuesto, que sabes cómo programar eficientemente.
*) siempre y cuando excluya la toma de decisiones de los jugadores. La mayoría de los juegos se basan en la premisa de que la estrategia ganadora ideal puede calcularse teóricamente, pero hacerlo es tan complejo que los jugadores y, a menudo, incluso las computadoras no pueden hacerlo, por lo que deben usar la intuición. Pero dijiste que no quieres IA y solo quieres jugador contra jugador, así que esto está fuera del alcance de esta pregunta. Pero también hace que uno piense en otro aspecto de trampa: ¿Consideró que un jugador usa un programa para ayudarlo con la toma de decisiones? ¿Como uno que les dice la probabilidad exacta de que el oponente tenga una determinada carta en la mano?
fuente
"Quiero evitar las trampas tanto como sea posible". - Así que decir que todos. :)
Quizás un enfoque más sensato es no perder el tiempo haciendo nada más allá de las medidas razonables y generalmente efectivas contra las trampas.
Esos son: hacer una doble prueba de errores que permitirían a los jugadores realizar cualquier acción ilegal, y enviar solo datos cifrados (a través de https o cifrado personalizado), y cifrar la aplicación para hacer que el pirateo sea más difícil. Eso es.
Los jugadores tienen más probabilidades de engañar a través de errores en el juego que cualquier otra cosa.
Simplemente podría hacerlo mejor, en cuanto al desarrollo, para esperar si sus jugadores realmente se preocupan lo suficiente como para hacer trampa. Si la aplicación no está en un "top 500 chart" figurativo y las trampas no son simples (es decir, errores), los jugadores no se preocuparán lo suficiente como para perder el tiempo tratando de engañar a través de otras medidas, como modificar el flujo de IP o piratear el aplicación
A menos, por supuesto, que esté tratando con dinero real y premios reales aquí.
Si su aplicación es exitosa y la trampa se convierte en un problema, entonces es cuando debe abordarla. Pero en este punto será un juego de gato y ratón, y los tramposos siempre ganarán.
Básicamente, lo que digo es que el 100% de tus jugadores no harán trampa si no es posible a través de un error reproducible y / o tu aplicación no es muy popular. Si su aplicación se vuelve muy popular, menos del 1% de sus jugadores engañarán de formas que ni siquiera puede comenzar a imaginar.
Entonces, en lo que respecta a las trampas, debe protegerse contra las trampas obvias (errores, encriptar tanto la aplicación como la transmisión de IP) y solo reaccionar a las trampas reales que conozca y abordarlas directamente. Lo que realmente desea es registrar todas las acciones de los jugadores, hacer que verifiquen en el servidor y si encuentra una acción ilegal que ocurre con bastante frecuencia, averigüe por qué. Podría ser un error, podría ser un exploit, podría ser un truco técnico.
La medida anti-trampa más importante es aprender que los jugadores realmente HACEN trampas, y cómo.
fuente
Creo que te encuentras con otros problemas aquí. ¿Qué sucede si el jugador finge ser un cliente normal (simulando el tráfico de su red) y está usando para corromper su juego por una validación incorrecta?
En lugar de tratar de construir un sistema cliente a prueba de balas, que lo llevará a la corrección y prohibición continua de errores / exploits, trataría de simplificar el sistema del servidor. No sé lo suficiente sobre su mecánica de juego, pero tal vez pueda reducir al mínimo la información en el servidor.
En general, debe suponer que el cliente con el que está hablando podría implementar cualquier código y mecánica de juego que parezca que se implementa. Y esto hace que la validación del lado del cliente sea casi imposible
fuente
Depende un poco de lo que consideres trampa. ¿Está usando una herramienta para hacer / calcular los movimientos? ¿Es para cambiar el mazo de cartas durante el juego? Lo primero será difícil de abordar. Para el segundo, puede pensar en hacer que cada usuario inserte sus tarjetas y cree un código hash que se muestre en ambos lados. Al final, el servidor puede calcular el hash con las cartas jugadas y las cartas restantes. Si un hash no coincide, el usuario ha hecho trampa. Si no se siguieron las reglas, también puede verificar esto en su servidor. Puede hacer esto en una solicitud del usuario para ahorrar recursos. No hay información disponible sobre las tarjetas. Para hacer que la generación del hash sea un poco más única / compleja, puede incluir el nombre de usuario en el hash.
fuente