¿Que fue del cliente de reinos de Leyenda?

El proyecto sigue adelante, y con buena pinta. sin embargo, existen dos «contras» actualmente:

• El inmortal encargado de su desarrollo anda con muy poco tiempo, menos del que le gustaría.
• Sólamente será soportado por Windows XP y Windows Vista en adelante. Digamos que se basa en unas de las últimas tecnologías que la multinacional ofrece. Por tanto, a corto plazo no podrá ser utilizados por sistemas Mac o Linux, pero a la vez le otorga una larga vida.

En segundo lugar, esperamos que su publicación se lleve a cabo junto con la nueva página web. Las fechas son desconocidas.

Por último indicar que sus primeras versiones no contendrán lo esperado de un cliente propio para un solo mud. Pese a que sólo se podrá utilizar para conectar a Reinos de Leyenda, a falta de un protocolo firme para comunicar el cliente con el mud, las características ofrecidas por la aplicación no superarán a las ofrecidas por cualquier cliente mediano, y por ello no podemos expresar de manera certera el termino «propio de RL».

Un saludo.

Como es Hallowen y es el día de ver caras nuevas, aquí os dejo la cara actual del cliente en desarrollo. Espero que os guste:

Me encanta ese interface, si ese cliente se puede hacer compatible con el mapa de zmud seria asombroso ^^ xD

Creo sinceramente que este proyecto puede ayudar mucho en un futuro a reinos de leyenda, asi que os mando todos los animos para que tireis esto adelante y podamos verlo algun dia finalizado.

podriais intentarlo en Mono asi no tendria problemas con varios SO.

Con el tiempo del que se dispone, no queremos meternos en temas que nos retrasen aun más, y por ahora seguiremos desarrollando utilizando todo el conjunto de recursos que nos ofrece .NET, sin restricción.

Dejando el lado técnico, la única cuestion que nos planteamos radica en cómo organizar la interfaz. Existen dos opciones:

• Interfaz sencilla: un cuadro de texto (donde iría el texto recibido por el mud) ocupando toda la ventana gráfica, una barra de insertar comandos abajo y la opcion de ver paneles para macros y puntos (MXP) en los extremos de la pantalla. Esta organización corresponde a la que podeis encontrar en el típico juego MMORPG, donde las «barras de acción» se anclan a los lados. La ventaja de esta disposición es que te ahorras las barritas de control y te aseguras una vision limpia.
• Interfaz compleja: supone identificar cada elemento del cliente como una «subventana», de manera que puedas moverla y redimensionarla a tu antojo dentro de la ventana gráfica. La ventaja es que puedes colocarte la interfaz a tu gusto, eliminando los elementos que «sobren» o añadiendo nuevos. La captura de pantalla anterior corresponde a este estilo de interfaz.

¿Qué opinais?

Ke muy chulo y muy bonito, pero lo ke creo ke se intentaba implementar era, sobre todo, ofrecer algo a los novatos propio de reinos de leyenda. Sin depender de la mierda de telnet. Sin depender de oye, mira bajate el zmud, el crack, y ya eres ilegal pero podras jugar al reinos… o de buscate la vida por ahi hay unos clientes en ingles gratuitos…
Un cliente gratuito, español, ke se instale y a jugar. Eso lo veo basico.
Despues, ke se le kieran añadir mejoras, virguerias y demas, de puta madre, pero el novato tiene ke llegar, instalar y jugar (con mapa a poder ser).

Muchas gracias por vuestro comentarios.

Quizá no haya necesidad Ilgrim, pero tener una aplicación MDI te permite añadir un montón de elementos interesantes. En la captura sólo se ven varias subventanas, pero existen muchas otras como un panel con el teclado numérico, un visualizador de imágenes o un simple nickeador. Sin embargo como dices, se corre el riesgo de hacer elementos inconexos. Si tienes alguna opinión más al respecto, por favor haznosla saber.

Hasta que no solventemos esa cuestión de interfaz no se avanzará en el cliente, así que esperamos vuestras opiniones: cliente con elementos fijos y bien definidos o cliente compuesto de subventanas movibles y redimensionables.

Un saludo.

Eso estaría genial Ilgrim. El cliente al fin y al cabo será para nosotros, así que cualquier opinión o colaboración será bien recibida.

Ahora mismo estamos probando una versión «compacta», con una interfaz parecida a la de un mmorpg. La verdad es que no está quedando mal, después de comer colgaré alguna captura de pantalla.

Un saludo.

Hombre, un aspecto móbil y configurable parece lo ideal, digo yo 🙂

Sencillito y potente, tiene muy buena pinta 🙂
Además, si no es fácil meter el mapa del zmud, siempre se pueden poner esos de situación como el que has colocado. A mi me parece buena idea.

Vaya, que rapidez 🙂

Quizá se me olvidó comentar algunos aspectos esenciales de la apliación. El más importante es que el MUD sólo puede comunicarse con el cliente a través del MXP actual, y ese protocolo no muestra información sobre tu equipo, entre otras muchas cosas. Actualmente los clientes sólo pueden saber los puntos de tu personaje actual e interactuar con algunos objetos de tu entorno, pero ni siquiera sabe con que personaje estás jugando ahora mismo, ni mucho menos su ficha.

Para aumentar la comunicación entre servidor-cliente hay que crear un protocolo nuevo o modificar el actual, pero eso puede llevar mucho tiempo. Por tanto, tenemos que ajustarnos a la situación actual.

Respecto a la interfaz, tiene muy buena pinta. En cuanto tenga un rato subo una captura.

Un saludo.

@Snaider wrote:

Vaya, que rapidez 🙂

Quizá se me olvidó comentar algunos aspectos esenciales de la apliación. El más importante es que el MUD sólo puede comunicarse con el cliente a través del MXP actual, y ese protocolo no muestra información sobre tu equipo, entre otras muchas cosas. Actualmente los clientes sólo pueden saber los puntos de tu personaje actual e interactuar con algunos objetos de tu entorno, pero ni siquiera sabe con que personaje estás jugando ahora mismo, ni mucho menos su ficha.

Para aumentar la comunicación entre servidor-cliente hay que crear un protocolo nuevo o modificar el actual, pero eso puede llevar mucho tiempo. Por tanto, tenemos que ajustarnos a la situación actual.

Respecto a la interfaz, tiene muy buena pinta. En cuanto tenga un rato subo una captura.

Un saludo.

Ok, modifico mi comentario porque Snai me ha contado su plan para crear un protocolo mucho más potente que dejará el parsing que yo he propuesto a la altura del betún 🙂
La idea es taggear las acciones para que el cliente las reconozca. Y así poder hacer cosas chulas 🙂

¡BINGO!

Has dado con el secreto Ilgrim. La solución para crear un cliente propio para un MUD es justamente lo que has comentado. En estos momentos no disponemos de tiempo para hacerlo, pero en mente tenemos crear un protocolo como el MXP, propio y eficaz. Además, deberá ser comunicación recíproca, pues el cliente muchas veces necesite algun tipo de información extra. Pero bueno, este tema está casi todo hablado.

Gracias por todo tu interes Ilgrim, te mantendremos informado 🙂

Un saludo.

Bueno, es anecdótico, pero creo que deberíamos centrar esa extensión del protocolo en otras cosas, pq la verdad, no creo que aporte nada el ver el inventario en el propio cliente. Actualmente el MXP ya te permite manipular con clicks el inventario, sin escribir nada, y ya existen muchos comandos para ver el equipo que tienes.

Veo más importante avanzar en funcionalidades de apoyo del cliente a la experiencia de juego, tales como gestión y registro de canales, mejoras en el mapeador, gestión de contactos (personajes conocidos que permitan crear una especie de red social al estilo facebook), emoticonos, no se, historias que sólo se puedan hacer a nivel cliente, y no servidor.

Eso que comenta Rutseg es fundamental. RL siempre se ha caracterizado por su «modo texto», y no podemos intentar convertirlo en algo más interactivo y visual, pues se perdería la ensencia del juego. Sin bien es cierto que el MXP nos ayuda durante el juego, no deberíamos centrar nuestra atención en añadir funcionalidades de ese tipo.

Hay dos ideas básicas: (a) separar la información recibida según las preferencias del usuario y (b) facilitar la creación de un mapeador. En lo referido a separar información se entiende, por ejemplo, por separar en subventanas los distintos canales. Así, un novato podría entrar al juego con una subventana exclusiva para el canal novato. Respecto al mapeador, muchos de vosotros habreis intentado mapear Eirea con distintas aplicaciones como el mapeador de ZMud. Las dificultades son principalmente que el cliente no sabe a ciencia cierta en que room te encuentras. Imaginemos que existe una avenida del tipo Avenida [o,e] con varias salas de longitud. Si el cliente recibe Avenida [o,e] debe ingeniarselas para reconocer en cual de ellas estás. Pues bien, todo eso se solucionaría enviando desde el servidor un identificador único para cada sala, de manera que el mapeador sepa con exactitud en qué habitación de encuentres, independientemente del origen o modo de llegada.

Eso es todo, un saludo 🙂

He seguido el post y hablando aier con Snaider me invito a que participase si tenia tiempo y como tiempo en esta vida nunca se tiene pues me decidi a leerlo.

Tengo las siguientes ideas, creo que sería capaz de realizar una interfaz como la de snaider que me parece la mejor (que me perdonen los demas) ya que es lo básico, pantalla de recepcion del mud en si, unos macros y poco mas.

A esto añadiría lo que otros dijeron por ahi de un sistema completo de ventanas estilo msn tanto para tells como para canales con sus correspondientes avisadores en caso de ser tells.

Si el mud tiene un sistema de mapeo basado en numeros unequivocos de room pues creo que crear un sistema propio de mapa sería bastante genial y no muy dificil. Todo esto estoy pensandolo con ideas innovadoras como que el mapa disponga de una (fog of war) estilo juegos de estrategia y juegos moorpg, entonces el pj naceria en una room y tendria el mundo sin descubrir asi como lo va descubriendo ampliaria su mapa, creo que sería genial. De esta forma el pj no tendría que generar el mapa sino que el servidor se lo iria sirviendo poco a poco.

Lo he estado pensando y al finalizar los examenes de febrero tendría tiempo para ponerme con el tema y en cosa de 1 mes a lo sumo debería tenerlo funcionando pero si lo voy a hacer necesitará hacer algun cambio en el servidor o hacer alguna funcion extra en la mudlib aunque poca cosa.

Un saludo y espero comentarios.

PD: se me olvidaba decir que de esta forma se explotaría el mxp creo q al máximo ya que el cliente se podría servir de sus enlaces continuamente.

Otra cosa que se me acaba de ocurrir es por ejemplo que cuando llegas a una ciudad se te abriria una ventana con la imagen de la ciudad y abajo te pondría que tiendas o establecimientos tiene, entonces tu podrías pinchas en una y te llevaría auto a ella, creo que para novatos y no tan novatos sería genial.

Esto haría que el mud ganara en elementos gráficos y no ser tan mátrix continuamente.

Otras cosas que podría tener es mediante los menus que tuviese poder abrir una ventana de inventario donde tendrías tu personaje con su equipo puesto y su mochila abajo donde se podrían arrastrar objetos de la mochila al pj para equiparlos o desequiparlos al puro estilo Diablo 2 o como en infinidad de juegos.

Creo que la clave del desarrollo del cliente tendría que ser que los nuevos jugadores entren al mud de una forma mas progresiva y facil pero sin olvidar a los viejos jugadores que con estas mejoras seguramente cambiarían su viejo Zmud por el nuevo cliente.

Hola Raiman, gracias por unirte al tema. Me alegra que te hayas animado con el desarrollo del cliente, sin embargo me temo que me toca ponerte un poco los pies en la tierra. Está muy bien proponer ideas, pero deben ser fundamentadas en algo consistente y no en un pensamiento esporádico. Piensa que ideas buenas tenemos todos, y si fuese tan sencillo como pensar en una interfaz la cosa no estaría como está. La imaginación del ser humano es infinita, pero en el desarrollo de software las buenas ideas no solo tienen en cuenta lo bien que podría quedar, sino los riesgos que conlleva implementarlo, el tiempo del que se dispone para ello y las restricciones que supone.

En primer lugar el servidor (MUD) y la mudlib no se va modificar a menos que prepares un estudio detallado donde se explique hasta la última linea de código que hay que modificar, por qué hay que modificarla y qué consencuencias traerá en el futuro. Esto engloba a «crear un sistema de mapeado unequivoco», crear un «sitema de ventanas msn» o hacer que el servidor «sirva mapa poco a poco», lo cual por cierto, me parece de las cosas más complejas que he oido en mucho tiempo.

Te recomiendo personalmente que comiences haciendo el análisis de un cliente capaz de conectar de manera estable y segura al MUD. Necesitarás concretar en qué plataforma vas a desarrollarlo, elegir el lenguaje de programación y entonces descubrir tus ventajas y limitaciones. Una vez hayas estudiado los requisitos, tendrás que ver si es viable esa opción y comenzar la etapa de diseño. Una vez hecho, implementarlo será sencillo y no te llevará mucho tiempo. Si tienes alguna duda puedes comentarla por el foro.

Cuando hayas conseguido un cliente estable y con una interfaz amigable tendrás que pensar entonces en añadirle módulos que mejoren la experiencia del jugador. Para empezar podrías comenzar con el MXP, un protocolo estandarizado por Zugg Software compatible ya por casi todos los clientes y que el MUD soporta desde hace años. Además existen otros protocolos básicos como el MSP o el MCCP, los cuales son fundamentales. Cuando todo eso sea estable entonces estarás preparado para crear tus propios módulos que interactuen o no con el MUD por medio de un protocolo exclusivo para RL.

Espero que te vayan muy bien los examenes, y si consigues algo de tiempo espero verte por este tema 🙂

Un saludo.

Bien, comprendo que tranqilices el enfasis inicial, pero todo lo que acabo de exponer tengo en mente como implementar todo.

Las cosas que he propuesto quiza en conjunto pueden parecer muy complejas cada una de ellas pero no son mas que tratar unos problemas mas pequeños que en conjunto darían ese resultado.

Otra cosa, la plataforma seria .NET ya que nos ofrece infinidad de posibilidades y al ser multiplataforma mi cliente se podría ejecutar tanto en windows linux como otros sistemas operativos futuros.

Creo que el tema debe ser estudiado y no me importaría un dia reunirme contigo en el mud y hablar sobre las dudas q te asaltan y cosas asi, pero sobre lo de ponerse a programar asi a lo loco no creo que sea lo mejor, ni que la gente se este haciendo mil clientes que al fin y al cabo no valdran.

Creo que lo mejor sería asignar el proyecto a alguien y que lo haga completamente aunque en mi caso sería necesario tener un inmo o varios al que poder preguntarles cosas en cualquier momento sobre detalles para implementar las cosas y cuadren lógicamente.

Un saludo.

PD: he de decir que tengo suficiente experiencia como para desarrollar una interfaz básica que se conecte al mud simplemente por ver si me sale, xq se que me va salir jeje.

PD2: incluso se podría añadirle las funcionalidades que ofrece la codificacion UTF8

@raiman wrote:

Bien, comprendo que tranqilices el enfasis inicial, pero todo lo que acabo de exponer tengo en mente como implementar todo.

Las cosas que he propuesto quiza en conjunto pueden parecer muy complejas cada una de ellas pero no son mas que tratar unos problemas mas pequeños que en conjunto darían ese resultado.

Otra cosa, la plataforma seria .NET ya que nos ofrece infinidad de posibilidades y al ser multiplataforma mi cliente se podría ejecutar tanto en windows linux como otros sistemas operativos futuros.

Creo que el tema debe ser estudiado y no me importaría un dia reunirme contigo en el mud y hablar sobre las dudas q te asaltan y cosas asi, pero sobre lo de ponerse a programar asi a lo loco no creo que sea lo mejor, ni que la gente se este haciendo mil clientes que al fin y al cabo no valdran.

Creo que lo mejor sería asignar el proyecto a alguien y que lo haga completamente aunque en mi caso sería necesario tener un inmo o varios al que poder preguntarles cosas en cualquier momento sobre detalles para implementar las cosas y cuadren lógicamente.

Un saludo.

PD: he de decir que tengo suficiente experiencia como para desarrollar una interfaz básica que se conecte al mud simplemente por ver si me sale, xq se que me va salir jeje.

PD2: incluso se podría añadirle las funcionalidades que ofrece la codificacion UTF8

No es por desanimarte, pero la única manera de hacer las cosas que dices es parseando. Nosotros lo que queremos hacer es desarollar un protocolo de comunicación integrado en la mudlib que se comunique con el cliente.
Si se parsea, hay muchos problemas, especificados al principio, y eso lo queremos evitar. Modificar la mudlib para integrar un protocolo sólo se hará cuando estemos seguros que da seguridad, es robusto y abre posibilidades también para el futuro.

El tema del cliente es algo prioritario, pero hay que hacerlo bien. De todas formas, hay que agradecer tu disposición, y en caso que tengamos claro como hacer el protocolo, no estamos cerrados a que haya gente que nos quiera ayudar, claro.

Yo en el tema de desarrollar un protocolo ya no me meto porque ademas creo que sería cosas de inmos gordos ya que habría que meter mucha mano en la mudlib.

Simplemente estaba comentando como se podría hacer algo para YA de una forma que no afectaría a la seguridad y fuese totalmente funcional para realizar mejoras en el mud, podría decirse que se trataría de una aproximacion a lo que realmente se quiere crear como producto final. Consideradlo como un cliente 1.0.

Como bien dijo Rutseg un diseño de un nuevo protocolo no es una cosa que deba tomarse a la ligera ya que es muy complicado y alguien dijo que no había tiempo para eso pues por eso me ofreci a hacerlo a mi modo.

Lo que teneis que decidir es si finalmente se va a implementar el protocolo o si quereis un cliente que este listo en poco tiempo.

Un saludo.

Me parece espectacular que tengáis esas ideas, felicidades, me parece interesantísimo.

Yo apoyo todo, pero me parece que si se pudiera hacer algo con el mapa para que al usar monturas el mapa no se inutilice sería genial, quizá con un protocolo tipo el MXP mejorado como hablábais donde se mande la ruta de la room (sin tener otras historias) y que el cliente lo reconozca para situar la posición. Esto también ayudaría a los arpeos y otro tipo de inconvenientes como cuando no te mueves correctamente en pantanos o con retener con el mapa que ahora mismo usamos casi todos (todos solucionables con programación del mapa por cada usuario, pero claro, es complicado para newbies.

El mapa se lo haría cada jugador, aunque si alguien te lo «pasa» pues tienes un mapa más extenso, pero sería lo suyo que se autogenere (digamos que gracias a la ayuda de la información que le sirve el protocolo que se use, el cliente «sabe» si está en una nueva habitación y la ponga en la ventana del mapa con el short, las salidas y el long.

Que el mismo mapa pueda reconocer cierto tipo de rooms como tiendas o posadas y les aplique una leyenda con un color diferente para cada tipo de room especial o un icono (si fuera factible). Esto ayudaría a los jugadores novatos para hacer su propio mapa con las zonas que ha visitado, haciendo prácticamente lo que se decía del «fog of war», siendo esto una experiencia tanto para jugadores novatos como para los que migremos al nuevo cliente.

Otra de las cosas que me parecería interesante, sin perder la función que tenemos ahora con el inform sobre entradas y salidas de jugadores (orbitar), sería implementar una ventana que yo tengo a base de triggers en el Zmud. Tengo una ventana de who que me tiñe (solo en esa ventana, cuando me los encuentro en la misma room son del color que tiene la raza) los jugadores que entran por ciudadanías y elimina los que salen. Eso me ayuda a hacer mi nick x de forma manual. Sería curioso que se pusiera algo que los pusiera con los colores raciales y ke tuviera una leyenda para aliados/enemigos (un simple asterisco al principio o al final del nombre que te indicara la diplomacia).

Otra cosa que ya no sé si os parecerá bien o mal, pero una base de datos para almacenar (de forma local y no automatizada) información de misiones/quests/npc’s, o rooms con alarmas para zonas peligrosas para newbies…
Algo que no te obligue a tener que tener cientos de papelotes y archivos con información por todas partes, que te lo gestione el mapeador de forma automática.

Bueno, son sólo ideas, ya sé vuestra política al respecto, pero si son útiles para ayudar a hacer una cosa bien útil y que facilite el juego sobre todo a jugadores novatos, pues los veteranos ya tenemos prácticamente finiquitada nuestra configuración personalizada de Zmud, pero si el nuevo cliente está bien, me migraré sin problemas 🙂

Se me hace la boca agua al ver vuestras propuestas  😮

Ojalá consiguieseis la mitada de las cosas que decís sería mucho mas facil empezar. Y los demás no se pero yo os lo agradecería muchisimo ^^

Como veo que lo del mapa es un tema fundamental tanto para newbies como para veteranos como ignie dice, pues debería ser totalmente a prueba de fallos a los que tu te refieres ignie (sino no valdría para nada). Si estamos hablando de crear un cliente específico para el mud no podría no contemplar movimientos de montura o escaladas con arpeos o movimientos erroneos estando retenido, todo eso estaría controlado.

Un cliente propio para el mud, sería tan util como ingenioso sea el que lo diseñe, puedes hacer lo que quieras, ya que el mud es un mundo realmente completo y se pueden añadir muchas cosas. Puede ser realmente impresionante la ganancia en riqueza de ambientacion por ejemplo, imaginaos que el mapa no fueran simplemente cuadraditos, que se metiesen imagenes de fondo para simular un bosque en thorin por ejemplo o lo que ya comente antes, al puro estilo Heroes of Might & Magic, cuando llegamos a una ciudad que se abriese una ventanita con el dibujo de la ciudad y «accesos directos» a las tiendas y otros establecimientos, por supuesto todo sería configurable, quien quiera que no le salga la ventana pues no le saldría.

Yo optaría por un cliente base y luego ir subiendo a la web updates con mejoras y funcionalidades que se vayan implementando.

Sobre cosas como hacer que el servidor te sirva el mapa poco a poco, hay mil formas de hacerlo y sin tocar la mudlib todas ellas. La forma mas optima tanto para el servidor como para el trafico del mud sería dejar en el directorio donde se ejecuta el cliente un archivo cifrado a modo de «cookie» diciendo, he explorado esta parte del mapa, dame solo este cacho, etc.

El sistema de informar al mud de la room en la que te encuentras fue una de las ventajas que se vio a MXP en sus comienzos, pero se quedo a medio hacer. Como curiosidad podeis activar el debug del MXP (al menos zmud y cmud lo tienen, otra opcion es activar el MXP en un cliente que no lo acepte), lo cual os permite ver el codigo MXP que envia el server. Si haceis un long de la room vereis que el nombre de la misma se envia entre dos etiquetas (ahora no recuerdo el nombe), que tenian como proposito facilitar al mapper el reconocimiento de zonas.

Lo de la configuracion del mapper actual… cierto es que es compleja, tal vez podriamos dejar subida una configuracion bien hecha para que fuera mas facil a los newbies mapear.

En cuanto a las ids unicas, es un tema peliagudo con el sistema actual. Lo que estamos intentando es poder traducir las rutas a ids unicos, porque por temas de seguridad no se enviaran las rutas de los ficheros (imaginaros uno que en la ruta tenga informacion «interesante» como «room_con_pared_secreta»). Es un trabajo algo peliagudo pero factible que habra que hacer en algun momento porque da muchas utilidades.

Saludos Golthiryus, solo queria comentar un par de pinceladas que creo que podrian ayudar.

Tu comentas que puedes informar al mud donde te encuentras, pero si lo pensamos bien, el mud tiene una especie de mapeado interno creado con el actual mapa del mud por medio de links en cada una de las salidas de las rooms, entonces podríamos ir diciendole al mud, dame las salidas de esta room, por supuesto, no aparecerían salidas que el pj no hubiese descubierto ya, no se si me explico, es decir, no sería peligroso eso que dices xq no daría esa salida, en el momento en que ejecutara la accion en que se descubre la salida si se le podría servir (aunque quiza eso obligaría a actualizar todas las rooms secretas del mud).

No se actualmente las rooms que puede haber de este tipo pero si incluso si eso fuese costoso, se podría hacer de otra forma facilmente, simplemente usando un algoritmo de encriptado de los nombres, tan solo sería crear la funcion en la mudlib para que sirva las rutas encriptadas y en el cliente otra funcion para desencriptarla.

En estos temas ya digo, tenemos total libertad de hacer cosas, sin tener que tocar demasiado porque al implementar el cliente de 0 se puede adaptar a la forma de funcionar el mud perfectamente.

Un saludo

@raiman wrote:

por supuesto, no aparecerían salidas que el pj no hubiese descubierto ya, no se si me explico

Como idea es muy bonita, ahora piensa como llevarla a la practica. Solo en el mapa que recientemente colgamos hay mas de 30k rooms, cada una con varias salidas. Crees que es abordable que el mud guarde por cada pj las salidas que conoce y encima tenerlas en memoria? Aun comprimiendo varias en un unico int es una cantidad de informacion no asumible, sin contar con el coste de buscar en esas 60-100k salidas a ver si el pj la conoce o no, un calculo que deberia hacerse con cierta frecuencia.

Realmente es mucho mas sencillo codificar una ruta y enviarla al cliente que coger y enviarle las salidas que «conoce».

No, no, me entendiste mal, me referia con eso a que no deberían mostrarse las salidas que el jugador no hubiese descubierto aun.

Entonces es cuando tu dices y como se podria hacer eso, pues facil, se mantiene en cada cliente un archivo cifrado (para que no pueda ser modificado por los pjs) totalmente generado por el cliente dinamicamente entonces cuando el pj se mueve si ha descubierto ya la room pues no pasa nada, si la room aun no ha sido descubierta (si no esta en la relacion de rooms descubiertas) se pode la room al server con sus salidas, algo similar a los que usan los navegadores y los servidores HTTP con el if-modified-since.

De esta forma se deriva MUCHA carga a los clientes y pcs que, estaremos todos deacuerdo, jugando al mud de desaprovecha totalmente la cpu, estas cosas no deberían notarse en el tiempo de respuesta al moverse ni nada por el estilo, cualquier cpu media puede hacer los debidos calculos en tiempos de menos de milisegundos.

Un saludo

De esa manera que dices es mas abordable, aunque hay innumerables pegas como que pasa cuando se modifica el mapa, cuando el pj juega desde otro pc o el tamaño en disco del cliente, pues si no se comprime sera un mapa similar al de zmud multiplicado por el numero de players.

Aun asi es tonteria meternos ahora en una discusion infinita sobre un futurible mapa. Tu propones que el cliente vaya descubriendo el mapa y nosotros, por ser mas sencillo, que el cliente tenga un mapa de todas las zonas no secretas (como el que colgamos) y se coloque automaticamente en el. Sea como sea, lo primero es obtener un id unico de cada room. Cuando este hecho eso, podremos discutir sobre otros asuntos.

Aun asi pocos inmos tienen tiempo y conocimientos suficientes para ponerse a trabajar en el tema de la obtencion de la id de manera eficaz, asi que tendremos que dejar las ideas en este sentido aparcadas durante un tiempo

con el tema de las ids tb podría ayudaros, pero hay un par de detalles que no conozco, por ejemplo: todas las rooms tienen una ruta distinta? supongo que si, si es asi, es tan facil como hacer una funcion que convierta un «string» que sería la ruta en un número.

Un saludo

@Golthiryus wrote:

En cuanto a las ids unicas, es un tema peliagudo con el sistema actual. Lo que estamos intentando es poder traducir las rutas a ids unicos, porque por temas de seguridad no se enviaran las rutas de los ficheros (…). Es un trabajo algo peliagudo pero factible que habra que hacer en algun momento porque da muchas utilidades.

Por lo tanto volvemos a donde decia yo. Necesitas que el mud genere ids unicas y eso es algo que ya tenemos pensado hacer, aunque no es una prioridad y es un trabajo delicado, pues, como decia, hay que encriptarlo bien a la vez que el calculo tiene que ser eficiente. Y eso implica que deben hacerlo los inmortales de mas rango, hablandolo tranquilamente y sin prisas.

Por ello, si quieres colaborar haciendo un cliente, adelante. Puedes partir de que las rooms envian una id unica al cliente para que este haga lo que quiera con ella. Pero ten en cuenta que eso no se implementara de un dia para otro. Aun asi, si vemos que funciona, tal vez podriamos darnos mas prisa en ello.

Hombre, como comprenderas si propongo hacerlo ahora despues de los examenes es xq tengo tiempo pero no querría dejar el tema que se alargase mucho tiempo, mas que nada xq si me pongo a implementarlo «de un tiron» creo un conocimiento del tema que me permitiria solucionar muchos bugs y desarrollar cosas, pero si se alarga y voy a tener que estar haciendo y parando seguido y relellendome todo el codigo de nuevo pues..

Si realmente la plantilla de inmortales está interesada en que me meta en esto deberíamos reunirnos y hablar las cosas bien y entonces ya estaría todo claro, como comprendereis y como ya dije no voy a programar nada sin estar las cosas claras y es que en caso de hacerlo tendría que contar con el apoyo de algun inmortal para que me supervisase y que tuviera algo de «mano» para hacer alguna que otra prueba sin que se escandalice la gente.

Saludos

Hola Raiman. El problema es que nos gustaría desarrollar un cliente capaz de interactuar de manera segura con el servidor, para lo cual utilizaría un protocolo un tanto complejo llamado MCP. Queremos apoyar su utilización, pero para ello habrá que estudiarlo y evaluar los costes y riesgos de su implementación. Queremos conseguir el mejor cliente posible, y apoyaremos al proyecto que nos ofrezca mayores espectativas.

En estos momentos hay un proyecto parado pero con muy buena pinta, desarrollandose por parte de algunos creadores. Por tanto, te animo a que crees tu propio cliente, lo publiques y veamos su repercusión. Para cuando hayas implementado de manera estable todos los protocolos actuales requeridos para que un cliente sea «mínimo» entonces -insisto- estaremos preparados para hablar sobre crear conjuntamente una aplicación apoyada por la asociación, intentando desde ese punto desarrollar el protocolo de comunicación.

Un saludo 🙂

Comprendo lo que dices, pero quiero tb vosotros comprendais que el funcionamiento del mud en bastantes cosas es algo complejo para quien no esta acostumbrado a tratar normalmente con su codigo por eso, insisto tb en que crear un cliente aunque sea básico sin un tutor o alguien a quien preguntar cosas sobre como funcionan, se hace casi imposible para alguien ajeno al circulo de los inmortales.

Entonces llegado este punto y si como dices hay un proyecto en marcha sobre el tema pues mejor me aparto y dejo a los que ya lo estan llevando.

Un saludo.

No tienes que desanimarte, cualquier iniciativa siempre es buena para toda la comunidad  😉

Yo mismo me ofrezco a resolver todas las dudas que se te planteen, puedes escribírmelas por medio de este tema del foro -y así se enterará el resto- o bien por mensajes privados.

Si quieres comenzar con el desarrollo en primer lugar debes olvidarte del funcionamiento del MUD, pues tu único objetivo por ahora es crear una aplicación que conecte via telnet a nuestra dirección 91.121.115.162 y sea capaz de recibir texto y enviar lo que el usuario quiera. Cuando hayas escogido el lenguaje, no creo que tardes más de media hora en encontrar un manual o el código necesario para desarrollar lo que te he dicho, no vas a tener que reinventar la rueda. Cuando conectes por primera vez verás todo monocolor -es decir, sin colores- y que entre las palabras habrá símbolos extraños del tipo ~]32m

Esos símbolos son los llamados ANSI codes, ¡Y descubriremos su función en el próximo capitulo de: Como hacer un cliente para RL!

Un saludo  ;D

yo solo hablo para poner una puntilla, y que resolveria mucho la vida de quienes no usamos windoze, ya que vais a hacer un cliente, este podria estar hecho en un lenguaje multiplataforma para que usuarios de macos, unix-like..etc puedan tener un cliente decente y dejar de tirar de virtualizacion ni emulacion ni cosas de esas 🙂

y hablando de reinventar la rueda (DRY) existen multitud de proyectos libres de clientes de mud, por lo que el grueso de conexcion, parseado MCP etc… esta mas que implementado…

yo votaría por java

🙂

.net es un modulo de java, que como ya dije antes es multiplataforma

no se donde has leido eso, pero .NET NO es un modulo de java, i no, tpoko es multiplataforma :P, aunque tiene alguna implementacion libre como mono (http://www.mono-project.com/) es bastante limitado

Package java.net

http://java.sun.com/j2se/1.4.2/docs/api/java/net/package-summary.html

Y si, java es multiplataforma xD

Quizás debiste ser algo más claro a la hora de hablar de .net, porque no se suelen hablar de paquetes de un lenguaje como soluciones a la implantación de un proyecto, sino de los propios lenguajes.

De hecho no tenemos modelo conceptual siquiera y ya están hablando de que paquete van a usar, un tanto apresurado.
El proyecto está en standby hasta que Snaider diga lo contrario y, aunque las colaboraciones son bienvenidas, discutir sobre implementaciones cuando nisiquiera nosotros sabemos cuando, como y que queremos, me parece un poco prematuro.

Y por cierto, como bien me apuntan por el cre un detalle que comentaste:

Otra cosa, la plataforma seria .NET ya que nos ofrece infinidad de posibilidades y al ser multiplataforma mi cliente se podría ejecutar tanto en windows linux como otros sistemas operativos futuros.

Si hablas de .NET (en mayúsculas) estás hablando de la plataforma micro$oft.

a vale como a dicho Satyr pense que hablabas de .NET y no de java.net :P, suerte 🙂

Si es cierto, por eso lo puntualice diciendo que era el modulo de java, y no digo que sea lo que vayais a usar vosotros, digo que si yo lo hiciese lo haría asi por la naturaleza de java de ser multiplataforma, nada mas, pero ahora que lo pienso el mono tb es multiplataforma creo.

Como ya te dije, si quieres crear un cliente la ayuda es bienvenida. Nosotros te podemos ayudar con dudas, pero no podemos ni hablarte de la mudlib ni darte acceso en ningún caso. Para eso hace falta ser inmortal.
Pero para lo que tú quieres hacer no te hace falta para nada conocer el mud. Tú interactuaras con la información que manda el mud al cliente y ya está. Snaider te puede dar algunos consejos, pero vamos, no tiene nada que ver con código de mud.

Sobre un tutor o ayuda, pues como te digo, creo que podemos brindarte la ayuda típica de dudas que puedas tener y que ya hayan sido solucionadas. El tema del protocolo es algo que llevaremos a cabo cuando tengamos tiempo, y se creará un cliente adecuado para ello, que será el cliente oficial del mud. Mientras, si tu quieres crear tu cliente no hay inconveniente y te brindaremos la ayuda que podamos darte, pero eso no incluye en ningún caso tutorizarte como si fueras un aprendiz, ni darte acceso a las tripas del mud, porque como te he dicho, es algo que no hace falta para un proyecto como éste.

En cualquier caso, es de agradecer el interés por ayudar a la comunidad 🙂

Bueno, al menos me he ofrecido, pero todos coincidiremos en que crear el cliente es un currazo y sin pequeños cambios en el servidor no se podría explotar ninguna de las cosas que propuse y si luego ademas va a ser sustituido pues me parece una tontería ponerse con ello, mas que nada porque no aportaría nada, quiza una interfaz «mas bonita» pero sería un zmud capado y seguramente ni siquiera se acercaría a lo que una buena config de zmud puede ofrecer.

De todas formas, si cuando creeis el cliente haceis un brainstorm y me quereis invitar, iria gustoso para aportar lo que buenamente pueda.

Un saludo.

Lo que dices es cierto y no… a que me refiero, con zmud, se puede hacer de todo, y cuando me refiero a de todo es todo, lagestion de canales de la que hablaba rutseg, se crea facilmente con un par de trigers, y mandando eso a ventanas separadas en zmud, lo de las monturas y el seguimiento del mapa, yo lo tengo hecho y funciona bastante bien con zmud, pero ami lo que me gustaba de la idea, es poder crear un cliente multiplataforma, si llegaras a tener uno como el zmud, pero multiplataforma se saldria de la taba :). Pero eso SI que tiene muchisimo curro.

Lo dicho suerte mucha suerte y paciencia, tb podrias crear el project en sourceforge/github/googlecode…. y que algun chalao se apunte a desarrollar contigo

Lo primero es hacer un cliente multiplataforma sencillo para nuevos jugadores. Con que conecte y pueda configurar macros es mas que suficiente. Luego poco a poco se pueden ir añadiendo mas cosas y listo. Primero metes compatibilidad con el mapa de zmud, aliases, trigges, etc.
Lo que inabordable es querer hacer desde cero un cliente similar a zmud (mas aun si luego sumas el MCP o MXP), porque es algo que ni ellos han hecho asi.

Viendo que alguno no me ha entendido, me extiendo mas:
Si quereis hacer un cliente (como cualquier otro proyecto medianamente serio), no debeis partir de la idea de hacerlo perfecto desde el primer momento, porque sera algo que os llevara numerosas horas de diseño, programacion y testeo. Por eso es mejor empezar por algo mas simple y abordable (por ejemplo, hacer un cliente que se conecte) y luego ir añadiendo cosas (meter macros, meter mapa, meter triggers…). Imaginad lo mal que iria el mud si intentasemos hacerlo todo a la vez en vez de ir poco a poco.
Citando a zmud queria daros a entender que zugg no hizo el zmud que conocemos de la noche a la mañana. Viendo el historial de versiones, hasta la version 2 no tenian version «estable» y no tenian cosas como las ventanas multiples. Teniendo en cuenta que este es un proyecto con fines de lucro, se entiende que alguien que voluntariamente hace un cliente empiece por cosas aun mas sencillas para ir poco a poco mejorando.

En fin, el objetivo de todo esto era que no desistierais en hacer un cliente si de verdad queriais colaborar, pero que no os pusierais la meta muy alta porque no paradojicamente eso haria que avanzaceis mas lento, sin contar con que nosotros, que ya hemos los efectos de demasiada ambicion en nuestras propias carnes, veriamos con mejores ojos un proyecto de cliente que avanza despacio pero constate que uno que se ponga metas muy altas y tardemos en ver los resultados.

yo en mi opinion veo buenas ideas,y veo mucha burocracia, en vez de agilizar y decir,mira  haz esto y yo te ayudo, es mejor decir mira hazlo y ya veremos q hacemos… pues no eh. Si kereis hacer una cosa de esa magnitud hay q implikarse,sino no pidais ideas ni gente q kiera ayudar si luego le dejais todo el marron a el, y ni sikiera una minima ayuda indispensable. solo es mi opinion,pq veo q algunos tienen buenas ideas y nada.

@unne wrote:

yo en mi opinion veo buenas ideas,y veo mucha burocracia, en vez de agilizar y decir,mira  haz esto y yo te ayudo, es mejor decir mira hazlo y ya veremos q hacemos… pues no eh. Si kereis hacer una cosa de esa magnitud hay q implikarse,sino no pidais ideas ni gente q kiera ayudar si luego le dejais todo el marron a el, y ni sikiera una minima ayuda indispensable. solo es mi opinion,pq veo q algunos tienen buenas ideas y nada.

Me alegra saber que no soy el unico que ve eso, ya me empezaba a preocupar jeje.

Respondiendo a Golthiryus, pues yo discrepo, evidentemente no vas a ponerte a implementar MXP antes de hacer que se conecte al mud, eso es evidente, pero creo que si no te pones metas altas el proyecto sale mediocre. En mi opinion querer que el cliente haga muchas cosas es bueno, no quiere decir esto que se va a programarlo a piñon jeje, creo que cualquiera que tenga una minima idea de programar hara lo que tu dices, empezar por lo basico e ir complicandose, de otra forma es imposible.

EDITO: veo que hablais de hacer algo como el zmud pero multiplataforma, yo no se si os dais cuenta de lo que es el zmud, pero sería complicadísimo hacer algo tan solo parecido al zmud, el zmud lleva un lenguaje de programacion interno y mucho mucho mas, como bien ha dicho Golthi, los de Zuggsoft llevan muchos años para desarrollar el Cmud asique seamos realistas y practicos.

Burocracia? ralentaizar? evidentemente hablais desde un pozo de desconocimiento.

Ya tenemos un proyecto de cliente y, por el momento, esta detenido por causas que no procede explicar aquí.
Como comprendereis, el desarrollo lo llevamos nosotros, más que nada porque así todos nos involucramos un poco.
Lo que no podeis pretender es que olvidemos las causas de las que hablabamos antes para hacer una reunión de los inmortales para llegar a conclusiones sobre cosas que no sabemos ni si queremos implementar. Sería dar palos de ciego y, para eso, retomaríamos el proyecto.

Esto no os priva de hacer algún tipo de colaboración, de hecho, para ello no necesitais nada por nuestra parte, ya que, como dice golthiryus, en estas cosas se empieza por hacer algo que sabemos que queremos y si después interesa, se ve de hacer reuniones, no al revés, no sirve de nada remover cielo y tierra si no hay a donde agarrarse. Podemos discutir todo el dia sobre innecesarios protocolos de encriptación de cliente-servidor para enmascarar salidas ocultas o se puede presentar algo y ver que hacer.

Bajo tu punto de vista puede que sea «burocracia excesiva», bajo nuestro punto de vista, que con todo el respeto estamos ya bastante escaldados en lo que a «proyectos demasiado ambiciosos y sus consecuencias en el tiempo de desarrollo», se trata de ser prácticos y de deciros que tal vez estais enfocando las cosas desde un mal punto de vista o ideas preconcebidas.

Y este post no tiene otra misión que agradecer el interés que poneis, pero las casas no se empiezan por el tejado, así que no atribuyais a «burocracia excesiva» lo que a lo mejor es un error de planificación.

Un saludo

@unne wrote:

yo en mi opinion veo buenas ideas,y veo mucha burocracia, en vez de agilizar y decir,mira  haz esto y yo te ayudo, es mejor decir mira hazlo y ya veremos q hacemos… pues no eh. Si kereis hacer una cosa de esa magnitud hay q implikarse,sino no pidais ideas ni gente q kiera ayudar si luego le dejais todo el marron a el, y ni sikiera una minima ayuda indispensable. solo es mi opinion,pq veo q algunos tienen buenas ideas y nada.

Supongo que el hilo se ha ido complicando y eso ha llevado a equivocos, pero nosotros en ningun momento hemos pedido que alguien codifique un cliente «para el mud» y a la vez no le proporcionemos ayuda. Creo que viene bien aclararlo porque visto asi parece que somos unos negreros desagradecidos.
Este post hablaba sobre el cliente que se ha ido desarrollando y que por determinadas razones se ha parado. Ademas se os ha pedido opinion sobre como hacer ciertas cosas e ideas para otras cosas nuevas, pero no se ha lanzado un grito de ayuda para que un tercero haga el cliente para nosotros. Ha sido Raiman, de manera totalmente desinteresada y que no nos cansaremos de agradecer, el que se ha propuesto a hacerlo, pero desde un primer momento hemos querido dejar claro (si no ha sido asi desde el principio creo que lo ultimo que han escrito ya varios inmortales lo aclaran) que seria un cliente hecho por Raiman y por tanto ajeno a mud. Si despues de hecho quisiera regalarnos el codigo y nos gustase, lo podriamos llegar a usar (con o sin modificaciones) como cliente oficial.
Si el cliente oficial que se estaba haciendo se ha detenido pero a la vez queremos hacer uno en un futuro, podreis deducir que una de las razones principales ha sido la falta de tiempo. Por ello debeis comprender que si no desarrollamos un cliente que ya esta a medio hacer por falta de tiempo, no podriamos participar activamente en hacer de cero un cliente que, ademas, no seria oficial. Por ello si Raiman (o quien quiera) hiciera finalmente un cliente y necesitase ayuda/opinion sobre temas genericos del mismo estariamos encantados en guiarle, pero no de manera activa, mas que nada porque para eso ya lo hacemos nosotros.

Contestando a Raiman, no digo que no te pongas metas altas como objetivo a largo plazo, pues para hacer un cliente que simplemente se conecte, tenga macros y alguna tonteria mas ya esta el mudmagic que ademas es multiplataforma. Sin embargo lo que no puede hacerse es ponerse como objetivo una alta meta y no comenzar a hacer la base hasta no tenerla totalmente clara.
En este caso, primero hay que hacer un cliente que funcione, que sea atractivo y tenga sus cosillas y luego, cuando la base este, podria llegar a pensarse distintos protocolos para mejorar la comunicacion entre el cliente y el mud. Hacerlo en el sentido contrario (es decir, primero diseñar la comunicacion y luego hacer toda la base, siendo estas dos partes independientes) es contraproducente por las razones ya expuestas.

He ido leyendo todos los comentarios segun los poniais, y no escribi antes para no desentonar, pq lo ke explicais ahora es lo ke parecia, ‘tu hazlo, y ya veremos si lo tiramos a la basura o lo usamos de papel higienico’.
Me alegro ke se haya ido aclarando, espero ke con esto todo vaya empezando a rodar, ya que creo ke raiman puede ir haciendo un cliente bueno, multiplataforma y multimud, y cuando la cosa este en marcha ya, se pueda especializar y oficializar a reinos de leyenda.

Un saludo a todos.

@Ilgrim wrote:

Pd: Querria, aprovechar para dar las gracias, a la gente que dedica tanto tiempo, y lineas de codigo para que el resto podamos disfrutar del que posiblemente es el mejor mud en lengua castellana. Es un esfuerzo del que no todo el mundo es consciente, e igual que normalmente, os toca soportar prisas,quejas,llantos y pataletas, esta vez al menos, quiero haceros soportar un poco de reconocimiento por tanta dedicacion y trabajo.

Y el único en activo que yo sepa…

Siempre es un placer cuando haces divertirse a gente como tu Ilgrim. Un «gracias» hace que merezca la pena horas y horas de trabajo. Gracias a ti.

Me alegro de verte de nuevo por aquí, tu visión del tema siempre ha sido muy correcta y estoy personalmente interesado en seguir en contacto con este tema. Muchos comenzamos un cuatrimestre nuevo y quizá tengamos tiempo para ponernos con proyectos de este tipo. De cualquier modo, te mantendremos informado.

Un saludo muy grande y espero que pronto puedas escribir con tiempo y con el proyecto aprobado 😉

Por si alguien se atreve a trabajar en un cliente java, he encontrado uno llamado jamochaMud que tiene licencia gpl y la javadoc de sus clases hecha. Por contra es practicamente lo que proponia yo como primer paso, es decir, un cliente que se conecte y poco mas.
La web es http://www.jamochamud.org/index.html

@faraon wrote:

He ido leyendo todos los comentarios segun los poniais, y no escribi antes para no desentonar, pq lo ke explicais ahora es lo ke parecia, ‘tu hazlo, y ya veremos si lo tiramos a la basura o lo usamos de papel higienico’.
Me alegro ke se haya ido aclarando, espero ke con esto todo vaya empezando a rodar, ya que creo ke raiman puede ir haciendo un cliente bueno, multiplataforma y multimud, y cuando la cosa este en marcha ya, se pueda especializar y oficializar a reinos de leyenda.

Un saludo a todos.

No, en ningún caso. Sabemos lo que jode perder horas para nada, como para ir por ahí soltando eso xD
Simplemente, las entrañas del nuevo protocolo se debe desarrollar desde la jerarquía de inmortales. Por lo que ahora mismo, lo que puede hacer, es un cliente sin más. Que ya le vendrá muy bien a la gente, y si luego lo podemos reaprovechar perfecto, y sino también, porque crear un protocolo completo nos va a llevar tiempo, y no es algo que vayamos a tener mañana.