Al iniciar el proyecto nos dimos cuenta de que necesitaríamos un mundo del que partir. Deberíamos analizar los datos de los que se compone y decidir cuales debían estar en el cliente, en el servidor o en ambos.
La información que encontramos habitualmente en los ficheros de mapas de un cliente de Argentum Online (ImperiumAO en ficheros .CSM por ejemplo) es la siguiente:
- Nombre y descripción
- Musica de ambiente y otros…
- 4 layers de GRHs
- Tiles bloqueados
- Triggers (mascara para representar cosas como zonas de paso, bajo techo, seguras, u otros…)
- Tiles con particulas y luces
- Objetos y NPCs
- Teleports
Encuentro especialmente interesante el hecho de que los ficheros de mapas que van a parar al cliente(del IAO sin ir mas lejos) contengan información tan irrelevante para el mismo como pueden ser los objetos y los npcs, que obviamente los ha de enviar el servidor en función del estado del juego. Aunque por otra parte nos han resultado extremadamente útiles para no encontrarnos con un mundo sin puertas, carteles, arboles, npcs, teleports…
Por otro lado los teleports podrían tener una explicación si se quiere bloquear al jugador hasta que le servidor lleve a cabo el teletransporte pero esto solo requeriría un flag y no la posición de destino. La única razón que se me ocurre para incluir esta información sería algún sistema de pre-cache cuya lógica se quiera delegar al cliente.
Otra cosa, cuanto menos llamativa, de los teleport es que la mayoría de los mapas conducen al adyacente por lo que podemos encontrar en cada mapa del orden de 80*4. Estos además representan 4 «filas» que llevan a las correspondientes «filas» en los mapas de al lado, lo cual parece una estructura de datos extremadamente ineficiente. Si lo multiplicamos por el numero de mapas nos encontramos del orden de 250k tiles con información de la posición de destino que no se utilizará tan solo en el mundo normal.
Por continuar con el ineficiente uso del espacio hay que tener en cuenta que la información de los bordes de los mapas(donde no podemos pisar) está por duplicado. Desde un mapa se ve lo que en realidad pertenece al de al lado pero que se alcanza a ver. Con 800 mapas que hay tan solo en el mundo principal, teniendo en cuenta la parte duplicada en bordes que sería del orden de 7*2*100+5*100-5*7*2=1900 tiles por cada mapa de 100*100=10000 tiles resultaría en un 19% del mapa con información duplicada que potencialmente se podría eliminar con el consiguiente ahorro de espacio en el cliente, tanto en disco duro como en memoria.
Además estas duplicidades pueden generar incoherencias en los cambios de mapa ya que lo que vemos desde un lado puede no ser igual que lo que vemos desde el otro. Estos fallos de mapeo son los que provocan que en un cambio de mapa podamos observar diferencias en el terreno.
En la siguiente entrada explicaré como teniendo en cuenta estas y otras consideraciones se estableció la forma de estructurar la información del mundo de DinastyAO y por supuesto, como llevar a cabo la conversión.
Un comentario en “Un mundo para DinastyAO”