Inicio › Foros › Clientes y programación › Algoritmo para un mapperpara MushClient y RL
-
AutorRespuestas
-
-
Buenas.
Hace unos días me encontré un archivo .lua en la carpeta de mushclient que me llamó la atención, llamado mapper.lua.
Puesto que no conozco el lenguage lua, no me puse a examinarlo a fondo. Sin embargo, se me ocurrió que podría desarrollar una API en python que haga el papel de base de datos de rooms del mud, para posteriormente desarrollar además un plugin en python que la utilice adecuadamente, así como un render gráfico para mostrar el mapa en la pantalla.Como decía Nick Gammon, el truco está en identificar las rooms individuales. Por ejemplo si tengo esta room:
Puerta sur de takome [s,n]
Será sencillo identificarla, ya que no hay otra en todo el mud con ese mismo nombre.
Sin embargo, si tenemos una como esta:
Camino empedrado de takome [s,n]
Entonces si se complica, porque tenemos varias rooms con el mismo nombre, incluso alineadas, por lo que nuestro flamante mapper se confundiría al identificar la room en la que estamos.
Una solución, en parte planteada por Nick, sería la siguiente: primero, juntamos el título de la room, luego las salidas,tal y como están, y a partir de esa información conseguimos una suma MD5.
Pero bueno, seguirá siendo un problema, ya que muchas rooms tienen incluso el mismo orden de las salidas, por lo que le añadimos un poco mas de complicación.
Esta es una clase en python:
class Room:
def __init__(self, titulo, salidas, volatile=False):
__titulo = titulo
__salidas = salidas
__volatile = volatile
__south = None
__north = None
West = None
__east = None
...P.D: esto es un simple borrador, no tengo ningún archivo escrito sobre esto.
Bien, ahora supongamos que tenemos nuestra clase room funcionando al 100% con un UID para cada room, y cada room genera su hash según el título y las salidas.
Ahora lo que sigue es escribir un manager para que guarde las rooms en dos arrays, una para guardar las rooms según los hashes y otra para guardarlas según su ID único.
Bien, las variables __south, __north, etc… son para el vínculo entre salas, y lo que se almacena en ellas es el ID único de la room que la sigue en dirección de la variable…ya seguramente están entendiendo mas o menos…
Ahora, ¿cómo almacenamos dos rooms con la misma suma MD5 en el mismo array? simple: si encontramos ya una room almacenada con el mismo hash, simplemente lo que hacemos es tomar esa room y transformar ese nodo del array en otro array, en el que vamos a guardar las rooms con ese hash particular.
Una buena manera de hacer funcionar la API es hacer lo siguiente: al manager añadirle métodos de movimiento, por ejemplo: moveSouth, moveNorth, etc… que lo que harán es simplemente tomar la room seleccionada actualmente y reemplazarla por la room que está en esa dirección, generando un error en caso de que no haya dicha room contigua.
Bueno, y claro, contrastar el hash de la room que recivimos del mud con la room seleccionada actualmente por el manager, y en caso de que no sea correcta, buscarla.Esto último sería trabajo del plugin.
Por hablar del render, podría hacerse mediante pygame o wxpython, no lo se…
P.D: se aceptan críticas.
Es todo.
Tengo muchas ideas en la cabeza, tantas que no puedo si quiera expresarlas.
-
A mi me incordia meterme el render gráfico, pero supongo que podemos hacer una base de datos en base las rooms se vayan cargando y si queréis tomar la parte gráfica, pues bien.
Sobre el id de sala, parte de los problemas se soluciona usando el fichero de la room, aunque hay más problemas aún: salas clonadas, el océano, salas virtuales… muchas de estas salas tienen la misma ruta para un centenar (o millar) de salas.
El problema del mud siempre fue identificar las salas con un id único así que estas en la encrucijada en la que estuvimos todos cuando quisimos automatizar el mapa.
Anyway, si se crea un render gráfico y un mapper que se mueva para algún cliente podemos ver de ponernos las pilas y facilitar algún tipo de mapa al respecto.
Sobre las críticas… las direcciones no creo que deban ser propiedades tan definidas, yo pondría un array asociativo o incluso un array de clases «direccion» ya que no todas las salas usan las salidas cardinales estandar (n, s, e, o…) y tienen salidas tipo «puerta», «taller» o movidas por el estilo.
-
@Satyr wrote:
A mi me incordia meterme el render gráfico, pero supongo que podemos hacer una base de datos en base las rooms se vayan cargando y si queréis tomar la parte gráfica, pues bien.
Sobre el id de sala, parte de los problemas se soluciona usando el fichero de la room, aunque hay más problemas aún: salas clonadas, el océano, salas virtuales… muchas de estas salas tienen la misma ruta para un centenar (o millar) de salas.
Bueno…el objetivo no es mapear el océano, ni el desierto, ni impenetrable…ni ningúna sala que sea de ese género, sino mas bien caminos, ciudades, y bosques que se puedan mapear, como el bosque de thorin que me parece muy sencillo de mapearlo.
Como dices, es complicado identificar las salas, y por eso mi planteamiento de asignarle un ID único a cada sala del mapa.
El secreto para un funcionamiento óptimo de este algoritmo sería ubicarse a pelo en una sala única y darle la orden al manager para que la identifique.
El problema del mud siempre fue identificar las salas con un id único así que estas en la encrucijada en la que estuvimos todos cuando quisimos automatizar el mapa.
Anyway, si se crea un render gráfico y un mapper que se mueva para algún cliente podemos ver de ponernos las pilas y facilitar algún tipo de mapa al respecto.
Sobre las críticas… las direcciones no creo que deban ser propiedades tan definidas, yo pondría un array asociativo o incluso un array de clases «direccion» ya que no todas las salas usan las salidas cardinales estandar (n, s, e, o…) y tienen salidas tipo «puerta», «taller» o movidas por el estilo.
Si claro, en ese caso…pues pondría esas salidas no-estándar en un array separado, con el único objetivo de ahorrar código de comprobación…
Ahora…hay algo que se me pasó explicar en el primer post, y es la variable volatile:
Pongamos un ejemplo:
Claro de los Nyathor [se,ne]
Esta sala, como casi todos saben, es una sala que varía sus salidas, así que puede tener dos hashes distintos, por lo que ponemos esa variable en True o Verdadero y añadimos una o mas listas de salidas y/o títulos para darle versatilidad…aunque claro, esto ya tendría que tener un método algo especial de gestión tanto dentro de la API como en el plugin que vaya a hacer esas gestiones…
Bueno solo eso.
Si a alguien le da dolor de cabeza todo esto tomarse algunas pastillas…
Tengo muchas ideas en la cabeza, tantas que no puedo si quiera expresarlas.
-
Eso es un poco lioso, lo que tiene que identificar al hash es la ruta de la room, como ya hace ahora la armería de objetos que está en desarrollo. Cualquier otra cosa implica código adicional difícil de mantener, implementar y comprender.
-
Hola,
@Satyr, quería preguntar si hay la posibilidad de implementar algunas extensiones del lado del cliente para facilitar todo estoYo pensé en un formato del estilo XML o similar a BBCode que se use para enviar información, como por ejemplo personajes en una sala, NPCs, IDs, áreas…
En particular, para la gente ciega se podrían hacer muchas cosas con eso.
Ahora mismo, yo veo muy difícil hacer algo complejo sin la información adecuada.
Un saludo.
Tengo muchas ideas en la cabeza, tantas que no puedo si quiera expresarlas.
-
Ah, se me olvidaba:
Supongo que conocés este MUD.Si tenés tiempo, descargate este cliente, que viene preparado para ese MUD.
Es una cosa muy interesante y muy completa y bien hecha, me gustaría que se pudiera hacer algo así.
Un saludo.
Tengo muchas ideas en la cabeza, tantas que no puedo si quiera expresarlas.
-
Hola,
@Satyr, quería preguntar si hay la posibilidad de implementar algunas extensiones del lado del cliente para facilitar todo estoYo pensé en un formato del estilo XML o similar a BBCode que se use para enviar información, como por ejemplo personajes en una sala, NPCs, IDs, áreas…
En particular, para la gente ciega se podrían hacer muchas cosas con eso.
Ahora mismo, yo veo muy difícil hacer algo complejo sin la información adecuada.
Un saludo.
No contesté antes porque no lo ví.
Hemos apostado por GCMP y es lo que usaremos (básicamente, JSON que envía el mud al cliente).
Si mushClient está preparado para JSON y es necesario que os demos alguna información, podemos ver de implementarla sin ningún problema.
El tema de mapas, de momento no hay nada. Preveo hacer rápido a corto plazo para los clientes, pero Zoilder se guarda algo mucho mejor a largo.
Cualquier cosa nos dices.
-
-
AutorRespuestas
- Debes estar registrado para responder a este debate.