Ya te darás cuenta de que este proceso cortocircuitaría bastantes de las lecturas de la tabla 4

Puede que pienses que deberíamos limitarnos a almacenar los datos recién calculados después de registrar una nueva entrada en la tabla. Esto puede parecer una buena idea, pero daría lugar a incoherencias en los datos y a una degradación del rendimiento. Por ejemplo, el sistema estaría ocupado recalculando y almacenando datos, a menudo debido a la necesidad de leer estos datos y luego escribirlos. Debemos equilibrar el cálculo mientras el juego se ejecuta con un rendimiento adecuado para todos los jugadores.

Uno de los problemas derivados de la inconsistencia de datos se daría a la hora de realizar los cálculos al final de la partida. Nuestra infraestructura de servidores y plataformas admite los mensajes que llegan tarde. Un ejemplo sería un problema transitorio entre dos centros de datos (A y B), ya que el mensaje para otorgarle experiencia a la mini de un jugador se envía desde A, pero aún no habría llegado a B. Imagínate esta situación: estás jugando una partida justo antes de medianoche. Juegas y ganas, y es miércoles a las 23:59. El procesador de cálculo parcial está configurado para ejecutarse diariamente y para todos los datos hasta la jornada presente. Dicho esto, arrancaría a medianoche y calcularía los valores totales de la experiencia obtenida hasta el jueves a las 00:00. Esos datos se almacenarían en la segunda tabla, y las nuevas lecturas de la experiencia buscarían el último valor almacenado para sumarlo todo pasado el jueves a las 00:00. Lo que sucede si un mensaje llega con retraso es que sí, lo recibimos, pero ten en cuenta que la partida se completó el miércoles a las 23:59 y se escribió el registro de experiencia a esa hora. La tabla de cálculo parcial no tendría en cuenta esta entrada y una petición posterior de los datos tampoco mostraría este registro. Por eso, estos datos incompletos supondrían un problema. ¿Y qué hay de los mensajes que llegan con unos días de retraso? Bueno, pues disponemos de sistemas de seguimiento y de alertas que casi siempre garantizan que la información nueva se procesará a tiempo para el siguiente cálculo parcial.

Calcular el nivel de las minis

Si nos fijamos en la tabla de experiencia total, verás que no se reflejan los niveles calculados. Solo disponemos del total de experiencia obtenida. Existe una tabla estática por separado que han creado los diseñadores de juego que tiene este aspecto. Una mini comienza en el nivel 1 y, en cuanto obtenga 1 punto de experiencia, subirá al nivel 2. Después, deberá obtener 3 puntos de experiencia para subir al nivel 3.

Si combinamos ambas tablas podemos obtener en tiempo real el nivel de una mini si calculamos el total, lo que nos facilita este último conjunto de datos:

Los diseñadores de juego disponen de la flexibilidad para modificar la experiencia necesaria para subir de nivel. Puede que lleguen a la conclusión de que es muy complicado subir de nivel en los niveles más bajos y reduzcan la cantidad necesaria para hacerlo. Esto implicaría que, sin realizar cambios a los datos guardados de los jugadores en la base de datos, las minis recibirían un empujoncito a su nivel actual y que necesitarían menos experiencia para subir al siguiente. Esto también ocurre al contrario. Si los diseñadores de juego deciden que se sube demasiado rápido y aumentan los valores, no otorgaremos experiencia gratuita para que las minis tengan el nivel previo al cambio. Eso no quiere decir que no podamos darles a los de diseño la opción de otorgar un poco de experiencia a las minis como medio para solucionar este problema.

Alternativas ponderadas

Antes de usar la solución que ya tenemos, estuvimos estudiando varias alternativas sobre cómo almacenar la obtención de experiencia y cómo calcular el nivel resultante para las minis. Algunas opciones provocaban mantenimientos adicionales que nos permitían modificar la experiencia el jugador, mientras que otros rendían bien a la hora de ofrecer la experiencia adecuada mientras seguían el ritmo de la progresión del jugador.

Almacenar el nivel y la experiencia de una mini hasta el siguiente nivel

¿Y si usáramos un patrón SQL estándar con actualizaciones transaccionales? Este tipo de actualizaciones permiten actualizar un conjunto de datos al completo (o todos o ninguno). Si una parte da error y no se escribe, todo vuelve a su valor original. Este método otorga atomicidad, regularidad, aislamiento y durabilidad.

Además, se usaría una única columna para mantener la experiencia y el nivel total de una mini, lo que provocaría que las lecturas fuesen muy ligeras.

A medida que una mini obtiene experiencia, hay que actualizarla para que ya tenga 2 PE y le falten otros 8 PE para llegar al nivel 3. Este tipo de cambio obliga a una lectura de los datos, a recalcularlos y a escribirlos en la base de datos. Este patrón no combina del todo bien con Cassandra y sus ventajas. Otro problema con este enfoque sería que para cambiar la cantidad necesaria para subir de nivel haría falta desconectar el juego para que podamos modificar los datos de las minis de todos los jugadores.

Almacenarlo todo en forma porcentaje

También pensamos en usar un porcentaje hasta el siguiente nivel. Por ejemplo:

Entonces, tras una partida, realizaríamos una serie de cálculos rápidos. Por ejemplo, si el bruto gnoll obtiene +3 PE, el porcentaje será +3/10. Le otorgaremos al bruto gnoll un 30 % del nivel, lo que genera lo siguiente:

Este método nos dará flexibilidad si cambiamos la curva de nivel de las minis, pero no habría cambios de nivel en la propia mini. Además, nos facilitaría una visualización más sencilla en la interfaz de usuario del juego porque, por ejemplo, nos limitaríamos a decir que falta rellenar un 30 % de la barra sin cálculos adicionales. No obstante, este patrón desembocaría en unos porcentajes muy reducidos en los niveles más altos. Si una mini recibe 10 PE por partida y se necesitan 100 000 PE para subir de nivel, ese valor se representaría a un 0,01 %. Las unidades centrales de procesamiento (CPU) pueden gestionar decimales, pero la precisión y la exactitud pueden generar errores si no tenemos en cuenta la naturaleza de los cálculos con este tipo de cifras.

Hasta la próxima...

Barajamos muchas opciones en cuanto a la tecnología de la base de datos, las herramientas que podíamos utilizar y, por último, el almacenamiento y el cálculo de todo ello. Como cualquier cosa que esté en desarrollo, existe la posibilidad de que cambiemos todo esto más tarde si encontramos algo que funcione aún mejor. No obstante, lo que tenemos parece un buen punto de partida para este juego.

¡Gracias por acompañarnos en esta actualización de ingeniería!

~ Andy Lim