inmensia

Coincidiendo con el fin de año llega también el fin de esta serie de posts. Del modelo de datos de PlaneShift quedan todavía algunas tablas por examinar, pero las principales creo que se han examinado todas, o al menos las suficientes como para entender como está estructurado en términos bastantes generales el juego en lo que refiere a esta parte concreta. Queda un primer grupo de tablas por examinar relacionadas con el concepto de "superclient", un término que utilizan en este juego para referirse a la gestión que realizan de los NPCs, mediante procesos ejecutándose en máquinas conectadas al servidor como si fueran jugadores normales. Otro segundo grupo de tablas que contiene información variada sobre el juego, como recursos naturales, zonas de caza, y cosas por el estílo. Y un tercer grupo que almacena opciones de configuración del servidor, comandos de gm (game master), mensajes de ayuda, etc...

Llegado este punto, si a alguien le interesa profundizar más en el funcionamiento del juego, le recomiendo que continue examinando el detalle concreto de cada tabla, estudiando a la par el modelo y el código fuente. Pero esa no es una opción que me atraiga mucho. Lo tomé sólo como modelo de un ejemplo real totalmente operativo, pero no quiere decir que sea el camino a seguir en todos los casos. Lo importante ha sido comprobar que realmente no hay mucha diferencia entre una aplicación de gestión y un juego de estas características, al menos en lo que al diseño de la base de datos se refiere. Es lo que tiene basarse en un gestor relacional, al final tiene que acabarse haciendo un modelo relacional, dando igual que sea para una aplicación de contabilidad que para un MMORPG.

Echando la vista atrás, y releyendo un poco por encima toda esta serie, he recordado las dudas que tenía al principio sobre la viabilidad del uso de una base de datos convencional para este tipo de juegos. Sobre todo después de leer que algunas compañías habían optado por desarrollar su propio gestor de transacciones. O que otras, a pesar de utilizar un gestor comercial, habían decidido saltarse cualquier tipo de normalización. Supongo que cuando se espera tener millones de cuentas y los objetivos son muy elevados, casi extremos, muchas de esas soluciones cobrarán sentido. Pero creo que sería algo para analizar en detalle para cada caso concreto. Yo personalmente optaría primero por tener un modelo totalmente normalizado, y luego ir desnormalizando a medida que haga falta. Aunque de todas formas hoy en día las mejoras de rendimiento muchas veces se prefieren obtener sustituyendo el hardware, algo generalmente más barato y menos complejo que realizar grandes cambios en el software. Las limitaciones que tradicionalmente se le han achacado a las base de datos relaciones, en cuanto a escalabilidad se refiere, se están dejando atrás por el aumento de prestaciones del hardware y la disminución de su coste, además del uso de otras técnicas como el particionado de tablas por ejemplo.

El siguiente paso lógico, después de la elaboración del modelo, sería contruir la capa de abstracción para el acceso a la base de datos. Normalmente un conjunto de clases a modo de wrapper sobre el API nativo proporcionado por el gestor utilizado. En PlaneShift estas clases están implementadas en los ficheros dal.cpp y dal.h (DAL = Data Access Layer), suministrando los habituales métodos de conexión, desconexión y ejecución de sentencias SQL. Si la elaboración del modelo es ya de por si un mundo, la construcción de una capa de abstracción no se queda atrás. Para sacar el máximo partido posible de las capacidades de una base de datos se debe optar generalmente por estudiar a fondo las posibilidades que ofrece esta. La ejecución de una simple sentencia puede ser algo rápido y casi inmediato, pero la ejecución de miles ya no tanto. La utilización de sentencias precompiladas, el uso de caches intermedias, la programación en algún tipo de PL/SQL soportado por el gestor, o las facilidades para las inserciones masivas (bulk arrays) son sólo algunas de las estrategías básicas que se deberían tener en cuenta. Aunque naturalmente, en vez de construir una capa de persistencia propia, se puede optar por la utilización de algún tipo de framework ya construido a tal efecto.

Es dificil a priori decir que enfoque será el más eficiente de cara a la implementación de esta parte. Lo mejor como siempre será probar varias técnicas y evaluarlas de forma individual mediante las oportunas pruebas de volumen y rendimiento. Si se espera que una tabla tenga miles de registros es mejor probarla con un millón, y si se espera que tenga un millón probarla con varios de ellos. Conocer en este punto las características particulares de almacenamiento proporcionado por el gestor puede ayudar a decidir como guardar los datos, optimizando la creación de los índices, particiones y las formas de acceso. En este punto también es bueno construir pequeñas herramientas auxiliares para la generación automática de registros. Las base de datos suele proporcionar meta-información acerca de la misma, de forma que a través de una consulta SQL normal se puede recuperar el nombre de las tablas, de las columnas, y sus tipos. Con esa información es fácil hacer un programa que inserte de forma automática registros con información aleatoria con la que rellenar facilmente una tabla. Incluso existe software comercial especializado en ese tipo de tareas; muy útil para realizar "demos" con nombres, direcciones y teléfonos de clientes ficticios, por ejemplo.

La actualización diferida de la base de datos es otro punto que quizás debería tenerse en cuenta desde el principio. Es lógico pensar que toda sentencia a ejecutar acabe teniendo una prioridad. No deberá ser lo mismo actualizar el modelo para reflejar un daño inmediato que está sufriendo un personaje, que actualizar la dirección en la que mira. En algunos casos puede que realmente ambas tengan la misma prioridad, en otros no. Además, si los cambios afectan a columnas de una misma tabla, de un mismo registro, entonces realizar las dos actualizaciones al unísono puede ser incluso mejor. Y todo ello sin perder de vista que lo importante es conseguir que el estado del mundo virtual quede siempre coherentemente reflejado en la base de datos.

Y en fin, esta es sólo la punta del iceberg. Más allá de la base de datos queda una lista enorme de cosas por hacer. Posiblemente lo siguiente sería estudiar la conectividad entre los clientes y el servidor, o servidores, o entre los propios clientes entre sí (para un chat de voz por ejemplo). Decidir que protocolo de red usar (la eterna discución TCP vs UDP). E incluso definir un protocolo propio para el intercambio de mensajes tratando de minimizar el volumen de información intercambiada (usando coordenadas relativas por ejemplo). Y así un largo, largo, largo, etcétera.

¿No encontró lo que buscaba?

Utilice el buscador para encontrar más páginas en esta web o en toda Internet.

	Web www.inmensia.com