Añadiendo a lo que dijo Larry, definitivamente va a tener que manejar el marcador en el el backend para evitar realmente la publicación de trampas/puntaje falso.
Para tener un ejemplo de esto en la práctica ... El juego Word Wars es un juego al estilo boggle donde puedes encontrar tantas palabras como puedas de una cuadrícula de letras 4x4.
Al comienzo de cada juego, se genera una tabla 4x4 del lado del servidor. Se genera una lista de posibles palabras para esa placa y se pasa al cliente una versión hash (md5'd con una sal aleatoria) de cada palabra, así como la sal.
En el lado del cliente, cuando se escriben las letras y se presiona la tecla enter, md5 (con la sal del servidor) la palabra que se ingresó y se compara con la lista de palabras hash provistas por el servidor. Si es una coincidencia, actualizamos al cliente con la nueva puntuación (hay una función basada en las letras utilizadas y sus valores de puntos).
Una vez que el juego termina, el cliente envía la lista de palabras que se le ocurrió al servidor (NO el puntaje), y el servidor verifica que esas palabras existían en el tablero y maneja la puntuación.
Aquí es donde entra Clay.io, la empresa en la que trabajo. Clay.io ofrece una API para funciones de juegos HTML5 de alto nivel, como tablas de clasificación, logros, procesamiento de pagos, etc. No hace falta decir que necesitaba una solución para juegos que tienen un back-end para hacer que ciertas cosas, como puntajes altos, sean más seguras.
La solución fue cifrar objetos de JavaScript en el back-end (node.js, php, lo que sea) usando JWT (JSON Web Token), y pasar ese objeto cifrado en lugar de la puntuación en sí. Esto nos permite comunicarnos en ambos sentidos (juego -> Clay.io y Clay.io -> juego), y es bastante fácil de hacer. Los documentos completos en esto son aquí: clay.io/docs/encryption (enlaces max golpeado en esta respuesta)
Volver a Word Wars ... desde el servidor que generamos JWT con la puntuación del usuario y que pase a Clay.io para publicar el puntaje.Voila :)
Por supuesto, esto será diferente según el tipo de juego que está en desarrollo es diferente, pero la moraleja de la historia es que hay que ser creativo :)
me ha escrito una entrada de blog que cubre HTML5 seguridad del juego en mayor detalle. Part 3 of a series on HTML5 Game Development Tips.
Todavía estoy pensando en maneras en que el servidor que genera los eventos de puntuación podría funcionar ... Parece que, inevitablemente, el cliente habría iniciado algunos comentarios para que el juego sea interactivo, como hacer clic o presionar un botón, lo que haría finalmente se traducirá a solo una llamada de socket/URL, suponiendo que cada proceso de puntuación se envía al servidor. Dado que la URL para enviar este evento de puntuación está abierta (¿y no hay manera de evitar esto?), Parece que las personas pueden fácilmente abusar de ella configurando un raspador en la URL, incluso. ¿Qué tipo de juego podría tener solo eventos de puntuación limitados por el servidor? – ina
@ina: casi todos los juegos comerciales en línea hacen toda su puntuación en el servidor. El cliente inicia las acciones pero el servidor las resuelve y decide el resultado. – Kylotan
@ina: Lo que dijo kylotan. No tenga un evento de "generar una puntuación". Haga que un evento de "jugador tomó esta acción". Si la acción genera un puntaje generado, genere el puntaje en el servidor. Significa que su cliente no es más que una pantalla para eventos generados por el servidor; efectivamente no hay elementos de juego ejecutados en el cliente, todos ocurren en el servidor y se procesan en el cliente. –