Novedades LumiMUD

Pues como prometí, voy informando de los progresos.

En el poco tiempo que he podido dedicarle he rehecho la creación de fichas y el login, todos los canales y algunos comandos básicos. Ya se nota la mejora de la base de gestión de personajes y ahora los comandos son casi 100 veces mas rápidos de ejecutar en el servidor.

El siguiente paso obvio es rehacer el movimiento y otros comandos como coger y dejar, pero aquí me he visto detenido de nuevo por otra decisión relevante, la capacidad y la carga.

Las entidades tienen un volumen y un peso, el peso que se podrá mover dependerá de la fuerza del personaje, pero el volumen también es un factor a tener en cuenta. Por ejemplo en el numero de cosas y personajes que entrarán en un bote, o en una room.

Por el momento la solución que va en cabeza en mi brainstorming personal es la de valorar todos los objetos con un valor de referencia para su volumen, pero entonces entra el problema jugabilidad vs realismo. Me explico, fastidia querer coger algo y no poder cargarlo, pero también es una tontería que un personaje pueda cargar 10 mochilas llenas de oro o 35 armas diferentes y trepar por ahí ágilmente.

Una solución es hacer que una persona no pueda cargar nada (lo agarrado con las manos o en la espalda, se considera "vestido") y el inventario del personaje se guarde en sus "bolsillos" los contenedores que lleve cargados. De esta manera el inventario tendría la capacidad de los contenedores vestidos, y un personaje desnudo solo podría llevar lo que agarrara con sus manos y algo colgado del hombro.

Muchos jugadores no gustarán de un juego en el que no pueden cargar todo el tesoro, o llevar un arma de cada tipo para cada ocasión...pero creo que los juegos sin limitaciones acaban en hastío,  y tampoco me parece mal que tengas que dejar parte del oro porque no puedes con todo. Si quieres llevarte todo el tesoro, trae mas gente y reparte el botín (mas colaboración entre personajes) o haz muchos viajes.

Y siempre se puede cambiar después, recordemos que este MUD está plagado de ideas bizarras. No tengo ni idea de como será de divertido, Pero original, un rato.

Estado de LumiMUD

Actualmente LumiMUD tiene implementados en su código:

Servidor de Telnet: acepta múltiples conexiones simultáneas, colores, y caracteres españoles como la ñ y las tildes (incluso los signos ¿ e ¡, casi nunca usados antes en MUDs, creo).

Módulo de gestión de conexiones: fusionado con el anterior módulo recepcionista, inicia el registro o la recepción de los clientes, atiende los comandos entrantes y expulsa a los jugadores inactivos.

Base de datos: al final después de probar varias, me he quedado con SQLite por razones prácticas. He usado una base de datos en vez de almacenamiento directo porque, aunque es mas lento, facilita tareas como la de exponer datos en la web y actualizar en tiempo real las entidades del MUD (rooms, jugadores, movs...todo lo que no es código, vamos)

Módulo adaptador para la base de datos: Gestiona el almacenamiento en la base de datos y hace de intermediario para las consultas SQL que sean necesarias desde el código (no era obligatorio, pero necesario para simplificar al máximo los futuros cambios).

Módulo reload: Permite recargar el código de manera automática y sin tener que desconectar a nadie (hasta la fecha sin problemas).

Módulo logger: en vez de imprimir por terminal las advertencias y errores, este módulo registra el nivel (debug, información, advertencia, error o error crítico) y el módulo donde se produce y lo imprime por pantalla. Además si es un error, añade a un archivo log con la fecha actual y los últimos mensajes para poder seguir el rastro a los posibles bugs que sucedan en el futuro.

Módulo comandos: con submódulos para cada categoría de comandos (generales, salidas, ayuda, de administrador...) y un analizador que recibe un string y extrapola el comando y los argumentos e intenta ejecutar el apropiado.

Novedades LumiMUD

Un nuevo cambio, he añadido un módulo logger que se encarga de llevar cuenta de los avisos según niveles.

En vez de imprimir por terminal las advertencias y errores, este módulo registra el nivel (debug, informacion, advertencia,error o error crítico) y el módulo donde se produce y lo imprime por pantalla. además si es un error, añade a un archivo log con la fecha actual y los últimos mensajes para poder seguir el rastro a los posibles bugs que sucedan en el futuro.

Así puedes configurar que nivel de advertencias se muestran por pantalla al arrancar el MUD (los print siempre aparecían) con cambiar una simple variable. Poner el modo debug para tener toda la información rastreando un error, poner el modo info para tener solo notificaciones o errores, o incluso poner el modo en errores con lo que no se imprime nada por pantalla que no sea un error.

Mucho mejor que llenar el código con prints, y el volcado de un buffer en un archivo vendrá de perlas en el futuro.

Novedades LumiMUD

Lo prometido es deuda, aquí tenéis la primera entrada sobre los avances en el LumiMUD.

He rehecho la mitad del código, pero por motivos prácticos. La parte mala de tener tanta creatividad aparece cuando has programado bastante y, de repente, se te ocurre una manera mejor. Sé que la norma es "no optimices el código hasta que lo hayas terminado, a veces, ni siquiera entonces", pero en un MUD creo que los cambios y añadidos son parte de la vida útil del código y cualquier cosa que los simplifique en un futuro debe estar en las bases del código.

El código sigue basándose en entidades, pero ahora se gestionan con clases. Lo que hace mucho mas sencillo su uso en otras partes del código como en los comandos.

El acceso a la base de datos ahora es mixto, lo que me permite cambiar varios parámetros en una sola instrucción y consulta.

En vez de establecer la fuerza y la destreza de un personaje a 10 (pongamos a zaroos como ejemplo) con:

Personaje('zaroos').fuerza = 10

Personaje('zaroos').destreza = 10

Ahora se puede hacer:

Personaje('zaroos'). Establecer({fuerza : 10, destreza : 10})
o
Personaje('zaroos'). Establecer(todos_los_nuevos_valores_que_quieras)

Esto que parece una trivialidad, permite cargar diccionarios enteros de modificaciones en una sola línea de código, o utilizar un diccionario de un solo elemento para hacer lo mismo que con los comandos anteriores.

Ademas, ahora el código carga los cambios de la base de datos al arrancar el MUD, así que si el día de mañana se añade o cambia una habilidad o atributo a la base de datos, el MUD la carga sin cambiar código y puedes usarla directamente en los comandos sin problema.

Con esto doy por finalizado por el momento los módulos de la Base de datos y del servidor de Telnet.

Actualización

Comencé este blog como alternativa mas accesible que el foro anterior. Nunca he sido blogger, y no he actualizado este tanto como debería.

Intentaré escribir más a menudo para aquellos interesados, aunque no seáis muchos.

Cambiando de tema...he vuelto a CallandorMUD, como muchos de vosotros ya habréis notado. Esta vez soy un bardo, por motivos prácticos -para mapear- aunque, según mis amigos, es la clase que mas me pega en la vida real. Intentaré actualizar el mapa y a Lumi proximamente.

En cuanto al LumiMUD, entre el trabajo, los estudios, la novia y los amigos... no me queda mucho tiempo para programar. Pero sigo dedicándole alguna hora suelta de vez en cuando.

Escribiré entradas sobre el progreso del LumiMUD etiquetadas y con titulo Novedades LumiMUD, para quien pueda interesar.

Servidor listo

Lo normal al crear un MUD es coger alguno de base y hacerle las modificaciones pertinentes.

Pero como soy de la opinión de que es mejor empezar un lienzo nuevo que retocar la obra de otro, pues decidí escribir de 0 el MUD.

Me llevó un par de tardes tener un servidor de Telnet al que conectarse, y aunque solo valía para charlar, ya era algo.

La pega de escribir el código de 0 es que tienes bastante mas trabajo, la ventaja que puedes diseñar hasta el último detalle. Tengo cientos de ideas (la mayoría disparatadas) que voy implementando a medida que escribo.

Una semana después, ya tenía un pequeño ejemplo. Tiene un recepcionista creador de fichas, un par de rooms para probar el movimiento, se puede decir y charlar (probar canales), e incluso un Mov con sus propios comandos.

Como siempre en la programación, mi mayor problema hasta la fecha son los pequeños errores. Esas tildes y erratas que hacen que el programa no funcione y te quitan mucho tiempo buscando el error en algo que ya funcionaba.

Pero en fin, que voy programando en mis ratos libres -que no son muchos-.

Historia de un Mapeador

Puede que algunos ya lo sepáis, pero mis comienzos MUDeros se deben a un amigo y compañero de carrera que me dejó en su día los tomos de la Rueda del Tiempo y, posteriormente,  me sugirió probar CallandorMUD.

El juego me convenció, no tenía gráficos ni complicación. era el súmmun del rol y con una gente maravillosa.

Las aficiones tienden a compaginarse, a atraerse unas a otras, y al final acabé programando en el zMUD y mapeando Callandor. Un mapa que posteriormente cedí a todos los jugadores y que, quiero pensar, que ayudó a que muchos se quedaran en Callandor.

Debido a un error de cálculo, los inmortales (administradores) de Callandor tuvieron que borrar todas las fichas (cuentas) y volver a empezar en lo que se llamó la segunda era. Esto, unido a las exigencias de mi carrera y a la falta de tiempo, propició que dejara de jugar al único MUD al que he jugado.

Terminé la carrera y cuando las ocupaciones mermaron y reapareció algo de tiempo libre, rescaté la idea que había tenido cuando casi cierran Callandor años atrás. ¿Porqué no hacer un MUD?, no parece tan complicado...

La idea ya la tenía, y aunque las ideas son etéreas y cambian de forma caprichosa, me decidí a programar un poco en mis ratos libres con la idea de hacer un MUD y practicar algo de programación.

Y así empieza el proyecto del LumiMUD (que toma su nombre del script para el mapa del zMUD). Espero ir haciendo progresos en mi tiempo libre, que no es mucho debido al trabajo, y ya iré relatando en este Blog los avances para los pocos a los que pueda interesar.

Un Saludo, ZarooS.