¿Errores de principiantes más vistos en la programación de juegos multijugador / en línea?

Question

¿Qué tipo de errores de novato has visto y cuáles son las curas?

Uno que ocurre una y otra vez es que el cliente no se verifica de ninguna manera contra el servidor.

Por ejemplo:

• El usuario descompila la fuente del juego flash o escucha el tráfico de la red y ve dónde van los datos de puntaje alto y envía puntajes falsos allí, ni siquiera jugando el juego.
• El usuario usa el entrenador y obtiene un elemento que incluso puede no aparecer en el nivel actual. Esto se envió al servidor como " el cliente X obtuvo el artículo Y " y el servidor simplemente acepta eso.

La solución simple es, por supuesto, manejar el cliente de juegos solo como API para el servidor. Luego, el usuario puede usar los entrenadores y otras manipulaciones de la memoria que más les guste, pero el servidor simplemente dice que no puede hacerlo. Piensa en el servidor como una base de datos donde puedes consultar cosas con las reglas del juego.

Por ejemplo

• Cliente: comienza el juego
• Cliente: se conecta al servidor
• Cliente: consulta la cantidad de dinero disponible del servidor
• Usuario: habilita al entrenador que establece el dinero en infinito
• Cliente: server.buyItem ('muy caro')
• Servidor: verifica el estado del juego (el usuario puede comprar cosas ahora). Comprueba el jugador [0] .money - > sin bonificación.
• Cliente: server.buyItem ('puede obtener esto')
• Servidor: verifica el estado del juego (el usuario puede comprar cosas ahora). Comprueba el jugador [0] .money, ok. jugador [0] .items.add ('puede obtener esto') que reducirá el costo del jugador [0] .money. Luego informe al cliente enviar (jugador [0], 'elementos', 'puede obtener esto'); enviar (jugador [0], 'dinero', jugador [0] .money).

La otra forma es registrar los movimientos del cliente y enviarlo al servidor de mayor puntuación donde el servidor lo reproduce. Por supuesto, esto puede llevar a que el registro sea muy grande.

Answer 1

Sin duda, la confianza ciega del cliente. En un juego en el que estoy trabajando, ahora mantenemos toda la "lógica de negocios". del lado del servidor, y que las máquinas cliente solo nos envíen los comandos que están realizando; por ejemplo, "el jugador B quiere moverse a la derecha" - pero el servidor calcula cuán lejos a la derecha se movieron. Esto conlleva una sobrecarga de rendimiento (y, por supuesto, problemas con la demora que podrían manejarse mejor), por lo que un posible punto intermedio podría ser realizar los cálculos pesados ??en el lado del cliente, y aún tener controles en el servidor; por ejemplo, verificar si el jugador del cliente se está moviendo más de lo que supuestamente es posible en el tiempo entre actualizaciones; es decir, si la velocidad máxima del reproductor es de 200 unidades / segundo, si obtienes una actualización después de 0,5 segundos que dice que movieron 150 unidades, inicialas.

Por supuesto, esto no necesariamente impide que alguien codifique un bot para enviar esas pulsaciones de teclas, así que hay otras formas de protegerse contra esto. Sin embargo, no tener ninguna validación es en gran medida un error de novato (de lo cual, desde luego, fui culpable cuando tomé atajos)

Answer 2

El enfoque que tomó Valve (al menos, en un momento dado) fue hacer que los clientes y el servidor simulen el juego de forma independiente. Luego, el servidor realiza la simulación autorizada y envía actualizaciones de estado a todos los clientes para corregir sus errores / intentos de piratería.

Por ejemplo, si presionas la flecha izquierda tu personaje se moverá a la izquierda inmediatamente; no hay que esperar a que el servidor diga 'OK'. Pero si resulta que te has pirateado a través de un muro, la próxima actualización del servidor te hará aparecer justo al lado del muro, ya que el servidor lo ve como sólido.

De manera similar, si un cliente ve que un personaje avanza, asumirá que continuará avanzando hasta que el servidor regrese con una respuesta autorizada.

Este enfoque anula los intentos de piratería cuando el servidor toma las decisiones principales (y realiza comprobaciones de seguridad en el proceso de simulación), y también se ocupa del retraso cuando los clientes hacen predicciones hasta que obtienen información del servidor.

Otro gran error relacionado con 'confiar en el cliente' es pensar que su protocolo de red no puede ser falsificado. La gente tiende a suponer que si envían fragmentos binarios al servidor, estos fragmentos binarios nunca serán de ingeniería inversa, y que nadie intentará alterar los datos para ver qué sucede. Esto ha llevado a todo tipo de problemas.

Answer 3

Ustedes han cubierto todo lo que puede salir mal con los clientes que confían en el servidor. No se me ocurren otros problemas reales.

Entonces, en lugar de decirte qué puede salir mal, mira lo que puede ir bien.

Valve ha puesto mucho trabajo en su netcode . Léelo arriba