MUD Multiuser Dungeon

Detrás del MUD
Multi User Dungeon

Hola a tod@s

Con el poco tiempo del que dispongo, de vez en cuando, me da por jugar un poco en la red, y mira tu por donde me dio por ver como andaban de salud estos juegos de aventuras conversacionales.

La verdad es que en castellano, no quedan ni la mitad, por no decir que prácticamente desaparecieron, se salva Reinos de Leyenda que después de todos estos años siguen el la brecha del resto, prácticamente nada.

¿Porqué desaparecieron…? ¿porqué en el mundo anglosajón lejos de desaparecer parecen tener una segunda/tercera juventud..?, con estas premisas me puse a investigar un poco como de difícil podía ser crear este tipo de aventuras y, creo que esta es una de las importantes razones por la que los hispanohablantes no hemos cuajado en esto de crear aventuras conversacionales.

Para empezar podéis buscar aventuras conversacionales en español y veréis que la mayoría de los enlaces están caídos, luego debemos preguntarnos que tutoriales, guías etc, etc, hay por la red, y la respuesta es bien clara, ninguno.

Por tanto me surge la pregunta siguiente… ¿ si no hay forma de saber como crear estos juegos, no será una de las causas de poca aceptación…?, pues podría ser una de las cientos de dilemas que rodean a estos y otros juegos.

Si, me he saltado la aparición de nuevos programas tecnologías etc, está mas que claro que las nuevas herramientas superan a los juegos conversacionales, pero como se suele decir una buena historia lo es, si es buena…

Pero para poder llevar a buen termino una historia de estas sin sucumbir en el intento, se deben tener en cuenta un montón de factores que no solo incumben al creador, hay que empezar por un guión, gente para poder desarrollar la idea y algo no menos importante, saber como hacer este tipo de juegos.

No, tampoco me voy a enrollar con la metodología, ni paradigmas de la programación, simplemente voy a mostrar lo poco que he sido capaz de recolectar en el poco tiempo dedicado y abrir una puerta a otros usuarios que ya sea por curiosidad o por que lo desean, puedan usar a su favor y no liarse a dar vueltas en busca de soluciones que muchas veces no están en la red y menos en castellano.

Para empezar que significa MUD, pues Multi Usuario Dungeon, y ¿ cómo se juega a esto..?, pues bien sencillo necesitamos acceso a la red y una conexión telnet, de forma que si queremos conectar al Mud Reino de Leyendas, deberemos abrir un terminal el Linux o escribir en la barra de comandos de Windows:

> telenet rlmud.org 23

… así de sencillo, lo primero el comando telnet para lanzar la comunicación, lo siguiente la dirección del servidor del juego y por ultimo el puerto.

Para probar los cientos de ellos, eso si, en ingles podéis buscar por la red, en castellano la cosa está mucho mas difícil, ¿quizá sea por la poquísima información que hay al respecto, pero desde aquí haremos una pequeña guía para empezar con los Mud’s, por descontado que no sera nada del otro mundo, pero si lo suficiente para poder afrontar esta tarea que puede resultar imposible sin ningún conocimiento, demostrando que es mas fácil de lo que parece, tan solo falta información.

Paginas con enlaces a servidores Mud:

http://www.topmudsites.com/

http://www.mushcode.com/MushList

Claro está que los juegos que corren en una ventana terminal, no incluyen nada más, tan solo la ventana terminal y el juego corriendo que puede ser mejor o peor, con mas o menos colores o gráficos y es que los llamados clientes, pueden variar desde el sencillo terminal, los de peso medio como el que usare Gnome-Mud, hasta los súper clientes, que pueden incluir todo tipo de información mapas etc.

Gnome-Mud es un cliente de peso medio con el que mas adelante elaborare ciertos sencillos  ejemplos y que ofrece relativamente poca posibilidad de modificación, una buena gestión de conexiones y poco mas, tampoco debería ser necesario un super cliente telnet, para los ejemplos será el utilizado, pero podría servir cualquiera, incluso la ventana terminal.

Claro que también tenéis otros muchísimo mas avanzados como el MudLet, y desde luego también se podría utilizar, pero la interfaces es tan grande que puede ser realmente difícil sacar todo el juego a este gigante, en las paginas o foros de juegos Mud’s suelen explicar como integrar mapas o hacer según que cosas con este programa, que tiene mas miga de lo que parece.

Sea, cual sea el cliente que utilicéis, podéis conectar y probar que tal os va con ellos y elegir el que mas os guste.

Creando un servidor MUD

La falta de información en castellano y la difícil comprensión de la sintaxis sobre la creación de Mud’s, me hace crear estas lineas para desvelar parte de los entresijos en la creación de estos programas.

Para los que no sepan que son los Mud’s decir, que son las llamadas aventuras conversacionales, donde los jugadores deben realizar ciertas acciones, resolver ciertos puzzles, con el fin de acabar la aventura propuesta.Quizá una de las partes mas engorrosas, sea la instalación y puesta en marcha del servidor Mud, una vez en marcha, podemos elegir el cliente con el que podemos interactuar con el Mud.

Los clientes pueden ser desde una ventana terminal a programas ya preparados para correr estos servicios y pueden llegar a ser tan avanzados como Mudlet, que permite interactuar con un montón de información.

Para este articulo voy a utilizar el servidor Pennmush, y como cliente uno intermedio, ni demasiado simple como una ventana de terminal, ni demasiado complejo como podría ser Mudlet, también debo decir que la instalación y posterior programación del Mud lo haré desde Linux/Debian, pero excepto la instalación, el resto las operaciones son iguales para cualquiera de los sistemas
operativos que se utilice.

Este articulo esta escrito para PennMUSH 1.8.2 por lo tanto el Mushcode será valido para estos sistemas, no es necesario nada mas, instalar correctamente el servidor en nuestro ordenador y desde ahí, conectar con un cliente para comenzar a desarrollar el Mud, también en nuestro ordenador.

La creación de nuestro propio juego MUD no implica que haya que programar ni desarrollar nuestro propio servidor MUD. Únicamente será necesario que, desde un cliente MUD, nos conectemos como administrador para poder crear el mundo de nuestro juego. Al estar conectados durante la creación, podremos probar en el acto todo lo que creemos. Todo servidor está pensado para ofrecer un servicio, generalmente por red, a uno o más clientes. Eso implica que debe estar accesible desde Internet para que nuestros amigos puedan conectarse desde sus casas.

Para esto es crucial que se cumplan tres puntos: Tener conexión a Internet, poder “enrutar” puertos y obtener nuestra IP externa para facilitársela a nuestros clientes.

Damos por hecho que el usuario tiene internet. El “enrutado” de puertos es complejo y depende de cada configuración, así que no voy abordarlo en este caso, pero es un tema asequible que se puede consultar en internet.

El tercer punto, la IP externa, se puede obtener (entre otras formas) consultando páginas como [1] o similares. También, como es habitual en informática, tener un mínimo nivel de inglés nos ayudará bastante.

Instalación

El primer paso consistirá en instalar el servidor MUD que vamos a usar.

He elegido Pennmush porque ha sido el que menos problemas me ha dado en las pruebas, por su estabilidad y porque, cuando se adquiere destreza, es fácilmente modificable a nivel interno. Así pues instalamos Pennmush, con su variante internacional, usando el paquete para Debian u otro.

> sudo apt-get install pennmush

Una vez instalado creamos una nueva carpeta, donde estará nuestro juego. Acto seguido nos desplazamos a esa carpeta, buscamos en concreto el archivo penn-install que lo encontraremos en /usr/games y copiamos y pegamos ese archivo en la carpeta destinada para el proyecto.

Una vez en ella, instalamos ahí una instancia del juego. El paquete que instalamos previamente contiene una herramienta que instalará automáticamente todo lo necesario en la carpeta y realizará todas las configuraciones iniciales.

> penn-install

este comando nos devolverá algo similar a esto:

Installing pennmush in
/home/usuario/mud/pennmush/game
………..Done
** Be sure to change the ’port’
entry in pennmush/game/mush.cnf
** to the one either assigned
by your system admin or
currently
** available on the system. It
is also necessary to set the
** GAMEDIR variable at the top
of pennmush/game/restart.
Finally,
** log into the mush and change
the password for One (#1) to
** something safe.

Podemos observar que se ha creado una carpeta nueva llamada pennmush, y que dentro de ella también hay otra carpeta, de nombre game.

Ahora es necesario configurar mínimamente el juego para que funcione. Empezamos modificando, con nuestro editor de texto favorito, el archivo :

> nano mush.cnf

Únicamente cambiaremos el puerto, indicando por ejemplo que usará el puerto 4001. La línea de configuración del puerto en ese fichero quedará así:

> port 4001
… guardamos el archivo.

Ahora editamos el archivo:
>>/home/usuario/nombre carpeta proyecto/pennmush/game/RESTART

En él tenemos que configurar el directorio del juego y el idioma.

>GAMEDIR=/home/usuario/carpeta proyecto/pennmush/game

Y más abajo, en # Internationalization stuff

>LANG=es_ES

Nota: Experimentalmente he descubierto que si no indicamos aquí el idioma, automáticamente se detecta el español, usando así los mensajes internos en español. Sin embargo no he sido capaces de conseguir que respete los caracteres especiales como tildes o eñes.

Con esto ya podremos arrancar el servidor:

/home/usuario/carpeta proyecto/pennmush/game/restart
>./restart

Aparecerá un texto en pantalla terminando con la línea:

Redirecting stderr to log/netmush.log

¡Bien! El servidor está funcionado ¿Y para apagarlo? Si queremos apagar el servidor MUD podremos hacerlo pulsando, en la terminal donde se esté ejecutando, las teclas CONTROL y la tecla C, y escribiendo a continuación el comando:

> killall netmush

No hace falta que lancemos con restart el proyecto, solo usaremos Restart cuando realicemos algún cambio en el soporte del juego que sea necesario resetear, par un arranque normal para crear el Mud bastara con:

>./netmush

… observar que lleva un punto delante de la barra inclinada, si todo fue bien el servidor estará en marcha como aparece en la imagen:

Resumido

Instalar Pennmush, una vez instalado copiar el archivo penn-install y pegar en la carpeta donde deseemos crear el proyecto.

Desde un terminal o cediendo permisos para ejecutarse, penn-install creara la carpeta “pennmush” donde incluirá todo lo necesario para ejecutar el servidor.

Para lanzar el servidor desde una ventana terminal ejecutamos ./netmush. No confundir con Restart que solo se ejecuta cuando realizamos cambios en ciertas partes de la ejecución del servidor.

Una vez ejecutada la orden, le ventana mostrara que el servidor está en marcha, no cerrar esta ventana se necesita abierta oara que el servidor este disponible.

Con el servidor en marcha, es momento de conectar nuestro cliente-Mud, en mi caso Gnome-Mud, como se aprecia en la imagen conecto al localhost o lo que es lo mismo 127.0.0.1 y el puerto el 4201.

En la primera ocasión conectaremos  como Dios (God), que tiene poderes para crear y dar privilegios, por esta razón en la solapa iniciar preparo > connect one one , realmente no es necesario incluir estos datos, los pedirá el servidor del juego sino lo hemos incluido en la conexión.

Una vez conectado el juego se muestra como en la imagen, partiremos desde la habitación (Zero room), lógicamente no hay nada esta todo por crear, como se podrá apreciar en el siguiente apartado La Hora de Crear.

–<>–
La Hora de Crear

Los MUD basan su acción en localizaciones o rooms. Cada una debería tener una descripción del lugar y una lista de posibles salidas.

Creamos un almacén.

> @dig Almacen

Lo que nos genera un identificador #3 (por ejemplo). Podemos, y debemos, referirnos a esa habitación con su identificador para ahorrarnos problemas con espacios y caracteres internacionales. Así, para referirnos a nuestro almacén escribiremos #3.

Nótese que no hemos puesto la tilde en el nombre, lo hemos hecho a propósito para evitar inconvenientes, ya que esta versión de pennmush no trata correctamente los nombres con caracteres especiales.

Creamos a continuación un patio.

>@dig Patio

Que genera como identificador #4. Por defecto las localizaciones no están conectadas, así que es necesario crear salidas. Para crear una salida en nuestro almacén lo primero es teletransportarnos allí.

>@teleport #3

Ahora en el Almacén creamos la salida.

>@open puerta

Nos informará de que la salida creada tiene como identificador #5. Enlazamos esa puerta (identificador #5) con el patio (identificador #4).

>@link #5=#4

Ya tenemos nuestra puerta; ahora podemos desplazarnos al patio y crear una puerta en sentido inverso (por defecto las puertas son unidireccionales), podemos usar la puerta creada para salir al Patio o usar el comando de teletransporte.

>@open Puerta del almacen

Esto genera la puerta #6. Tenemos que unir la puerta #6 con el almacén #3.

>@link #6=#3

Ya podemos pasar de una habitación a otra a través de estas puertas. Repetiremos este proceso para crear todas las estancias de nuestro juego. Sin embargo, no es necesario crearlas todas de golpe. Por ejemplo, podemos crear las estancias de un castillo y más adelante, cuando alguien consiga derrotar o resolver el puzzle que lo sellaba, estarán disponibles nuevas localizaciones, dándonos tiempo mientras tanto para crearlas, por ejemplo.

Objetos

Aunque se podría hacer un juego únicamente basado en localizaciones, lo habitual es que como mínimo haya algunos objetos con los que interactuar. En nuestro ejemplo disponemos de dos habitaciones enlazadas, pero vamos a poner una puerta cerrada entre ambos. Vamos a cerrar con llave la puerta desde el lado del almacén.

Vamos pues al almacén y creamos un objeto llave.

>@teleport #3
>@create llave

La llave tendrá el identificador #7. Ahora necesitamos una cerradura en la puerta, pero no es un objeto normal, es una cerradura o lock. Las cerraduras deben enlazarse con salidas, por lo que vamos a unir la llave #7 con la puerta #5.

>@lock #5=#7

Ahora podemos soltar la llave (lo que creamos lo cogemos automáticamente).

>drop llave

Si intentamos pasar por la puerta no nos lo permitirá. Así que antes tendremos que mirar la estancia para localizar la llave.

>look

Nos informará de que ve una llave. La cogemos y entonces tendremos vía libre para abrir la puerta.

>take llave

Ahora vamos al patio pasando por la puerta sin problemas. Una vez allí, queremos que la puerta también tenga una cerradura en sentido contrario. Lo haremos con:

>@lock #6=#7

La atmósfera es muy importante en la realización de un MUD. Hay que invertir mucho tiempo en escoger buenas descripciones para todos los elementos. Se usa el comando @desc para añadir descripciones a los elementos.

Estas son unas sencillas descripciones a nuestros objetos.

@desc #7=Herrumbrosa llave de bronce bastante pesada.
@desc #4=Patio de armas del castillo con todas sus paredes cubiertas de hiedra.
@desc #3=El almacén del castillo con espacio suficiente para almacenar alimentos.

Además de @desc hay 4 comandos importantes que sirven para dar descripciones en ciertas circunstancias particulares.
@success: mensaje que aparecerá cuando uses o cojas el objeto.
@osuccess: mensaje para los observadores cuando se use o coja el objeto.
@fail: mensaje cuando no podemos usar o coger el objeto.
@ofail: mensaje para los observadores cuando no podamos usar o coger el objeto.

Otros comandos de uso comúnmente utilizados en la creación de Mud’s:

@dig Crea habitación nueva
@desc algo=texto Añade descripción
@set me=sexo Configura sexo (male, female o neuter)
@open Abre una salida en la sala actual
@link Enlaza una salida con una habitación
@unlink Desenlaza una salida
@succ Mensaje de éxito al usar elemento
@osucc Mensaje de éxito para observador
@fail Mensaje de fallo al usar elemento
@ofail Mensaje de fallo para observador
@lock Creación de cerraduras
@find name Encontrar algo
@recycle Destruye un objeto

También podemos crear nuestros propios comandos que se podrán incluir en los diferentes elementos que componen el juego, pero de momento con los comandos de base hay mas que suficiente para empezar a crear Mud’s sin problemas.

Traducción del Juego

El soporte del servidor pennmush en nuestro idioma deja mucho que desear y, al menos en la versión que instala el paquete para Debian, el soporte de caracteres internacionales “falla”. Sin embargo, se nos da la opción de crear traducciones de los comandos. Para ello hay que editar el archivo alias.cnf y añadir traducciones para cada comando en cada línea después de añadir un
espacio. Así la línea:

> command_alias look l

Quedaría de este modo:

> command_alias look mirar

También podemos traducir los mensajes habituales del servidor directamente en los archivos de texto que encontraremos en la subcarpeta txt, dentro del directorio games de pennmush donde encontraremos las subcarpetas con los txt que podemos traducir o mejorar según nuestro gusto para mejorar la experiencia de juego.

Modificar los txt no tiene ningún efecto, mas allá de que el texto que nos pueda presentar pennmush aparecerán en castellano, el problema como anteriormente se comento, es que no he encontrado la forma de que el programa respete las tildes y las eñes, sin alcanzar a comprender el por que de esta situación.

Como norma general las modificaciones realizadas en los archivos descritos, estarán disponibles después de arrancar el servidor, por lo que en algunas ocasiones será necesario parar y relanzar el servidor para que los cambios tenga su efecto.

Y ¿cómo guardo lo realizado…? buena pregunta, en un principio no se aconseja guardar nada hasta tener un manejo del programa suficiente como para crear juegos mas madurados, tener un guión, un plano con las habitaciones o estancias y en definitiva saber lo que se quiere hacer para hacerlo, nos ahorraran mucho trabajo, la planificación es un factor muy importante si no queremos descubrir que el trabajo realizado sirvió para poco o hay que modificar tal cantidad de cosas que lo hace inviable.

No obstante para guardar de forma permanente nuestro trabajo escribir >@shutdown/reboot , con este sencillo comando podemos ir salvando nuestro trabajo, cuando creamos conveniente.

Mi Cuñado Quiere Conectarse

Para que alguien pueda conectarse a nuestro juego desde Internet debemos indicarle nuestra IP externa y el puerto que hemos usado en la configuración. En su cliente tendrá que usar estos datos para conectarse al juego. Si la IP es correcta, el router está configurado correctamente y el servidor está funcionando, logrará conectarse a nuestra pequeña ópera prima.

Fin del Principio

Ahora ya estamos preparados para la creación de nuestro primer, y muy modesto, juego MUD. Si dominar un MUD en calidad de cliente podría rondar las 70 horas, para hacerlo como administrador debemos medir el tiempo en días, meses, años. Las posibilidades son enormes, y además cada servidor MUD es distinto y suele ofrecer un grupo de opciones particulares que no existen en losdemás. Animamos desde aquí a todos aquellos que siempre han querido mostrar su mundo soñado a que, armados de paciencia, se embarquen en la creación de su propio juego MUD.

[1] Obtener IP externa: http://cual-es-mi-ip-publica.com/

Podéis probar una aventura en : > telnet rlmud.org :5001
<–>

Como siempre agradecer a Ximocm que está al quite de lo propuesto, una aclaración para los usuarios de windows.

No debería confundirse el cliente-telnet con el servidor del juego, para dejar claro conceptos, el servidor es Pennmush, y para windows lo podéis encontrar en la siguiente dirección:

http://www.gammon.com.au/downloads/dlpennmush.htm

La instalación no debería suponer ningún problema, ejecutar el EXE que incluye el paquete descargado que debería instalar sus archivos en > C: \\ Archivos de programa \\ PennMUSH, ahora para poner en marcha el SERVIDOR en la ventana de comando de windows escribimos:

> pennmush/run

o lanzamos el SERVIDOR haciendo doble click en el icono correspondiente (acceso directo).

Ahora vamos con el cliente, desde windows vista, los de M$ decidieron que Telnet no estuviera activo, cosa que comparto desde el punto de vista (jeje vista) del servidor, pero este no es el caso del cliente, que es lo que nosotros utilizaremos y como se comento en el articulo anterior para gustos colores con respecto a los clientes-telnet.

¿Pero es que yo quiero usar Telnet en windows…? pues nada no os preocupéis que tan solo es cuestión de activarlo ¿Cómo…? pues en este par de enlaces os explican como que es muy sencillo.

http://www.luis-ortega.com/donde-esta-el-telnet-en-windows-7/

http://es.wikihow.com/activar-Telnet-en-Windows-7

Estupendo, problema resuelto, pero es que yo uso ANDROID, pues tampoco hay problema y además son gratuitos para su descarga desde Google-play estos son de los mas descargados:

BlowTorch MUD Client (este es el que mas uso)
https://play.google.com/store/apps/details?id=com.happygoatstudios.bt

Mukluk MUD Client
https://play.google.com/store/apps/details?id=com.crap.mukluk

LensDroid Mud Client

https://play.google.com/store/apps/details?id=net.lensmoor.lensmoorclient

Recodad que cualquier cliente os pedirá una dirección y un puerto para la misma, y esto es valido para todos Linux, Windows o Android.

Cuando tenga algo de tiempo os subo algún ejemplo para mejorar y mucho lo propuesto hasta ahora, de momento con poner en marcha el servidor y conectar el cliente telnet elegido con lo dicho hasta ahora tenéis para entreteneros un rato, tampoco mucho por que es tan sencillo que una vez realizado nos daremos cuenta de lo extremadamente fácil que puede llegar a resultar.

MEJORANDO LO PROPUESTO

Voy a intentar explicar con mas detenimiento esto del servidor Mud, para empezar no me gustaría entrar en tecnicismos y amalgamas, pero sin comprender el concepto difícilmente se puede llegar a entender lo que se puede hacer con el.

Lo primero es saber como es su estructura de directorios:

pennmush
|
|———- Game
|———- Po

Esto es lo que encontraremos en su directorio, Game y sus contenidos es el que nos interesa, Po representa los archivos de ayuda en los diferentes idiomas.

Dentro de Game encontramos :

Carpetas →
Data // contiene las bases de datos creadas en nuestro juego.
Log // contiene información de los errores e incisos.
Save // para realizar BackUps de las base de datos.
Txt // un montón de información que podemos modificar para mejorar la presentación.
|— connect.txt // mensaje inicial al conectar al Mud.
|— down.txt // mensaje de despedida al desconectar el Mud.
|— full.txt // mensaje que aparece cuando el servidor esta completo de usuarios.
|— guest.txt // mensaje para Invitados Guest.
|— motd.txt // mensaje cuando se conecto al juego, (no confundir con connect.txt).
|— newuser.txt // mensaje para los nuevos usuarios que entran al Mud.
|— quit.txt // confirma que se ha desconectado del Mud.
|— register.txt // mensaje que aparece cuando el registro es necesario via mail.
|— wizmotd.txt // Puede usarse para Wizards o como apoyo en la entrada al Mud.
|___ EVT//HLP//NWS carpetas de apoyo pueden ser necesarias si se amplia el Mud.

Archivos →
alias.cnf // ya explicado se usa para los alias de los comandos.
config.sh // archivo consultado al arrancar el servidor configura su arranque.
mush.cnf // ya explicado ayuda a configurar el servidor al arrancar.
names.cnf // restringe el uso de cierto tipos de nombres o palabrotas.
restrict.cnf // restringe el uso de comando a usuarios en el Mud.
Restart // ya comentado establece ciertas directivas para el uso del servidor.

Para empezar de una forma sencilla, modificaremos el archivo que se nos muestra al inicio de conectarnos al servidor, el archivo en cuestión es el connect.txt que incluye:

<This is where you announce that they’ve connected to your MUSH>
<It’s a good idea to include the version/patchlevel of MUSH you’re running>
<It’s a good idea to include an email address for questions about the MUSH>
—————————————————————————–
Use create <name> <password> to create a character.
Use connect <name> <password> to connect to your existing character.
Use ‘ch <name> <pass>’ to connect hidden, and cd to connect DARK (admin)
Use QUIT to logout.
Use the WHO command to find out who is online currently.
—————————————————————————–
Yell at your local god to personalize this file!

Una buena manera, que no la única manera de empezar es incluir el típico Art-ascii con el que comienzan los juegos mas elaborados, conviene tener en cuenta que el ancho máximo de caracteres con la que trabaja el servidor es de 80 caracteres, a partir de esa cantidad, crea un salto de linea y, es importante contar con ello para que no se produzcan saltos de linea que afeen nuestra presentación, esta norma es valida para posteriores textos o presentaciones.

No me he esforzado mucho a la hora de escoger una imagen, por lo tanto elegí una de las tantas que hay por la red que comparten sus creadores, conviene recordar que los autores suelen firmar sus obras y como tal la respeto y la dejo reconociendo tanto a su creador como su obra, pero vamos a cambiar la presentación…

Como se puede comprobar la presentación y demás textos se pueden cambiar al gusto del creador, la información de estos textos no solo se puede cambiar, también puede describir o arrojar datos sobre nuestro juego o alguna circunstancia especial que merezca ser mencionada.

Si se observa la imagen prácticamente se tradujo y la verdad es que se podría reducir mucho mas, con que el juego te pida un <nombre> y una <clave> es suficiente, debe tenerse en cuenta que el juego da esos datos al creador (God de ahora en adelante Creador) para que entienda las posibilidades de conexión al juego, la mayoría de jugadores no usaran ese tipo de conexiones, ya que en algunos casos según el Creador ceda permisos a usuarios, podrán modificar ciertas partes del juego y eso puede no resultar interesante dejarlo activo a todo el mundo.

Seguramente cuando hayamos modificado todos los txt, querremos hacer algo mas ya que con lo expuesto hasta ahora no hemos creado mucho mas que las dos habitaciones del primer ejemplo, pero vayamos por partes.

Quizá y digo quizá por qué a lo mejor no es necesario, una buena idea seria explicar de que va el juego, detalles o cuestiones que los usuarios deberían tener en cuenta, de momento con modificar los txt hay mas que suficiente, mas adelante veremos como presentar un texto mas elaborado utilizando la Zero-room, que es donde entran los jugadores al conectarse, al menos que cambiemos las directivas del servidor y le digamos otra cosa, como suele ocurrir con ciertos juegos que lo primero que nos indican es que juguemos un pequeño tutorial, este no será nuestro caso, pero puede que algún creador lo quiera realizar de esa forma.

Quien es quien en Pennmush

Ya se ha mostrado la estructura de archivos y carpetas del servidor Pennmush, antes de entrar con el parser, conviene tener claro quienes intervienen en el juego y por ende en el Mud:

Jugador (Player).- Los que están leyendo estas lineas y pueden jugar con la creación.

Marioneta (Puppet).- Objetos creados por Creadores o jugadores, según los permisos otorgados por el Creador, que pueden realizar ciertas acciones en el juego.

Robot.- “Algo” que puede parecer un personaje pero en realidad son un conjunto de scripts.

Maquina (Machine).- Objetos programados para realizar ciertas cosas en el juego.

Banderas(Flag).- Parte del código del servidor que controla el comportamiento de ciertos objetos en Pennmush. Puede estar encendido o apagado y puede activar las salidas de objetos. Es realmente importante en Penmmush y accedemos a su puesta en marcha o parada con el comando @set, las banderas (flags) en los objetos del juego la veremos mas adelante con algún ejemplo, porque tienen bastante peso en la creación avanzada del juego Mud.

Objetos.- Podemos clasificar los objetos en cuatro tipos diferentes:
Jugadores // Cosas // Habitaciones // Salidas  (Players, Things, Rooms, Extis)

Jugador.- Quien se puede conectar al Mud a través de un Nombre y una contraseña, puede poseer cosas, también puede contener funciones independientemente de cualquier otro objeto o cosa en el juego.

Cosas.- Suelen ser objetos móviles, que pueden se utilizados y recogidos por los jugadores participantes, que además se pueden manipular de diferentes formas.

Habitaciones.- Son las estancias de las que está compuesto el juego, también conocidas como Salas siendo estas la unidad mínima de construcción y contenedores del resto de cosas, objetos y salidas.

Salidas.- Son los enlaces que conectan dos lugares en el juego, estas se suelen representar como puertas o indicadores de dirección por la que los jugadores cambian de Sala a Salas.

Dbref.- Con esto nos referimos al número de referencia recogido en la base de datos del juego, normalmente se representa con el prefijo “ #00 “, sin comillas, el indicador es único, los objetos pueden compartir nombres en el juego, pero nunca los indicadores numéricos.

Cliente.- La persona que se conecta al Mud.

Pennies.- Unidad monetaria del juego que puede cambiarse por la que se desee, mas adelante usaremos euros.

Dios.- God, Creador, es la persona encargada del Mud. Mantiene el código y el orden en general. Tiene poderes que no están disponibles al resto de jugadores o ayudantes.

Wizard.- Son los asistentes del Creador, los conocemos como Moderadores y ayudan al mantenimiento del programa, poseen habilidades especiales para ejecutar ciertas acciones en el juego o cambiar partes del código, suelen dividirse aunque no es necesario en:

Royalty.- Especie de asistente, no puede cambiar objetos.
Mortal.- Un jugador normal sin privilegios.
Control.- Todo objeto es controlado por una o mas cosas.
Guest.- Invitado, como el jugador normal, también sin privilegios

Estos son parte de los elementos a los que nos vamos a referir constantemente y conviene saber que es cada cosa y sus posibilidades como limitaciones.

El Parser

Técnicamente es un analizador sintáctico, para los que no lo tienen claro es donde escribimos y damos las ordenes pertinentes, se parece por no decir que es igual al por muchos conocido Prompt> del Ms-Dos y otros, es conveniente tener en cuenta que por lo menos en Gnome-Mud puede ser multilinea, de forma que pulsando CTRL+ENTER creara una nueva linea en blanco que podemos emplear para aumentar las lineas de ordenes o código para introducir al parser.

Los parser pueden tener la posibilidad de recordar comandos anteriormente introducidos que hayamos utilizado y podemos recorrer su pila con las flechas del teclado, concretamente Arriba y Abajo, esto es una ventaja para recorrer los comandos empleados, pero puede ser un inconveniente cuando estamos preparando varias lineas de ordenes, por que al pulsar cualquiera de las dos mencionadas antes de pulsar Enter para validar las ordenes, el parser borrara lo escrito y colocara la ultima orden utilizada volviendo al ultimo comando que usamos, conviene tener esto en cuenta para no perder el tiempo escribiendo o modificando ordenes que podrían perderse por esta causa, Copiar y Pegar será un gran aliado pues nos permitirá probar comandos sin tener que escribirlos.

La sintaxis en el parser debe cuidarse con esmero y con algunos comandos los espacios en blanco pueden ser motivo de error, por lo general el 90% de los errores son provocados por escribir mal el comando o la orden.

El parser interpreta al momento los comandos introducidos, debemos tener en cuenta esta cuestión puesto que cuando los comandos introducidos son muy largos pueden producir errores (generalmente sintácticos) y por este motivo el código se rompe en la linea donde se produjo el error, cuestión que nos avisara con el típico HE?, pero si entre las ordenes anteriores habíamos creado algún objeto, habitación, etc, deberemos ser cuidadosos por que si repetimos las instrucciones ya arregladas, nos volverá a crear una nueva cosa, habitación etc, pudiendo ocurrir que tras varios intentos para depurar las ordenes erradas, nos encontremos con un montón de objetos repetidos, y pasa mas veces de las que nos podamos imaginar si no estamos al tanto.

Por ultimo hay un par de comandos que usaremos mas a menudo incluso los manuales suelen utilizarlos para sus ejemplos de uso con ciertas partes del codigo.

Deforma que para pruebas o ejemplos usaremos Say y Think para comandos que muestren como usarse y su formato para representarse, tambien conviene aclarar la sintaxis usada en esta ayuda que usaré para mostrar el uso y ejemplos, de tal forma que (>) indicara que es una orden que debemos introducir al parser para probar o ejecutar las ordenes que usemos.

>say Hola este texto lo vera todo el mundo en el juego.

>think Hola este no, es solo para la Sala donde me encuentre.

>say Lanzo 1d6 = [rand(6)]

>think Lanzo 1d6 = [rand(6)]

Con lo anteriormente expuesto ya podemos probar cantidad de comandos, unos funcionaran directamente otros deberemos incluirlos entre [código] corchetes para que la función sea tenida en cuenta y ejecutada por el parser, no es lo mismo un comando que una función, de forma muy general diremos que un comando ejecutara una orden y una función por lo general no devolverá nada en pantalla pero realizara instrucciones a nivel interno, creo que para que toso lo entendamos podemos de momento tomar esto como definición muy genérica.

Trabajando el Texto

Para mejorar los textos y la presentación de los mismos, es conveniente tener en cuenta las siguientes instrucciones.

%r   Salto de linea
%t   Tabulador
%b   Espacio en blanco

> think %r Hola %t soy %b un %r%b ejemplo.
Hola   soy   un
ejemplo.

>say %r Hola %r soy %r un %r ejemplo.
Dices:”
Hola
soy
un
ejemplo.”

Podemos centrar, desplazar el texto a izquierda  o derecha,  con la siguientes instrucciones, se completan con la cantidad de caracteres en numero y el grafo elegido al final de la instrucción.

ljust[<texto justificado a izquierdas> , <ancho de la pantalla> , <relleno con el grafo> ]
rjust[<texto justificado a derechas> , <ancho de la pantalla> , <relleno con el grafo> ]
center[<texto justificado al centro> , <ancho de la pantalla> , <relleno con el grafo> ]

>think %r[center(Texto centrado.,80,-)]

—————————————-Texto centrado—————————————-

Con caracteres especiales podemos usar ( \ ) para que el parser no tenga en cuenta el comando o la instrucción de forma que la podemos mostrar en como un texto mas.

>think Comando para ver en pantalla \[rand(6)\] sin generar un numero aleatorio.
Comando para ver en pantalla [rand(6)] sin generar un numero aleatorio.

Los mas entendidos recomiendan que los textos comiencen con %R y %T terminando los mismos con %R.

>think %R%T Hola soy un ejemplo de buena practica en la forma de %Rrepresentar escritos en el juego, se recomienda acabar con \%R %Rpara que el texto siguiente no quede pegado al ultimo que se %Rejecuto en la anterior instruccion. %R

Hola soy un ejemplo de buena practica en la forma de
representar escritos en el juego, se recomienda acabar con %R
para que el texto siguiente no quede pegado al ultimo que se
ejecuto en la anterior instruccion.

Como se puede observar el uso en mayúsculas no cambia en nada el resultado es mas bien cuestión de estética, yo suelo usar estas instrucciones en mayúscula para mejorar el entendimiento y encontrar de forma mas fácil donde introduje este tipo de instrucciones en el texto, haciendo mas fácil de modificar cuando son textos muy largos.

Con lo propuesto se puede mejorar y mucho el texto que presentemos en el juego, recordemos que cada vez que un nuevo jugador entra al juego lo hace en la habitación (Zero-room) y podemos incluir una mejor descripción del juego a aprovechando el comando @desc del objeto habitación, no es la mejor manera pero de momento y hasta saber realizar comando definidos por el usuario lo hacemos así a modo de ejemplo.

>@desc #00= %R%TDescribe el juego que puede contener diferentes elementos:%R%R<Heroes>%RTipos de personajes que participan en el juego.%R%R<Monstruos>%RLos malos malosos que podemos encontrar en el transcurso de la aventura.%R%R<Lugares>%RDonde podremos hacer alguna accion especial como vender o comprar cosas.%RTambien pueden ser sitios de obligado paso o donde dejar nuestros objetos%Rpersonales o cosas.%R%R<Extras> – Lo que se estime oportuno para que los jugadores puedan tener en %Rcuenta, ya sean instrucciones u otras ayudas al juego.%R

Sobre el comando @desc poco mas que decir, se utiliza para la descripción de objetos en el juego he utilizado #00 que corresponde a la habitación (Zero-room) pero podría haber utilizado cualquier otra habitación u objeto.

Con lo propuesto se pueden mejorar y mucho los textos que los usuarios verán durante el juego, vamos ampliar un poco mas la información utilizando una herramienta que nos puede ser de gran ayuda para incluir y mejorar lo propuesto usando algo de ascii y que podemos encontrar en la pagina :

http://www.mushcode.com/Ascii2Mu

Bien, podemos usar esta excelente aplicación para mejorar nuestros texto acompañando a los mismos con una imagen que podemos crear  o reutilizar otras de nuestra cosecha, el resultado puede ser muy interesante y los artistas del Art-ascii lucirse con este programa que genera el código para incluir al juego.

Nota: En Gnome-Mud viene por seleccionado por defecto ( ; ) como divisor de comandos, conviene tener esto en cuenta por que si el dibujo incluye este tipo de carácter será interpretado por el cliente-telnet y el gráfico puede verse alterado, yo lo tengo modificado para que no sea ( ; ), mas adelante hablare del porqué.

>think %R[space(15)]\,@@@@@@@\,%r[space(7)]\,\,\,.%b%b%b\,@@@@@@/@@\,%b%b.oo8888o.[space(5)]Mejorando lo propuesto%r[space(4)]\,&\%\%&\%&&\%\,@@@@@/@@@@@@\,8888\\88/8o[space(4)]con una imagen ascii%r%b%b%b\,\%&\\\%&&\%&&\%\,@@@\\@@@/@@@88\\88888/88’%b%b%bincluyendo algo de texto%r%b%b%b\%&&\%&\%&/\%&&\%@@\\@@/ /@@@88888\\88888’%b%b%bpara tal mejora.%r%b%b%b\%&&\%/ \%&\%\%&&@@\\ V /@@’ `88\\8 `/88’%r%b%b%b`&\%\\ ` /\%&'[space( 4 )]|.|[space( 8 )]\\ ‘|8’%r[space( 7 )]|o|[space( 8 )]| |[space( 9 )]| |%r[space( 7 )]|.|[space( 8 )]| |[space(9)]| |%rjgs \\\\/ ._\\//_/__/%b%b\,\\_//__\\\\/.%b%b\\_//__/_

Este es el código generado por ASCII-2-MU*: Text to MUSHCode Converter.

Observar que no he colocado %T después del salto de linea %R para no desplazar la primera linea de la imagen ascii, esta herramienta puede ayudar en gran manera nuestras presentaciones, los mas puristas no incluyen ningún tipo de imágenes otros son mas permisivos, yo no establezco ninguna norma en este sentido y dependerá de como cada Creador quiere realizar sus proyectos, pero conviene tener en cuenta esta posibilidad y emplear o no esta técnica según el gusto de cada uno. No es lo mismo incluir Ascii en los txt de los archivos que podemos modificar y anteriormente descritos, que hacerlo desde el parser para describir algún objeto o similar.

Con lo expuesto podemos mejorar los textos, poco mas de momento, ¿se puede incluir mejoras ? Si, lo veremos mas adelante por el momento tenemos para ir probando y la retorica que envuelva al juego es sumamente importante, después de todo la mayor parte de la información está escrita y como se dijo anteriormente, requiere dedicarle un buen rato para crear ambiente, pero si además le sumamos algo de Ascii-art el resultado puede mejorar el contexto y por tanto el juego.

Mejorando lo creado y algo mas

> @dig Almacen
Almacén creado con el número de habitación 3
>@dig Patio
Almacén creado con el número de habitación 4
>@teleport #3
Almacén(#3Rn)
>@open puerta
Abierta la salida #5
>@link #5=#4
Linked exit #5 to Patio(#4Rn)
>puerta
Patio(#4Rn)
>@open Puerta del almacen
Abierta la salida #6
>@link #6=#3
Linked exit #6 to Almacén(#3Rn)
>@teleport #3
Almacén(#3Rn)
>@create llave
Created: object #7
>@lock #5=#7
puerta(#5) – Basic locked
>drop llave
You drop llave
>look
Almacen(#3Rn)
Contenidos:
llave(#7Tn)
Salidas Obvias:
puerta
>take llave
You take llave
>puerta
Patio(#4Rn)
Salidas Obvias:
Puerta del almacen
>@lock #6=#7
Puerta del almacen(#6) – Basic Locked

@desc #7=Herrumbrosa llave de bronce bastante pesada.
@desc #4=Patio de armas del castillo con todas sus paredes cubiertas de hiedra.
@desc #3=El almacen del castillo con espacio suficiente para almacenar alimentos.

Recordando como se realizo el ejemplo creado al inicio, el juego de momento esta de la siguiente manera:

[Zero-room]

[Almacen]———–[Patio]
|
[llave]

Hasta ahora solo participa en el juego el Creador pero ¿qué pasaría si se crea un jugador para probar lo que se ha realizado…?, crear al jugador Yoyo para comprobar que ocurre…

Desde Gnome-Mud añadir una nueva conexión y crear el personaje Yoyo, obsérvese que no se ha indicado ningún tipo de comando para la conexión, tan solo el nombre de la nuevo enlace junto con la dirección mostrándose como dirección, 127.0.0.1 y el puerto 4201

En la ventana de conexiones ahora aparece una nueva conexión llamada Yoyo, haciendo un doble click sobre Yoyo se puede conectar con el servidor.

Ni que decir tiene que al servidor se está conectado, pero no se ha entrado al juego, introducir en el parser > create Yoyo yoyo , para crear un nuevo jugador de forma que ahora el servidor reconoce al nuevo usuario con la contraseña elegida.

El servidor dará la bienvenida, si el archivo de texto newuser.txt se cambió se observara que es lo que se muestra en pantalla y el nuevo jugador Yoyo aparece en la habitación Zero-room.

Pero, Yoyo no puede ir a ningún sitio, la habitación no tiene salida alguna, y si no ha cambiado la descripción de la habitación tampoco mostrara ningún mensaje contenido en @desc #0.

Si se observa con detenimiento el cliente-telnet se aprecia que hay dos solapas, la primera One, corresponde al creador, la segunda  para Yoyo que es la que se muestra, se ha aprovechado para examinar a él mismo con el comando:

>examine me

Ojo, por que no es lo mismo introducir comandos en una ventana como la del jugador Yoyo, que hacerlo en la ventana del Creador One, veamos los extraños caracteres que acompañan a Yoyo y lo que significan:

Yoyo(#8PenA)

Yoyo .- Es el nombre del jugador
#8      .- Es el número asignado al jugador en la base de datos (Dref).
P        .- Player indica que el personaje es un jugador normal.
e        .- Bandera (flag) activada, corresponde a ENTER_OK
n        .- Bandera (flag) activada, corresponde a NO_COMMAND
A        .- Bandera (flag) activada, corresponde a ANSI

Las banderas se verán con mas detenimiento por ser una parte muy importante en el juego de momento con conocer de su existencia y que se puede consultar si están activadas como es el caso es suficiente, las banderas (flag) se pueden encontrar en todos los objetos en general.

Actívese por tanto a la solapa del Creador One, para crear una nueva descripción en la habitación y luego crear una salida que comunique la Zero-room con el Almacén.

One debe estar en la habitación Zero-room(#0R), si no es así,  usar el comando @tel #0 para ir a la habitación,( si se intenta usar el comando de teletransporte con Yoyo se denegara el servicio, los jugadores normales no tienen este privilegio), pero eso se puede solucionar, sigamos con el Creador One y, la descripción de la habitación #0 o lo que es lo mismo la Zero-room:

… en la solapa de One

>@tel #0

>@desc #0= %R%TUn imponente castillo con puertas firmemente selladas, %Ren un lateral vemos un porton que comunica con el almacen, ningún humano ha logrado entrar %Ren este castillo sin pagarlo con su vida.%R

>@open Porton

>@link #9=#3

A la nueva salida Portón se la ha asignado la referencia #9 en la base de datos, como se necesita comunicar el Portón con el Almacén, utilizar el enlace @link #9=#3, deforma que cualquier jugador que se conecte al juego empezara en esta sala, y tan solo tendrá una única posibilidad de continuar por el Portón al no existir otra salida.

Por lo general la sala Zero-room se la denomina Limbo, y se puede cambiar de nombre a este o cualquier otro nombre, con el siguiente comando:

>@name #0 = Limbo

Si se utiliza el comando look en la solapa de Yoyo, además de una breve descripción, también se observa la posibilidad de usar la salida Porton, pero antes de eso, se debe preparar la llave y si alguien se pregunta ¿ el porqué ? Es porque se necesita preparar el escenario antes de ser mostrado.

One creará una nueva habitación Armería a la que se accederá desde el Patio, suponga que Yoyo ya está en el Almacén, ha cogido la llave para pasar al Patio y de ahí a la Armería, si entrara otro personaje al juego, se encontraría que la llave no esta en el Almacén porque la tiene Yoyo, ¿cómo hacer para evitar que los personajes porten objetos que pueden ser necesarios a otros jugadores…?

Si se está jugando una partida de Rol y se va creando sobre la marcha, el Creador será el encargado de este tipo de cosas, pero si es un juego “normal” el Creador es muy posible que no este conectado y por lo tanto deberían dejarse estos datos establecidos para que se pueda jugar con normalidad.

… seguir en la solapa de One, el Creador pasó por el Portón y está en el Almacén, escribir:

>@search

Este comando muestra el contenido total de Habitaciones, Salidas, Cosas y Jugadores, cuando el juego es muy pequeño como es el caso, se puede recordar el número asignado a los objetos, pero cuando hay cientos de puertas, salas etc etc, la cuestión se complica, una buena opción seria ir creando un listado de objetos según se avanza en la creación del Mud.

… el Creador desde el Patio crea una nueva Sala con su salida correspondiente:

>@dig Armeria = sur; s, norte; n

Este comando crea una habitación llamada Armería, desde la sala donde nos encontramos ahora ( Patio ) enlaza el Patio con la Armería y viceversa, si escribe look, ahora se verán dos salidas, la primera a la puerta del almacén y la segunda hacia el sur.

De esta forma se crean salidas mucho mas rápido, no es necesario @open puerta xxx y tampoco es necesario @link #xxx=#xxx, el código lo genera automáticamente el servidor ahorrando mucho trabajo al Creador.

Nota.- para que funcione correctamente he cambiado el carácter de división de comando que trae Gnome-Mud en su solapa propiedades, por alguna razón solo interpreta el código hasta que encuentra el primer ( ; ) de forma que se puede cambiar el carácter por otro para que el parser interprete al completo la linea introducida, en este caso uso AltGr+5 que crea ( ½ ) puede ser cualquier otro que no entre en conflicto con el interprete, la razón debe estar en el cliente-Mud, pero no se exactamente el porque.

[Limbo] ——– [Almacén]———–[Patio]
|
[Armería]

Ningún jugador debería pasar a la Armería si está en posesión de la llave, gracias al comando @search sabemos que la salida que comunica el Patio con la Armería es la #11 que corresponde a Sur, y la llave es el objeto #7, de forma que lo que se hará es prohibir el paso al que porte la llave e intente usar esa salida:

>@lock #11 = !#7

Lógicamente el jugador no sabrá que debe tirar (drop llave) la llave si no se le advierte del hecho, de forma que usaremos el comando @fail que muestra un mensaje cuando no podemos usar o coger el objeto.

>@fail #11 = No se puede pasar por esta salida… %Rdebe arrojar la llave para poder pasar.

Con este comando ocurrirá que cuando cualquier jugador intente pasar a la Armería con la llave, le haremos saber que debe arrojarla para poder continuar, obsérvese que se utiliza el carácter ( ! ) que niega el paso al objeto #7 la llave.

… pero ¿qué pasaría si el personaje tira la llave en el Patio…?, pues que la llave no estaría dispuesta para otro jugador que entrara de nuevo al juego y no podría pasar del Almacén.

Para solucionar este tipo de cuestiones con el Creador posicionado en el Almacén escribir :

>@link #7 = #3

…con este comando aseguramos que cualquier jugador que tenga la llave si sale del juego o se desconecta la llave volverá al Almacén…

pero…¿ y si todavía sigue en el juego y la tira la llave en otra habitación…?

>@set #7 = sticky

Este comando hará regresar a la llave desde donde fuera arrojada a la habitación donde se ancla con ( sticky ) por eso la importancia de realizar estos comando en el Almacén para cuando el jugador que porta la llave en el momento de arrojarla, la llave regrese al punto donde se encuentre anclada.

… pero el jugador no sabrá que ha ocurrido si no le advertimos del hecho, para advertir del hecho de que la llave ha sido regresada algún sitio usaremos el comando @drop con la llave:

>@drop #7 = La llave desaparece tras una cortina de humo.

Esto le da un toque mágico, ya que el jugador cuando arroje la llave será advertido que la misma desapareció tras una cortina de humo, pero lo que realmente ha ocurrido es que la llave regreso al Almacén y estará dispuesta para cualquier otro que comenzando la aventura pase por el Almacén y la recoja.

Lógicamente con la cerradura que se incluyo en la puerta del Patio hacia el Almacén prohíbe que el jugador que arrojo la llave vuelva al Almacén, ahora no tiene la llave, pero si podrá continuar la aventura, ya que podrá pasar a la Armería y continuar el juego.

Vamos a comprobar con el jugador Yoyo como quedo preparado el juego desde el punto de vista de un jugador que empieza en el Limbo:

De entre los cientos de correos recibidos he elegido este que comenta:

Estuve creando un sencillo Mud como el propuesto, por la noche cerré el ordenador y me fui a descansar, al día siguiente cuando volví a retomar el Mud, los datos habían desaparecido y nada de lo creado se guardo incluso después de un >@shutdown/reboot.

Esto es algo que puede pasar si no se modifico el archivo <Restart> en la linea  nº 7 que por defecto viene sin ruta, GAMEDIR= /home/usuario/pennmush/game, para los usuarios de windows, GAMEDIR= C:/Archivos de programa/pennmush/game ,de esta forma aseguramos que el juego se guarda, incluso si no deseamos cambiar la linea nº 21 que hace alusión al lenguaje, el servidor Pennmush por lo general optara por usar es_ES.UTF-8, si es el idioma que tenemos seleccionado en nuestra computadora, pero sin la ruta GAMEDIR anterior, el Mud empezara una nueva sesión cada vez que se inicie y no retomara lo creado, “lógico no tiene ruta”, pero no hay porque preocuparse si se salvaron los datos antes de cerrar, bastara con indicar la ruta en el archivo Restart y desde la ventana terminal lanzar >./restart , se observará que se recupera lo creado, pero como se dijo anteriormente no es la mejor manera de lanzar el servidor, una vez comprobado que la sesión anterior fue recuperada(siempre que fuera guardada con >@shutdown/reboot) lo suyo es salir pulsando CTRL+C, eliminar cualquier proceso activo con >killall netmush y lanzar el servidor como se suele hacer normalmente con el comando >./netmush , para los usuarios de windows >pennmush/run o el acceso directo si fue creado.

Una buena forma de saber si la ruta está bien escrita (además de editar el archivo Restart) y que es la correcta, es escribir dentro del Mud >help help , si funciona, sabremos que la ruta es la correcta puesto que nos mostrara un amplio sistema de ayuda disponible para la creación del juego.

Y ya que estamos con las ayudas escribir >help @edit

Bueno como me pude despistar cuando Yoyo repasaba lo creado, me di cuenta de que en las descripciones del Almacén y del Patio se me “olvido” poner un %R (salto de linea)al final del texto y se pueden hacer dos cosas, escribir de nuevo el texto con las correcciones oportunas o utilizar el comando @edit para modificar lo escrito.

El comando examine es un muy buen aliado para el Creador ya que permite examinar objetos y sus contenidos donde podemos encontrar entre otras el código utilizado la sintaxis en muy sencilla examine <objeto>.

… el Creador puede utilizar @edit de la siguiente forma para cambiar la descripción del Patio que tiene como numero en la base de datos Patio(#4Rn):

>@edit #4/desc=Castillo.,Castillo.%R

Ahora si se hiciera look en el Patio, la descripción tendría un salto de linea al final y evita que quede pegado al texto siguiente.

Recordar que se debe guardar el proyecto para no perder los cambios realizados.

Es importante tener en cuenta la coma que divide el texto a buscar del texto a remplazar, pero… ¿que pasaría si el texto que se desea cambiar tiene comas…? pues en ese caso hay que usar llaves para incluir los textos podría ser algo como lo siguiente.

>@edit #x/desc={un Castillo, muy alto},{un Castillo, alto, viejo y, desvencijado.}

HELP es de gran ayuda para saber como emplear comandos, funciones y atributos en Pennmush y no serán pocas las veces que se consulte como implementar código, sin duda una gran ayuda que conviene explorar en todos sus términos.

Otros caracteres que convine conocer:

%#   Dbref del ENACTOR
%n   El nombre del ENACTOR
%N  Nombre del ENACTOR con la primera letra en mayúsculas
%l    Dbref de la localización
%:   Identificador único del ENACTOR,usado en objid(%#)
%c  Muestra el código utilizado
%% Literal % usar también la barra inclinada \

Podemos incluir estos caracteres en los textos utilizados por ejemplo para referirnos al jugador que entre en una sala le advirtamos de algo por ejemplo:

>think Hola [%N] , estas en la guarida de un poderoso dragon.%R%c

>think Te encuentras en la sala [name(loc(me))] bienvenido investigador [%n]

>think Te encuentras en la sala [name(%l)] bienvenido investigador [%N]

Antes de seguir con algo mas avanzado convendrá repasar el comando @lock para utilizar este en otras circunstancias o por lo menos saber como poder emplear este comando.

Normal (Key:<objeto>)
Se aplica a una cerradura simple.
@lock Salida = Llave

Cifrado (key:=<objeto>)
Se pasa el bloqueo solo si es el objeto key.
@lock camino == caballo
Solo el caballo puede viajar por ese camino.

Portado (key:+<objeto>)
Solo pasa quien sea el portador del objeto.
@lock camino = +caballo
Solo pasa quien tenga el objeto bloqueado.

Propiedad (key:$<objeto>)
Se pasa el bloqueo si es el propietario.
@lock miscosas = $me
Solo yo puedo utilizar miscosas.
@lock/page me = !$ * Yoyo
Ni Yoyo ni sus objetos podrían pasar el bloqueo.

Indirecto (key:@<objeto>)
Se puede hacer una referencia a la cerradura de otro objeto y utilizar el resultado.
@lock master.lock = me
@lock Norte = @master.lock
@lock Sur = @master.lock
Las cerraduras hacen referencia al master.lock y puede cambiar todas las cerraduras a la vez.

Atributo(key:<attribute>:<pattern>)
+ <attribute>:<wildcard pattern>
= <attribute>:<wildcard pattern>
Se pueden bloquear atributos específicos que no coincidan con el patrón.
@lock Wchombres = sex:m*
@lock af = name:<g

Evaliación (key:<attribute>/<value>)
La evaluacion de atributos compara resultados, pueden ser directos o indirectos.
@lock Banco = checkmoney/1
&checkmoney Bank=[gt(money(%#),5000)]
Solo los jugadores y objetos con valor > 5000 pueden pasar.
Nota: requiere priviliegios
@lock divisible_por_5 = comprobar/0
&comprobar divisible_por_5 = [mod(%#,2,20),5]
Solo los objetos cuya Dref es divisible por 5 pueden pasar.

Compuesto(key: Key&Key)
Se pueden crear cerraduras booleanas combinando las mismas.
<key> | <key>   esta es una OR
<key> & <key> esta es una AND
<key> !              Esta es una NOT
@lock mensaje = me | *amigo
Tanto yo como mi amigo pueden ver el mensaje.

Con estas cerraduras conviene experimentar y probar para situarlas según se desarrolle el juego en el Mud, las posibilidades son casi ilimitadas, una buena combinación y empleo de estos recursos aplicados a objetos y salidas mejoran sustancialmente lo propuesto.

… pero ¿podemos crear otro tipo de cerraduras sin el comando @lock?, pues claro que si, veamos el siguiente ejemplo:

Tenemos un par de salas creadas la sala A y la B, se trata de un simple puzzle que el jugador tiene que resolver, no es una cerradura propiamente dicho pero funciona de la siguiente manera:

El jugador entra en las sala A donde un letrero le advierte que para poder continuar tiene que resolver un acertijo… en @desc de la sala se incluyo el siguiente texto por ejemplo…

>@desc= Este es un puzzle con letras %R a e k u e r %R Descubre la palabra oculta aventurero.

Estupendo, ahora preparamos la cerradura que no es tal sino una salida oculta, podría ser un espejo como el de Alicia, el cuarto secreto de un mago o lo que desee la imaginación no tiene limites.

Antes se preparó la salida “oculta” de la siguiente manera, como es una salida usamos @open ya de sobra conocido:

>@open eureka ; eureka = #nº de la sala B

No hay mucho que decir crea una salida que se llama eureka que conecta la sala A con la sala B.

>@set eureka = DARK

Con este comando lo que se esta haciendo es ocultar la salida utilizando la bandera(flag) dark, el jugador que entre en la sala A, no vera ninguna salida ya que el Mud oculta la salida eureka por tener la bandera activada… sencillo ¿ verdad ?

De esta sencilla forma se ha creado una “cerradura”, a cualquier jugador le sera imposible visionar la salida cuando entre en la sala, podía ser una adivinanza, una palabra que este escondida en el texto de @desc etc, etc.

Pues de esta manera tan sencilla es como se activan las banderas(flag) en el Mud (@set <objeto> = <Flag>), pero antes….

¿Cómo se desactiva una bandera? Pues igual de sencillo basta con recordar el signo de negación ( ! ) que ya se utilizo con la llave de la Armería.

Y así es como se desactiva una bandera ( @set <objeto> = !<bandera> ) para comprobar su funcionamiento con la “cerradura oculta” usaremos:

>@set eureka = !DARK

Felicitaciones, así es como se activan y desactivan las banderas(flag), esto es valido para todas las banderas de todos los objetos recordamos que eran ( Jugadores // Cosas // Habitaciones // Salidas ) por lógica no todos los objetos tienen todo tipo de banderas de forma que veamos que banderas corresponden a cada tipo de objeto.

Todos los objetos.-
AUDIBLE, CHOWN_OK, DARK, DEBUG, ENTER_OK, HALT, HAVEN, INHERIT, LIGHT, LINK_OK, NO_COMMAND, NO_WARN, OPAQUE, QUIET, ROYALTY, SAFE, STICKY, TRANSPARENT, UNFINDABLE, VERBOSE, VISUAL, WIZARD

Jugadores.-
ANSI, COLOR, FIXED, FORCE_WHITE, GAGGED, JUDGE, JURY_OK, MONITOR, MYOPIC, NOSPOOF, ON-VACATION, SUSPECT, TERSE, UNREGISTERED, ZONE

Cosas.-
MONITOR, DESTROY_OK, PUPPET, NO_LEAVE

Habitaciones.-
ABODE, FLOATING, JUMP_OK, MONITOR, Z_TEL, NO_TEL, UNINSPECTED

Salidas.-
CLOUDY

PennMush es grande no, realmente es inmenso y la combinación de los diferentes elementos darán como resultado un juego estable, con nivel profesional y con muchísimas posibilidades, cuando se comentaba que la curva de aprendizaje podía ser de días, meses o años no estaba faltando a la verdad y esto solo es una mínima parte, hay mucho mas.

Si alguien creía que habíamos acabado con el comando @lock, craso error, ya se ha dicho que PennMush es inmenso y para muestra un botón… mejor dicho mas de código.

A continuación se describen otros tipos de cerraduras. Por ejemplo, para establecer una en  ” @lock/ enter” se debería utilizar:

@lock/enter cosa=otracosa

/enter
¿Quién puede entrar en el objeto de un / Jugador ?
Bloquea un objeto, la restricción le permite entrar en el objeto. Sólo los objetos que incluyen ENTER_OK se pueden modificar, independientemente de la llave.

Tenga en cuenta que la cerradura enter de un objeto o habitación se utiliza como un objeto maestro en una Zona determinada será el control de esa zona. Tenga en cuenta que si usted está utilizando una habitación como una ZMO (es decir, como una zona sala principal), sólo los controladores de esa zona podrán teletransportarse a esa habitación (que es una buena idea para la seguridad del Mud).

/teleport
Controla quién puede teletransportarse a una habitación.

Sólo las personas que pasan el bloqueo teleport de la habitación, suelen ser magos o moderadores, o quien creo la habitación, se les permitirá teletransportarse a la habitación. (Tenga en cuenta que esto es diferente de NO_TEL, que impide a las personas teletransportarse a una habitación). El bloqueo de teletransporte se evalúa incluso si la habitación es JUMP_OK – en otras palabras, si usted está tratando de teletransportarse a una habitación que no controla, la habitación deberá tener la bandera  JUMP_OK, activada y usted tiene que pasar el bloqueo de teletransporte.

/use
Controla quién puede utilizar el objeto

Establece el uso en un objeto, restringe que se puedan desencadenar “use” en el conjunto de registros de la base de datos, y que se puedan utilizar los comandos $ en los objetos. La persona está tratando de utilizar el objeto o sus comandos especiales, no podrá pasar el bloqueo, mostrando, “Permiso denegado”.

                        /page      Quién puede usar la página del jugador
                             /zone      Quién puede controlar objetos en esta zona
                                             /parent    Quién puede usar @parent de este objeto / habitación
                                      /link      Quién puede usar @link de este objeto / habitación

/mail      Quién puede mandar mails
                                         /user:<name>    El usuario definido. No puede crear funciones
                         /speech  Quién puede hablar / posar / emitir en esa sala
                 /listen      Quién puede  trigger o @listen/^-patterns

/leave      Quién puede  @leave el objeto
/drop      Quién puede tirar el objeto
          /give      Quién puede dar a alguien el objeto

OBJETOS

Lo anteriormente comentado contenía mucha información textual, y se hacia referencia a las banderas, estas se podían incluir  en  ( Jugadores // Cosas // Habitaciones // Salidas ) observemos con mas detalle estos objetos.

Empezaremos por los jugadores. En la ventana de Yoyo…

>ex me

He utilizado la sintaxis reducida de examine, de hecho es lo mismo escribir >examine Yoyo, que >ex me , lógicamente estoy en la ventana de Yoyo y cuando me refiero a mi (me) es lo mismo que si hubiera escrito Yoyo, me, #nº del objeto jugador en la Dbref(referencia en la base de datos).

Todo esto es lo mismo:

>examine Yoyo // > ex Yoyo // >examine #nº Dbref // >examine me // >ex me // >ex #nº Dbref

… este comando actúa de diferente manera si es el Creador quien lo ejecuta a que lo haga un simple usuario, excepto >examine jugador con él mismo, pero con otros objetos solo mostrara su >@desc , es mejor probar creando un par de jugadores ver los resultados, pero antes de ver un sencillo ejemplo veamos que contiene el objeto Jugador una vez examinado.

Jugador(Player)

La primera parte ya fue comentada, de modo que pasamos por encima recordando que es el nombre del jugador y las banderas asignadas.

A continuación vendría la descripción del objeto si es que se incluyo alguna, podría ponerse:

>@desc = Un jugador del Mud, investigador de Arkham y lo que se estime oportuno.

Propietario.- el propietario, la persona que creo el objeto, lógicamente Yoyo. Y el dinero que porta el jugador, si se utiliza el dinero en el juego se mostrara la cantidad del jugador en esta solapa.

Parent.- hay veces que los objetos pertenecen a otro objeto y se establece un parentesco con el objeto Padre,  pasamos por encima pero conviene saber de su existencia.

Después hay tres @lock, que establecen bloqueos sobre el objeto, por ejemplo podemos impedir que alguien nos coja como si fuéramos un objeto mas entre otras ver @lock ya comentado.

Poderes.-  se refiere al tipo de permisos que nos puede dar el creador y por lo tanto las restricciones a las que estaremos sometidos por esta causa.

Canales.- Si ha creado un canal Chat aparecerá como tal en esta solapa, con el comando >@channel/add <channel> se puede crear un chat, con determinadas propiedades, pero debe tener permiso o privilegios para crear un canal, en el archivo mush.cnf encontrara en la linea 297:

max_player_chans 0

Si está situado a cero, los jugadores no podrán crear canales Chat, hago aquí una parada para que los Creadores tengan en cuenta que los recursos de consumo en cuanto al flujo del Mud puede verse ralentizado si deja crear a los usuarios muchos canales Chat, para probar que funciona puede cambiar la linea e incluir 2 o 3, pero hay que tener en cuenta que en el hipotético caso de que cada jugador pueda crear 3 canales por ejemplo, y se conectan al servidor 1000 usuarios y cada uno crea 3 canales de chat, el total que deberá soportar el servidor serán 3000 canales con el consiguiente consumo de flujo en el servidor. No suele estar activo la creación de canales para los jugadores, pero si fuera necesario con un canal por usuario es mas que suficiente.

No será la ultima vez que editemos este archivo para dar directivas al juego pero veremos algunas un poco mas adelante, de momento con saber de su existencia es suficiente.

Alertas.- las alertas nos avisan sobre los objetos creados y sus posibles circunstancias en el juego, por ejemplo nos pueden advertir de que tenemos habitaciones sin salidas, de salidas que no están totalmente comunicadas y otras. Interesante pero muy avanzado, se debe ser un usuario avanzado para utilizar esta alternativa.

Creado.- cuando se creo el personaje.

LAST.- ultima conexión al juego del personaje.

LASTFAIL.- recoge el uso del @fail en la ultima ocasión.
LASTLOGOUT.- recoge cuando fue la ultima vez que salio el personaje del juego.

LASTSITE.- ultima conexión generalmente suele ser localhost.

MAILCURF.- coreo enviado.

MAILFOLDERS.- contenido de la carpeta de los correos recibidos.

Hogar.- donde el personaje tiene su casa, suele ser utilizado para dejar sus cosas, los personajes en el Mud tienen la posibilidad de crear sus salas personales.

Lugar.- donde se encuentra ahora el personaje.

Tanto la creación de salas u objetos y salidas tienen un costo que repercute en el dinero que el personaje posee, en la mayoría de Mud’s no se suele utilizar o mejor dicho no tienen permisos para crear objetos, para restringir comandos se puede editar el archivo restrict.cnf donde se pueden dar o restringir los comandos que podrán usar los personajes.

Cosa(thing)

En la imagen se puede observar que he usado al Creador para examinar el objeto Llave, lo he realizado de dos formas diferentes pero muestran el mismo resultado, si intentáramos usar el comando examinar desde la solapa del personaje Yoyo el resultado seria diferente mostrándonos solo la descripción del mismo.

llave(#7TSn)

Se puede observar que en primer lugar el nombre del objeto, entre paréntesis el numero adjudicado en la base de datos la (T) se refiere a que es un objeto en ingles thing, la (S) se refiere a la palabra inglesa pegajoso que como se comento anclaba el objeto con el lugar indicado y por ultimo(n) se refiere a la bandera NO_COMMAND la veremos mas adelante.

Tipo.- que objeto es, en este caso es una cosa y a continuación en la misma linea las banderas activas que tenga el objeto “cosa”.

Si se incluyó alguna descripción con el comando @desc sera mostrado.

Propietario.- quien creó el objeto, la zona del mismo y el dinero que costo crearlo.

Poderes.-  se refiere al tipo de permisos que tiene el objeto otorgados por el creador y por tanto las restricciones a las que estará sometido por esta causa, por ejemplo la posibilidad de teletransportar al personaje que lo posea.

Alertas.- las alertas nos avisan sobre posibles circunstancias en el juego con el objeto. Interesante pero muy avanzado, se debe ser un usuario avanzado para utilizar esta alternativa.

Creado.- cuando se creo el objeto “cosa”.

Ultima modificación.- cuando fue modificado por ultima vez.

DROP.- lanzar, tirar, si se ha incluido algún comando en el objeto aparece con el texto incluido cuando se genero y el contenido del mismo.

Hogar.- donde regresa si es arrojado.

Lugar.- donde se encuentra el objeto.

Salida(Exit)

Porton(#9E)

El nombre del objeto y entre paréntesis nos indica el numero adjudica en la base de datos y (E) que indica que es una salida (Exit).

Tipo.- lo que es el objeto Exit y a continuación las banderas que tenga asignadas el objeto.

Propietario.- quien creo el objeto, la zona si la tiene asignada y el costo en Pennis del objeto.

Parent.- hay veces que los objetos pertenecen a otro objeto y se establece un parentesco con el objeto Padre,  pasamos por encima pero conviene saber de su existencia.

Alertas.- las alertas nos avisan sobre posibles circunstancias en el juego con el objeto. Interesante pero muy avanzado, se debe ser un usuario avanzado para utilizar esta alternativa.

Creado.- cuando se creo el objeto “cosa”.

Ultima modificación.- cuando fue modificado por ultima vez.

Fuente.- de donde parte la salida.

Destino.- a donde lleva la salida.

Habitación(Room)

Sala Ejemplo(#13Rn)

El nombre del objeto y entre paréntesis nos indica el numero adjudica en la base de datos, (R) que indica que es una habitación y (n) que tiene activa la bandera NO_COMMAND.

Tipo.- es un objeto Habitación y a continuación las banderas que tenga asignadas el objeto.

Propietario.- quien creo el objeto, la zona si la tiene asignada y el costo en Pennis del objeto.

Parent.- hay veces que los objetos pertenecen a otro objeto y se establece un parentesco con el objeto Padre,  pasamos por encima pero conviene saber de su existencia.

Creado.- cuando se creo el objeto “cosa”.

Ultima modificación.- cuando fue modificado por ultima vez.

Contenido.- los objetos  que contenga dicha habitación pueden ser cosas como la Llave, otros jugadores que pasen en ese momento.

Salidas obvias.- las salidas que contenga la sala, en esta ocasión como no cree ninguna para el ejemplo no se muestran, si cualquier jugador normal intentara examinar Sala XXX , se mostrara el contenido incluido en @desc.

Conviene tener en cuenta cuenta que modificando ciertas directivas del archivo mush.cnf se pueden dar permisos o restringir el uso de los mismos, que modificando el archivo restrict.cnf de igual forma podemos dar o restringir permisos de ciertos comandos y esto es una importante cuestión para ir dando forma al MUD, veremos algún ejemplo sencillo con mas detenimiento, pero será mas adelante, antes se verán otros que están íntimamente ligados como se habrá podido ir observando si se ha leído este articulo con la calma necesaria para entender el concepto global de lo que es este inmenso gigante llamado MUD.


El entorno y su relación entre objetos

Lo mas normal cuando se entra en este tipo de juegos basados en Pennmush puede ser saber quienes están jugando y como comunicarnos con ellos.

He creado un nuevo jugador Yuyu para ver como desde diferentes solapas como actúan los comandos en el tema de la comunicación entre jugadores, para averiguar quienes están jugando podemos escribir desde su solapa:

>WHO

>WHEREIS Yoyo

>WHEREIS One

Foto Who//whereis

One y Yuyu están en la misma sala Limbo y Yoyo en la Armería, pero como Yuyu no lo sabe usa el comando WHEREIS para averiguar en donde esta Yoyo y One (bueno con One no es exactamente cierto ya que aparece como contenido de la sala Limbo cuando entra Yuyu al juego).

En la solapa de Yoyo el programa nos advierte que el jugador Yuyu se interesa por nuestra ubicación.

Y lo mismo ocurriría con One.

El poder tener varias solapas con los diferentes jugadores y el Creador en el cliente-telnet fue la razón por la que me decante por usar este cliente para realizar estas pruebas, es un magnifico aliado, pero continuemos.

El comando WHO ampliado y solo para Creadores es SESSION con detalles mas concretos de la actividad de cada jugador conectado.

>SESSION

Ya se ha comentado el comando (say) pero hay otras formas de comunicación que conviene saber de su existencia ampliando mas el conocimiento del programa como puede ser el caso de ( “ ) las comillas que viene a ser lo mismo y añade nuestro nombre antes del mensaje.

>Say Esto es un mensaje y solo lo ven los que esten en la misma sala.

>”Esto es un mensaje y solo lo ven los que esten en la misma sala escrito con comillas.

>; Esto es un mensaje y solo lo ven los que esten en la misma sala escrito con punto y coma.

>: Esto es un mensaje y solo lo ven los que esten en la misma sala escrito con dos puntos.

Y esto es lo que aparece en la ventana del jugador que este en la misma sala independientemente de que sea el Creador o un jugador normal.

En definitiva los comandos anteriores son la versión reducida de (pose) si va usarse el ingles como idioma se puede consultar el manual para ver su uso de otras formas sobre los posesivos ingleses y su representación, recuerde que seria >help pose , dentro de Pennmush.

Imaginemos que estamos en una sala con un montón de objetos y no nos interesa que el resto de los jugadores que estén en la misma sala vean, esto podría ser una clave escondida dentro de varias cajas o unos libros que una vez leídos nos dan una clave.

Para este tipo de mensajes podemos contar con @emit y @pemit, el primero es visible a todos los que estén en la misma sala y el segundo solo sera visible al jugador que lo ejecuta o a quien deseemos en concreto que vea el mensaje.

>@emit  Esto lo ven todos los jugadores de la sala.

>@pemit %# = Esto solo lo ve el jugador que lo ejecuta que es %#.

>@pemit %N = Esto solo lo ve el jugador que lo ejecuta que es %N.

Recuerde los caracteres de substitución ya comentados para %xxx. Para conformar el uso de los comandos @emit, @pemit consultar el manual para ampliar información, estos dos comando son frecuentemente utilizados en las creaciones de Mud’s mas avanzadas.

En ciertas ocasiones es posible que deseemos comunicarnos en privado y contamos con un par de comandos para realizar esta acción.

Los comandos “page” y “whisper” pueden servir al efecto, su forma reducida es ( “p” y “w” ) y se utilizan para esto con la forma page <persona> = <mensaje> o whisper <persona> = <mensaje>.

Whisper envía un mensaje privado a un jugador siempre que este en la misma habitación. Puede usarse para hacer consultas en privado con otros jugadores, cuando el jugador este en una habitación diferente el uso de “page” será la solución con la sintaxis propuesta incluso puede enviar un mensaje a varios jugadores usando  < page Yoyo Yuyu = mensaje para los jugadores. >

Una vez se haya enviado un mensaje privado a un jugador en concreto, no hace falta que vuelva a poner su nombre al menos que quiera mandar un nuevo mensaje privado, a un nuevo jugador, la sintaxis seria < page texto para el jugador con el que contacto en primer lugar.> conviene tener esto en cuenta porque “page” volverá a enviar el mensaje a la ultima persona a la que se lo envío usando esta formula “p = <mensaje>” o “p <mensaje>”

> page Yuyu = Este es un mensaje privado para Yuyu que puede estar en otra Sala.

>p Mensaje para la ultima persona a la que envio un mensaje privado.

>page Yoyo Yuyu = Este es un privado para los dos jugadores, pueden estar en salas diferentes.

>whisper  Yoyo = Privado para Yoyo debe estar en la misma habitación.

Para terminar la forma habitual de bloquear la posibilidad de recibir mensajes puede realizarse de dos maneras, con la bandera HAVEN podemos bloquear los mensaje “page” que pudieran mandarnos, aun así leer @haven en el manual del Mud para ampliar información, la otra posibilidad es un bloque @lock/page, se describió en lineas anteriores.

Para evitar que un jugador nos envié “page” usar la sintaxis:

“@lock/page me=!*<player>”
Para evitar que todos los mensajes “page” se puedan enviar excepto algún <player> usar:

“@lock/page me=*<player>” o todos con “@lock/page me=#0”

La bandera GAGGED, cuando se establece en una persona, le limita a mover y mirar objetos en el juego. Esta opción sólo puede ser establecido por los Creadores, y se utiliza como un castigo para los jugadores que están siendo particularmente molestos.

-<>-

Interactuando con Objetos

Lo mas usual es encontrar objetos repartidos por las salas como se pudo comprobar con la Llave del Almacén/Patio.

Preparando objetos

Pennmush esta sujeto a un sistema monetario donde los usuarios normales pueden crear ciertos objetos  con un coste en Pennies como moneda y puede ser consultada con el comando inventario ( i ) inventario, nos muestra los objetos que llevamos y el dinero que tenemos.

[El nombre del sistema monetario puede ser cambiado para utilizar euros, por ejemplo, para poder cambiar el sistema monetario es necesario editar el archivo “mush.cnf” en las lineas 196, 197 se encuentran las lineas que podemos modificar para este efecto. Reiniciar el juego y ya estará disponible la nueva moneda.]

Según el sistema del juego por defecto, deja la posibilidad de que los jugadores normales puedan crear ciertos objetos a ciertos precios que le serán restados de su montante en euros.

[Para restringir el uso de comandos se puede editar restrict.cnf entre las lineas 31 a 47, se pueden modificar los permisos de estos comandos,con respecto a los jugadores que entren al Mud, estableciendo como, o quien puede utilizarlos. En la imagen se muestran los mas usuales, para ampliar la información consultar en el Mud >help restrict ]

>HELP restrict2

Esta ayuda le indica a quien le puede restringir el usos de comandos.

Dar y recoger objetos

Para dar y recoger objetos se suele utilizar Take y Give, también Drop deshacerse de objetos del inventario del personaje. Para que el Creador le entregue 5 euros a Yoyo, por ejemplo.

[Desde la solapa de One-Creador]

>give 5 to Yoyo  // es preferible incluir el Dbref  del jugador >give 5 to #8

Sintaxis.-
“give <player>=<objeto>”  //  “give <objeto> to <player>”

“take <objeto>”    //   “get <objeto>”

“drop <objeto>

Con los comandos anteriores se puede coger y soltar objetos, los objetos recogidos por cada personaje se pueden consultar en el inventario ( i ) del jugador.

Objetos fijos, anclados y otros

Para crear un objeto que fijaremos a una Sala, creamos el objeto Cartel:

>@create Cartel
>@desc Cartel=%R%TSoy un objeto fijo no se me puede coger.%R
>@lock Cartel=here

Para crear un objeto anclado que puede ser recogido, usado y regresar a la sala de origen donde estaba depositado. Conviene usar el numero de la Dberf mejor que el nombre y aprovechar la acción Drop del objeto para incluir algún mensaje…

>@create Llave
>@link Llave=here
>@set Llave=sticky

… cuando se suelte el objeto aprovechando el Drop del objeto.

>drop Llave=Texto mostrado cuando se lanza el objeto Llave y regresa a su ancla(sticky).

Un comando muy util para el Creador es @tel , gracias a este comando podemos dejar objetos en las habitaciones que se desee para poder hacer pruebas en Mud.

>@tel <objeto>=<Sala destino>

[Desde la solapa del Creador]

>@tel Yoyo=#0

El comando anterior teletransporta a Yoyo a la habitación Limbo(#0), es útil para hacer pruebas con las modificaciones realizadas, si se necesita cambiar objetos de lugar. Este comando está solo habilitado para los Creadores.

Activando y desactivando Banderas y Atributos

Para activar banderas ya se conoce el comando y su sintaxis:

@set <objeto>=<flag>  y desmontadas son @set <objeto>=!<flag>

…pero ¿que ocurre con los atributos de los objetos?

Para eliminar atribuciones debemos observar cual de ellas esta activada en el objeto, por ejemplo queremos eliminar todos los bloqueos del jugador que tenga establecidos con @lock,  que son los casos (Basic, Enter, Use) la sintaxis es:

Basic
>@lock  <objeto>

Enter
>@lock/enter <objeto>
Use
>@lock/user <objeto>

Para quien desee ampliar su conocimiento al respecto, debería consultar en la ayuda el comando “@conformat” que remplaza el código por otro determinado por el Creador.

>@conformat here=Contenido:[iter(%0, name(##))]

… para las Salidas de las habitaciones.

>@exitformat here=Salidas:[iter(%0,name(##))]

… para cambiar el Nombre de la sala.

>@nameformat here=%1[if (isdbref(zone(%0))) ,<[name(zone(%0))]>)]

Para Cambiar atributos debemos usar el Creador y eliminar atributos que tenga activos el objeto por ejemplo:

>&LAST <objeto>

Borra la referencia a la hora de la ultima vez que se conecto al Mud.

>&LASTFILED <objeto>

Borra la referencia al atributo que guarda la referencia del ultimo fallo al usar o coger algún objeto.

Nota: Observar que se usa ( & ) en el caso de los atributos y, ( @ ) para los comandos que activa o desactiva ciertos tributados como @lock u otros.

Con lo expuesto se puede modificar el comportamiento de los diferentes objetos activando o desactivando, su atributos y sus banderas, cada objeto tendrá sus propiedades que podrán ser modificadas si se desea, en algunos casos se hace necesario modificar el objeto para ampliar su función o interactuar de alguna manera en el juego, en otras sera necesario cambiar directivas en los archivos “ mush.cnf. y restrict.cnf “ para configurar otras por defecto. Recodar que se debe guardar el proyecto para que las modificaciones se mantengan.

Un paso adelante el Comando ( $ ) definido por el usuario.

Pennmush nos permite crear nuestro propios comandos, estos nos ayudaran a mejorar la experiencia del juego, mejora la interactividad y da sensación de realismo.

Preparando el objeto

Lo primero a modificar pueden ser las banderas, para que se puedan activar los comandos personalizados, se debe desactivar la bandera NO_COMMAND, esta bandera impide que los $comandos puedan ejecutarse donde estén activos :

>@create Libro

>@desc Libro=Deberia OJEAR con mas detenimiento este libro.

>@set Libro=!NO_COMMAND

Creando el comando $ojear *

Con el objeto Libro liberado de la bandera NO_COMMAND, crear el comando de forma:

&<nombre del atributo> <nombre del objeto> = $<nombre del comando> : <lista de acciones>

…para crear un libro, que al ser “ojeado” nos teletransporte hacia otra habitación.

&comando Libro=$ojear*:@tel %#=#<habitación deseada>

>@cm Libro=$ojear*:@tel %#=#3

La sintaxis se descompone de la siguiente forma:

& .- crea el atributo con el nombre proporcionado.
Libro .- <objeto> preferible #nº dbref.
$ .- crea el comando que se debe escribir en el parser, el * es un comodín de texto.
: inicia las lista de acciones.
@tel %# .- comando que ejecuta el teletransporte, se refiere al usuario.
=#<habitacion deseada> .- lugar a desplazar el objeto.

Antes de arrojar el objeto, hay que activar la bandera JUMP_OK que le permite a la sala <habitación deseada> que lo tenga activo, recibir objetos teletransportados.

>@set #3=JUMP_OK

… Activa la bandera Jump y Tel del Almacén(#3R)

Ahora se puede “soltar/drop” el objeto Libro, los jugadores normales, podrían coger y usar el Libro,  en otro momento o en otra habitación, pero puede anclarse a la sala con @lock <objeto>=<habitación> , de forma que el objeto no pueda recogerse, lo que no quiere decir que se pueda interactuar con el objeto, por ejemplo escribamos en el parser:

>drop Libro

>@lock Libro=here

>ojear libro

… Ejecuta la lista de acciones contenidas a partir del comando $xxx : ,del objeto Libro.

Tachan..!!! teletransportado al Almacén(#3Rn)

————<>———–
DEL BLANCO Y NEGRO AL COLOR EN MUD

[/size]

Antes de comenzar, con el Mud, se necesita editar el archivo “mush.cnf”, se va activar la bandera color para los jugadores, podría activarse la bandera desde el parser, pero si la incluimos por defecto vendrá otorgada cuando se cree el objeto jugador.

Editar el archivo “musch.cnf” encontrara en la linea 805 las banderas asignadas a los jugadores, se incluirá una nueva linea, justo a continuación de la instrucción “player_flags ansi”, escribimos en la linea 815 “player_flags color”, para establecer la bandera como opción base. Guarde el archivo y reinicie el Mud para que los cambios tengan efecto.

Los objetos jugadores creados a partir de la modificación de “mush.cnf” incluirán la bandera COLOR activada, en caso de jugadores creados con anterioridad, puede modificar su bandera manualmente en el parser:

@set <objeto>=COLOR

Con la bandera COLOR activada podemos incluir colores a los textos o art-ascii, el jugador vera los colores incluidos al código del Mud, por ejemplo en una descripción:

>@desc <objeto>=[ansi(r,texto de prueba en color rojo)]

>@desc <objeto>=[ansi(v,texto de prueba en color verde)]

también se puede probar directamente en el parser con:

>think [ansi(r,texto de prueba en color rojo)]

>think ansi(fc Texto)

>think %r[center([ansi(hg,EL SALON DEL ATLAS).],80)%r%rMapa sala actual(@You, #Closet, *Exit)%r%r[ansi(n,%b%b%b[ansi(red,#)]%b%b%b)]%r[ansi(n,%b%b%b%|%b%b%b)]%r[ansi(n,[ansi(r,#)]%-%-[ansi(y,@)]%b%b%b)]%r[ansi(n,%b%b%b%b%\%b%b)]%r[ansi(n,%b%b%b%b%b[ansi(g,*)]%b)] ]

>think %b%b%b_________________________________%r%b%b|[space(9)]|%b%b|[space(8)]|%b%b[ansi(g,#)][space(8)]|%r%b%b|Cocheras [ansi(g,#)]%b%b| Alcoba |%b%b|Biblio- |%r%b%b|[space(9)]|%b%b|[space(8)]|%b%b|teca[space(4)]|%r%b%b|_________|%b%b|___[ansi(g,#)]____|%b%b|________|%r%b%b|[space(33)]|%r%b%b|______ __[space(4)]________[space(4)]__ _____|%r%b%b|[space(6)][ansi(g,#)]%b%b|%b%b|%b[ansi(hb,MIS)]%b%b%b%b|%b%b|%b%b[ansi(g,#)][space(5)]|%r%b%b|Vesti-%b%b%b|%b%b|%b%b%b[ansi(hb,TE)]%b%b%b|%b%b|Panteon |%r%b%b|bulo[space(5)]|%b%b|%b%b%b[ansi(hb,RIO)]%b%b|%b%b|[space(8)]|%r%b%b|_____[ansi(g,#)]___|%b%b|________|%b%b|__[ansi(g,#)]_____|%r%b%b|[space(33)]|%r%b%b|_________[space(4)]___ ____[space(4)]________|%r%b%b|[space(9)]|%b%b|%b%b%b[ansi(g,#)][space(4)]|%b%b[ansi(g,#)][space(8)]|%r%b%b| Bodega%b%b[ansi(g,#)]%b%b| [ansi(y,Salon)]%b%b|%b%b|Labora- |%r%b%b|[space(9)]|%b%b|[space(8)]|%b%b|torio%b%b%b|%r%b%b|_

El comando help ansi() se muestra las posibles combinaciones para incluir el texto coloreado.

Un par de trucos básicos y un Comando Global

Para crear un Comando Global, se crearán tres habitaciones, cada una de ellas tendrá un Comando de Usuario que mostrará un (plano), el Comando Global(mapa) es un tanto especial ya que abarca a todas las habitaciones y para declararlo debe hacerse en una habitación especial y estar declarado en un objeto. Antes de clonar la habitación plantilla, podemos preparar algunos aspectos para ahorrarnos trabajo.

A la hora de construir más rápido puede interesarnos tener creada una plantilla o utilizar una sala como plantilla, de esa forma la nueva habitación clonada tendrá las mismas propiedades que su clone(copia), con (@clone <objeto>) podemos crear un nuevo objeto idéntico al apuntado, de forma que se puede usar como plantilla para crear habitaciones.

Antes de clonar el objeto sala, debemos preparar la plantilla que consistirá en una modificación que cambie el Nombre, ahora aparecerá centrado y de color verde:

>@nameformat here= %R%R.[center([ansi(hg,%b[iter(%0,name(##))]%b)],80,-)]

Con este comando damos dos saltos de linea y ponemos el Nombre de la sala en verde, recordar que para ver el color debe estar activada la bandera COLOR, y un par de espacios a cada lado del nombre que rellena, hasta 80 caracteres con guiones.

Se modifica el contenido de la sala para añadir color a los objetos contenidos.

>@conformat here=Se ve a:%b[ansi(b,[iter(%0,name(##))])]

A la vista tienes: One, Libro

Se modifica las salidas de las salas para que se muestren en color verde.

>@exitformat here=Salidas:%b[ansi(g,[iter(%0, name(##))])]

Salidas: norte, puerta

Por ultimo, se crea una caja que contendrá al texto, que está vacía para su posterior uso en cada sala, de modo que preparamos la habitación con :

@desc here=*[center(, 80,)]*%R*[center(, 80,)]*%R*[center(, 80,)]*%R*[center(, 80,)]*%R*[center(, 80,)]*%R*[center(, 80,)]*%R*[center( ,80,)]*%R*[center(, 80,)]*%R*[center(, 80, )]*%R*[center( ,80,-)]*%R

… esto nos creara una caja ascii, donde podremos incluir una breve descripción para cada sala, si lo deseamos.

Trabajar con texto anterior parece un galimatías de mucho cuidado, un truco es usar el procesador de textos del parser, nos permite trabajar por lineas, como ya se comento y es mas fácil y rápido crear el texto de la siguiente forma:

@desc here=*[center(Titulo, 80,)]*%R
*[center(Texto que se desea incluir, 80,)]*%R
*[center(…otro texto incluido en otra linea, 80,)]*%R
*[center(, 80,)]*%R
*[center(, 80,)]*%R
*[center(, 80,)]*%R
*[center(, 80,)]*%R
*[center(, 80,)]*%R
*[center(, 80,)]*%R
*[center(,80,-)]*%R

El inconveniente del sistema es que luego se deber volver a unir el texto para eliminar los saltos creados, pero es muchísimo mas fácil y rápido, crear los textos usando este “atajo”.

Ahora ya podemos clonar la plantilla con todas las propiedades que hayamos establecido, con( @clone <objeto> ), y repetir las veces que se deseen.

>@clone #0 es el comando que nos permite clonar objetos en MUD.

Es buena idea guardar el patrón como copia de seguridad, al resto de salas creadas se les puede cambiar el nombre e incluir texto para cada habitación, con el comando ( @name <objeto>=<nombre> ), se pueden renombrar las salas clonadas.

Con @open y @link pueden unirse las salidas a las salas que se desee, además se incluirá un Comando Definido por el Usuario -$comando que muestre el plano de la habitación con las salidas existentes.

… para crear los planos de cada habitación he recurrido al block de notas de los que crean txt normales y corrientes para crear los gráficos ascii que usará el ejemplo:

*********
* Patio  *
******************************************
*                            #                              *
*                            |                               *
*                            |                               *
*                 $#—-@                              *
*                            |                               *
*                            |                               *
*                          $#                              *
******************************************

Luego los copio y pego en http://www.mushcode.com/Ascii2Mu  para prepararlo en su inclusión al Mud.

El programa nos devuelve:

*********%r* Patio *%r********************************%r*[space(13)][ansi(g,#)][space(16)]*%r*[space(13)]|[space(16)]*%r*[space(13)]|[space(16)]*%r*[space(7)][ansi(g,#)]—–[ansi(y,@)][space(16)]*%r*[space(13)]|[space(16)]*%r*[space(13)]|[space(16)]*%r*[space(13)][ansi(g,#)][space(16)]*%r********************************%b%b

Para incluir el “PLANO” a la habitación se crea un comando definido por el usuario para cuando se le llame, nos muestre el plano de cada habitación:

&cmd #4=$plano:@emit %R*********%r* Patio *%r********************************%r*[space(13)]#[space(16)]*%r*[space(13)]|[space(16)]*%r*[space(13)]|[space(16)]*%r*[space(7)]$#—-@[space(16)]*%r*[space(13)]|[space(16)]*%r*[space(13)]|[space(16)]*%r*[space(12)]$#[space(16)]*%r********************************%b%b

Con este ascii solo tenemos el PLANO de una habitación y sus Salidas, cada habitación tendrá sus propiedades al respecto y es tremendamente útil para ayudar a los jugadores cuando el Mud es muy grande, aunque puede que no ser necesario, dependera del juego que cree o la aventura que se desarrolle.

Ahora cada habitación tiene su plano … ¿y si queremos todo el mapa general visible desde cualquier habitación?, para estos casos se puede recurrir al $Comando Global.

$Comando Global

Es el comando definido por el usuario, que abarca a todo el proyecto o mejor dicho a todas las salas independientemente de donde se ejecute.

Si se desea crear este tipo de comandos debemos situar al Creador en la habitación (#2), use el @tel #2 para situarse mas rápidamente, esta sala es especial, no esta conectada a ninguna otra sala, su bandera es un Floating y no se aconseja dar permisos a ningún jugador para usar esta sala.

[Con el Creador haremos un objeto Portamapas para incluir el Comando Global]

>@cerate PortaMapas
>@set PortaMapas=!NO_COMMAND
>&cmG #<objeto>=$mapa: @pemit %#=<dibujo ascii mapa>
>drop PortaMapas

&cmG #7=$mapa:@pemit %#=***[space(5)]%r*** [ansi(g,Atlas General)]%r***%r[space(19)]\[#2MasterRoom\][space(6)]—–\[Bodega\]%r[space(39)]|[space(7)]|%r[space(10)]\[Limbo\]—–\[Almacen\]—–\[Patio\][space(4)]|[space(11)]leyenda%r[space(25)]|[space(13)]|[space(6)]\[ \][space(9)]#-Salidas%r[space(25)]|[space(13)]|[space(18)]@-Jugador%r[space(18)]\[Gran Salon\]—–\[Armeria\][space(14)]T-Tele.%r[space(25)]|[space(32)]!-Bloqueo %r[space(25)]|%r[space(24)]\[ \]%r——————————————————————————-%r**[space(76)]* %r** [ansi(g,Plano Especifico)][space(59)]*%r**[space(42)]P.almacen[space(25)]*%r*[space(44)]Llave[space(28)]*%r*[space(30)]Puerta[space(11)]|[space(29)]*%r*[space(17)]Porton[space(7)]Llave[space(12)]|%b%b—–\[Bodega\][space(14)]*%r*[space(19)]|[space(11)]|[space(15)]|%b%b|[space(9)]|[space(16)]*%r*[space(10)]\[Limbo\]———-\[Almacen\]———-\[Patio\][space(7)]|[space(16)]*%r*[space(12)]|[space(19)]|[space(17)]|[space(8)]\[ \][space(15)]*%r*[space(10)]@tel[space(18)]|[space(17)]|[space(26)]*%r*[space(5)]\(Libro/almacen\)[space(9)]\[Gran Salon\]—–\[Armeria\][space(22)]*%r*[space(32)]|[space(17)]|[space(26)]*%r*[space(31)]\[ \][space(13)]!Llave[space(24)]*%r*[space(46)]sur\,este[space(23)]*%r*[space(77)]*%r——————————————————————————-%R

__–__

Con este comando pongo fin a esta guía de Pennmush, con lo comentado se pueden crear MUD para jugar entre amigos, preparar retos para los peques de la casa y un sin fin de utilidades que se os puedan ocurrir, como en otras ocasiones el limite es nuestra imaginación.

Enlace.- Detrás del Mud https://app.box.com/s/ydpk81ir3i0ix3d1foqi2wzyo0g44tkc

Dice el refrán que no dejes para mañana…

Esta guía la debí acabar antes del verano y unas cosas por otras al final se dilata, no obstante casi 70 paginas de contenido llevan su tiempo, aunque la verdad también hay muchas imágenes.

Hablamos hace tiempo del problema de los servidores de imágenes y su caducidad para dotar de contenidos a los lugares donde hacemos uso de ellas, y como ejemplo de salvaguarda crear un  Pdf para que en todo momento este disponible, aunque las imágenes pudieran dejar de existir, no se hasta que punto esto puede ser entendido como un descuido del autor, pero ni mucho menos debería entenderse así, simplemente los servidores gratuitos “caducan” amen de que mantener chorrocientas y tantas imágenes requeriría un esfuerzo inhumano.

Al grano… esta guía puede servir de apoyo a jugadores tanto como a creadores de MUD y la idea es dar unas lineas generales de los comandos mas usados así como sencillas aplicaciones que desvelan su uso. Como para todo la curva de aprendizaje es inevitable, esta guía cubre un peqeño espectro de conocimiento del que lamentablemente apenas hay información en nuestro idioma, pudiendo servir de apoyo a quienes estén interesados en desarrollar con el aplicaciones, como a usuarios que deseen aumentar sus posibilidades de iteración.

Saludos

Anuncios



Archivos

Categorías

  • No hay categorías

Categorías

  • Categorías
    • No hay categorías

A %d blogueros les gusta esto: