Hola show:
Yo también llegué hasta el CAAD porque tenía (tengo) la necesidad de hacer un MUD. En su momento, en la lista de correo, pregunté si se podía hacer en Inform y Zak mismo me explicó lo que él había hecho, que era lo siguiente:
Zak en la lista de correo CAAD escribió:
Hola, Lenko,
Para que no te hagas falsas esperanzas, debería decirte que Inform no soporta multi-jugador. Sí que tiene soporte en cambio para el juego multi-personaje (en el que un solo jugador decide qué personaje manejar en un momento dado, al estilo Maniac Mansion), pero no es lo mismo.
El problema no viene del lenguaje Inform, que es lo bastante genérico como para permitir casi cualquier cosa, sino de las máquinas virtuales en que se ejecuta (máquina Z o Glulx), ya que ninguna de ellas tiene soporte de red. Y claro, un juego multijugador sin posibilidad de conectarse a él por la red es bastante inútil.
La experiencia que te relató Jenesis, y que tan buenos recuerdos dejó en ella, en relación a una versión Multijugador del juego "El Vampiro", no dejó de ser un experimento, por otra parte bastante difícil de reproducir. Te cuento. (Antes de nada, todas estas ideas no fueron mias, sino de Roger Firth. Yo me limité a adaptarlas al caso español).
La idea fue, "ya que la maquina Z no tiene soporte de red ¿no se podría hacer un programa intermedio que sí tenga soporte de red y que se ocupe de recibir de la red los comandos que los jugadores envían, pasárselos a un intérprete Z que esté ejecutando el juego, leer la respuesta que genera el intérprete Z y enviarlo de nuevo por la red a los jugadores" ?
Es decir, el esquema sería este:
Jugador -> Cliente_para_jugar -------RED----
Otro Jugador -> Cliente_para_jugar ---RED-----> Server <--> MaquinaZ
/ (Frotz)
Otro Jugador -> Cliente_para_jugar --RED----/
Asi que para lograr el objetivo del juego multijugador, para empezar
habría que crear un par de programas:
- Cliente (se ejecuta en las máquinas de los jugadores, lee comandos del teclado, los envía por la red al servidor, espera respuesta del servidor y la muestra en pantalla)
- Servidor (se ejecuta en la máquina en la que está corriendo realmente el juego. Lee comandos de la red, se los envía a Frotz, o al intérprete Z que se use, lee la respuesta de ese intérprete y la envía por la red a los jugadores)
Para no tener que trabajar más de la cuenta, a alguien se le ocurrió que el nexo de unión entre jugadores y maquina Z podría ser un MUD. Asi no habria que programar clientes para los jugadores (el cliente que ellos usaran para acceder al MUD sería este programa), y por otro lado el server sería un programa que se conectaría al MUD como si fuera otro jugador más. Este jugador "falso" (un bot en realidad) se llamaba ZX. Los jugadores, hablando con ZX, estaban enviando comandos a la máquina Z y la respuesta que ZX les daba era la respuesta de la máquina Z.
Con esto ya se lograba un objetivo: Poder jugar entre varias personas, cada uno en su casa y vía red, un mismo juego. Esto tenía interesantes implicaciones para el betatesting. Por ejemplo, el autor del juego y un betatester se conectaban al MUD y, a través de ZX, el betatester jugaba.
El autor podía ver lo que el betatester hacía y las respuestas que le daba el juego, como si estuviera "mirando por encima del hombro" del jugador.
Pero para lograr un juego multijugador no bastaba con eso. Un juego multijugador se lograría creando un juego multipersonaje, y haciendo que el parser cambiara automáticamente de un personaje a otro, según qué jugador fuera el que enviaba el comando. Además, el texto que produzca el juego (la respuesta al comando) debería ir marcado de alguna forma, indicando qué jugador puede ver esa respuesta. Por ejemplo, si los personajes Zak y Jenesis están en la misma localidad, y el personaje Zak recibe el comando "Ir norte", el juego debe generar dos respuestas, una que solo Zak debería ver y que dice "Vas al norte...." y otra que sólo Jenesis debería ver y que dice "Zak se marcha por el norte". Además puede haber texto que todos los jugadores deban leer, por ejemplo sucesos globales del estilo "Un campanario suena en la lejanía". La
solución adoptada fue marcar con tags al estilo html el texto que el juego genera. Así, en esta situación el juego sacaría el texto:
<zak>Vas al norte...</zak>
<jenesis>Zak se marcha por el norte</jenesis>
Un campanario suena en la lejanía.
El servidor intermedio lee esta respuesta producida por el intérprete Z, y analizando los tags, sabe a qué jugador debe enviar cada frase (en la implementación a través de ZX, lo que ocurría es que ZX enviaba mensajes "por privado" a los demás jugadores, con el texto que solo ellos pueden leer, y mensajes "globales" con el texto que todos pueden leer).
Todo esto implica modificaciones en la librería InformATE. Estas modificaciones se recogían en un módulo llamado "multi.h", o "multizx.h" o algo asi.
De todas formas, como ves, no deja de ser trampa sobre trampa. Una mera demostracion de que "si uno se pone, se puede hacer casi cualquier cosa", pero aun muy lejos de ser algo realmente operativo y simple.
Francamente, no te recomiendo Inform para este tipo de cosas. Aunque realmente no hay, de momento, otra alternativa... A ver si nuestro amigo Al-Kwarizmi termina ese parser en el que anda metido desde hace tanto tiempo, que promete.
Saludos,
|Zak|
Como ves, tal y como dice no deja de ser "trampa sobre trampa" así que yo también estoy esperando a que Al-* publique
AGE para poder hacerlo.
Por otra parte, códigos de MUD's hay un montón en C, Perl y otros lenguajes, pero tienen dos problemas graves para lo que necesito: están en inglés (habría que traducirlo todo incluyendo el parser) y suelen estar más pensados para la pelea que para la resolución de puzzles.
Identificarse
Registrarse
FAQ
Buscar
