Tal y como traté de explicar en la entrada anterior, el formato de datos del Argentum Online original no parece el optimo.
Aún así puedo afirmar que este formato ha mejorado sustancialmente desde las primeras versiones. Sin embargo, a pesar de todas las evoluciones que ha sufrido a lo largo del tiempo, nunca se ha llegado a profundizar en ellos con el objetivo de optimizarlo de verdad.
En el post anterior revelé la información innecesaria o redundante de la que directamente se podía prescindir. Sin embargo, más allá de esto, cierta información como la correspondiente a zonas bloqueadas o navegables, por ejemplo, puede no estar almacenada de la forma mas conveniente.
Más concretamente, en el caso mas extremo, si tenemos en cuenta la cantidad de agua que hay en el mundo no parece la estructura mas apropiada para almacenarlo guardar todos y cada uno de los tiles de forma individual. También hay que tener en cuenta que lo más habitual será, tanto para el agua como para los tiles bloqueados, que estos no se encuentren de forma aislada o separados entre si.
Además, si es un simple array el que define si una posición concreta está bloqueada o es navegable resulta una estructura extremadamente rígida para posteriores ampliaciones. Idealmente un formato mínimamente flexible debería permitirnos la posibilidad de ampliar el numero de atributos de los tiles. Cosas como definir zonas seguras, la música de ambiente, el nombre del área, si el inventario cae o si está permitido ocultarse, etc…
El primer problema de definir tile a tile se soluciona cambiando la estructura de datos para que sea capaz de contener rangos de áreas, desde una posición a otra. El segundo, de flexibilidad, pudiendo asignar propiedades arbitrariamente(como clave-valor) a cada una de estas áreas que definen un conjunto de rectángulos sobre la superficie del mapa.
Así es como queda la información si se exporta a formato TMX y se abre con editor de mapas Tiled, que bien podría ser la alternativa al world editor del AO.
Resumiendo, las áreas con rangos y propiedades asociadas junto a las 4 capas de gráficos sin duplicidades en los bordes parece ser una buena estructura para almacenar los datos.
Gracias a un fichero INI de los recursos del IAO que especifica la coordenada de cada mapa en el mundo no hubo que sacar ninguna relación entre los teleports de los bordes para situarlos. En cuanto al cambio de coordenadas al sistema nuevo, resulta bastante intuitivo una vez que se conoce el offset del mapa en el mundo y su tamaño real.
Para localizar la información del nuevo world resultaría tan sencillo como buscar el mapa al que corresponde la coordenada en el fichero INI y esa posición dentro dentro del mismo, descontando el offset junto al borde del mapa, obviamente.
En caso de que alguien se anime a hacer este ejercicio, tan solo advertir que el fichero INI a día de hoy tiene fallos. El mas evidente es que hay al menos 2 mapas que tiene las posiciones intercambiadas(como la cueva newbie). Por otra parte ya comentamos que el borde es información duplicada y esta no coincide en algún caso en el que dos mapas «desconectados por teleports» están uno junto al otro.
Por último se creo un «world» nuevo compuesto por todos aquellos mapas que no están conectados o posicionados directamente en relación con los demás. Encontramos muchos mapas con diferentes finalidades, tal y como puede apreciarse en la imagen, desde cerrar la pasarela de Banderbill hasta organizar un evento con el Game Master. De esta forma no se rompen los tele-transportes hasta y desde estos mapas los mundos continuos, como podría ser el caso de lo que, al menos antes, se conocía como Intermundia.
En la próxima entrada espero hablar de la parte que considero mas interesante, y no tan evidente como lo tratado hasta el momento, donde hay mas situaciones y excepciones que tener en cuenta. Se trata de un diseño e implementación del mundo continuo, tanto desde la perspectiva del cliente como la del servidor.
2 opiniones en “Estructura de datos del mundo de DinastyAO”