Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs

Respondiendo a la invocación de Ruber, salgo un momento de la cueva para comentar tu idea.

El tema de las aventuras de texto multijugador siempre me ha interesado. Aunque es cierto que no es fácil encontrar jugadores, creo que es algo que ofrece muchísimas posibilidades, sobre todo si los personajes jugadores tienen diferentes características que haga necesario que colaboren para conseguir un objetivo (por poner un ejemplo muy simplón, un personaje muy alto que es el único que llega a coger un objeto de encima de una estantería, pero luego se lo tiene que dar a uno bajito que es el único que cabe por un agujero... pero todos sabemos que se puede llevar mucho más lejos). Es una forma de acercar las aventuras a una experiencia de rol de mesa. Por eso AGE está diseñado, y lo estuvo desde el principio, para poder hacer estas cosas.

Desde la experiencia desarrollando un sistema de creación de aventuras, creo que no es realista crear un sistema para aventuras multijugador decente en tres meses y en solitario. La creación de un sistema de creación de aventuras ya es, en sí, bastante trabajosa. Hay toda una serie de detallitos que se deben incluir, funcionalidades que todo el mundo espera y que vas sumando y al final son un montón de líneas de código. Además, si quieres que la cosa sea extensible, tampoco puedes tomar el camino más corto sino que tienes que hacer las cosas medianamente genéricas, lo cual añade más trabajo.

El multijugador añade bastante complejidad a mayores, más de lo que la gente suele creer. Ten en cuenta que no es sólo programar unos sockets para que los clientes se comuniquen con el servidor (que también), gestionar eventos como desconexiones y reconexiones (que también), y hacer que los personajes jugadores sean objetos independientes y asimilables a los no jugadores (que es algo que ya harías también para monojugador si diseñas bien). Son también cosas como por ejemplo programar el sistema de mensajes para que cada evento se narre indistintamente en primera, segunda o tercera persona. Si estamos los tres en la misma habitación y Ruber me ataca con la espada, yo tengo que leer "Ruber te ataca con la espada", él tiene que leer "Atacas a Al-Khwarizmi con la espada", y tú tienes que leer "Ruber ataca a Al-Khwarizmi con la espada".  Esto, por cierto, también supone necesariamente un cierto grado de trabajo para el creador de aventuras cuando introduce acciones personalizadas, y posiblemente es uno de los motivos por los que la gente no crea aventuras multijugador: si ya las normales dan trabajo, éstas dan más. De todas formas, te animo a crear una, sea con un sistema propio o uno existente. ¡Sería genial!

Como te ha dicho Ruber, AGE es un sistema que puedes utilizar para crear aventuras de este tipo. Está diseñado desde el principio para ello (por ejemplo, tiene el soporte integrado para las descripciones en distintas personas que he mencionado).  Respecto a los ítems concretos de tu lista:

- Explorar, acciones básicas, inventario: todo está soportado, por supuesto.

- Hablar con personajes: también está soportado. Por defecto no es por menús, sino con conversación libre. Podrías implementar menús sin mucho problema, se ha hecho en bastantes aventuras en AGE (por ejemplo, "Una de Dragones"). Sin embargo, en el caso concreto de una aventura multijugador, te recomendaría encarecidamente que lo hagas con conversación libre, por un sencillo motivo: las aventuras multijugador son mucho más naturales si son asíncronas (en tiempo real), y los menús son por naturaleza síncronos. ¿Qué ven los otros jugadores mientras un jugador está dentro de un menú? ¿Qué pasa si varios inician el mismo menú? Todo ello se puede resolver, pero opino que es mucho más natural con la conversación libre, que además posibilita fácilmente que varios jugadores puedan intervenir en la misma conversación (y no tenga cada uno la suya).  Es sólo mi opinión.

- Modelar el comportamiento de personajes no jugadores: también está soportado, se les pueden dar las mismas órdenes que a los jugadores.

- Hablar con otros jugadores: se puede haber simplemente por la propia conversación libre, siempre que los jugadores estén en la misma habitación, se oirán unos a otros (o sea, si yo pongo "decir hola", los demás veréis: "Al-Khwarizmi dice: hola"). Si quieres implementar un chat global que se lea desde cualquier parte del mundo, no viene implementado por defecto  pero lo puedes hacer (AGE permite añadir scripts de comportamiento a todos los objetos) y sería bastante trivial, no creo que más de 10 líneas de código.

- Gestionar eventos de tiempo: sin problema, AGE soporta tiempo real y es el modo más natural en el caso de multijugador.

- Alternativas de descripciones: se pueden poner sin problema.

- Describir de forma inteligente/no robótica las situaciones: esto te lo tendrías que currar tú programando en los scripts de tu aventura. En  la última versión de "Wizard's Quest: Morluck's Lair" hice algo parecido para el combate, puedes echarle un vistazo (cosas como que si te atacan dos veces, no aparezca "El goblin te ataca con la espada. El goblin te ataca con la espada." sino "El goblin te ataca con la espada. ¡Te vuelve a atacar!", etc.

- Mantener la posición relativa de los jugadores: no está por defecto pero lo podrías programar en tu aventura. Ojo que lo de la izquierda y la derecha se ha intentado alguna vez pero puede resultar un poco farragoso... Ruber de hecho tiene un experimento con eso, "Randolph Dwight", que estaba muy bien.  Pero lo estaba porque su aventura en concreto se ajustaba a eso. En general es cuestionable que ese tipo de control de movimiento sea cómodo en la práctica. Estoy de acuerdo con lo de evitar "norte", "sur" y demás, pero eso lo puedes hacer sin posicionamiento relativo. Todas mis aventuras se pueden explorar sin poner ningún punto cardinal, simplemente es cuestión de soportar cosas como "subir por las escaleras", "ir por la puerta grande", "ir al baño", "salir de la habitación", etc.

- Poder controlar la secuencia de eventos: sin problema.

Como ves, AGE te proporciona buen soporte para implementar lo que quieres. Ahora bien, también hay puntos negativos. Que son los siguientes:

- Como ya ha dicho Ruber, AGE está hecho en Java, que ha caído en desgracia a la hora de ejecutar contenido online.  La forma de ejecutar aventuras pasa o bien por hacerlo en el escritorio (cosa que no excluye la posibilidad de multijugador, claro, se conectan a través de sockets) o bien hacerlo en el navegador sólo después de dar permisos y aceptar cuadros de diálogo que asustan. Esto es una limitación que seguirá ahí salvo que alguien porte el sistema a JavaScript, cosa que yo no voy a hacer. Pero si quieres, ya sabes... el sistema es totalmente libre, y tendrías todo el apoyo que te pueda dar :)

- Aunque la funcionalidad de multijugador está ahí, no hay mucha documentación ni muchos ejemplos porque en la práctica la gente apenas la ha usado. Bastante gente ha creado aventuras con AGE, pero prácticamente todas monojugador. Sólo se creó una aventura multijugador, que es "Burbuja", de dddddd. http://wiki.caad.es/Burbuja La puedes usar como ejemplo, pero el problema es que no es una aventura al uso, sino más bien un juego de simulación sobre especular en los mercados y ganar más dinero que los demás.  Por lo tanto, no explota realmente todas las capacidades del sistema dado que no tiene localidades, apenas necesita decir a unos jugadores lo que hacen los otros, etc. En todo caso, si decides usar AGE y te surge cualquier duda, sólo tendrías que preguntarme (o mejor aún, preguntar en el foro del CAAD, donde hay más gente que conoce AGE aparte de mí y alguien te echará una mano). Y de hecho si te decidieras a hacer eso, seguramente me animaría a escribir una documentación como Dios manda sobre cómo hacer aventuras multijugador, que hasta ahora no he hecho porque simplemente nadie había mostrado interés.

Por cierto, la documentación (aunque sin decir apenas nada de multijugador) la tienes en http://www.caad.es/aetheria/doc/doku.php

Vaya tocho he soltado. Me vuelvo a mi cueva, hay demasiada luz aquí fuera :)

¡Hola, Al-Khwarizmi!

 ¡Gracias por contestar con tanto detalle! Y gracias a Ruber por invocarte :D.

 Creo que hace algunas Jams le eché un vistazo a AGE, pero no me atreví a aprender a usarlo... Y como llevaba lustros con ganas de hacer uno propio, no continué investigádolo. Veo que tengo que darle otra vuelta, pues parece muy sólido, ¡y con muchísimas características!

 Para empezar, querría echarle un vistazo a PUCK, pero no lo encuentro... La verdad es que soy muy perezoso :_)

 Depende de cómo esté diseñado, quizás no sea difícil convertirlo a javascript con Google WebToolkit, que puede compilar Java a programas en Javascript... Eso sí, la comunicación clientes-servidor habría que modificarla. Pero se podría comenzar con las versiones de un solo jugador.

 También podría intentar crear lo de las descripciones automatizadas: imagina que, para crear una habitación, describes en algún formato (JSon, XML, ...), qué objetos hay en el escenario, dónde están, sus propiedades... Y una entidad "narradora" genera la descripción con distintos estilos. Creo que hay investigaciones sobre la generación inteligente de descripciones, pero no me dedico a ese tema...

 En resumen, que tengo que estudiar AGE, por si puedo extenderlo, o usarlo directamente. 

 ¡Gracias!

Acabo de darme cuenta de que PUCK está disponible en github. 

Por otro lado, me interesa el uso de BeanShell.. .lo que pasa es que parece un poco antiguo. En ocasiones anteriores he considerado usar Rhino, un intérprete de JavaScript, pero también de Java, que desarrolló Mozilla. El problema que tuve fue desarrollar un sistema de eventos asíncronos que evaluaran las condiciones que el diseñador eligiera para el juego: como tenía que realizar las comprobaciones cada vez que se producía un cambio en el estado del juego, no parecía una solución demasiado eficiente. Pero no llegué a programarla completamente, estaba en proyecto...

 ¡Gracias de nuevo!

¿Juraría que Puck puede exportar a otros sistemas? Quizás ya usa Json, y en ese aspecto lo podrías reutilizar.

Los mundos de AGE son precisamente XML. Las características de los objetos están descritas de forma declarativa, salvo los comportamientos que hay que definir en código (BeanShell). Así que el material para generar descripciones está, la herramienta es adecuada para eso. Otra cosa es que generar bien descripciones podría ser casi una tesis doctoral...

Bueno, si te gusta AGE pero no te gusta BeanShell, siempre lo podrías cambiar por otro intérprete de otro lenguaje (mientras el intérprete esté escrito en Java). AGE está diseñado para pasar sus eventos, métodos invocables y demás "callbacks" a un intérprete. Ahora mismo el que hay es el de BeanShell, pero el acoplamiento es débil: fue diseñado desde el principio para que resultase sencillo añadir alguno adicional, y en el XML hay un campo para especificar en qué lenguaje está cada fragmento de código (que se puede usar para decidir qué intérprete llamar), de forma que es perfectamente posible añadir otro lenguaje y que las aventuras puedan funcionar indistintamente con BeanShell y con el nuevo. 

En realidad creo que tiene mejor pinta BeanShell, porque tiene una sintaxis menos estricta que el Java de Rhino. Simplemente lo decía para que no se quedara obsoleto en algún momento... No sería una prioridad para mí modificarlo. Pero es bueno saber que es fácil llevarlo a cabo :).

Sí que tengo que estudiar los documentos XML, para ver si podría faltarle algún atributo o etiqueta nueva que pudiera necesitar para los diálogos, por ejemplo.

 ¡Gracias de nuevo!

¡Buenas!

Me he pasad otodo el día trasteando, pero tengo una primera versión web de la versión de línea de comandos, basándome en Cheapage, GWT, y GWT-Material.

 Se trata de una aplicación web (Servlet GWT + web GWT) responsive, que sondea cada 2 segundos al servidor por si hay algún mensaje nuevo.

 No soporta el estilo de fuentes, ni sonido ni imágenes, ni esperar una tecla... aunque supongo que se podría mejorar poco a poco.

 Además, seguramente, al usar un servidor central donde se ejecuta AGE y el mundo concreto, quizás se pueda generalizar para que sea multijugador... Pero me pierdo con las clases y demás, necesitaría que me echaras una mano. 

 Pero he disfrutado del ejercicio. Aunque aún no me entero bien de los entresijos de AGE. ¡Es enorme!

 Adjunto una captura del navegador web, ejecutando el juego del "Insecto".


¡ Salud!

-Juanjo

PD1: no he podido recompilarlo bien desde NetBeans, importando el proyecto con Ant. Pero tomando el AGECore.jar, y las librerías de las que depende, he podido desarrollar el servlet GWT.

PD2: Si usaba las librerías que vienen con el código fuente, no se ejecutaba correctamete. He tenido que coger los .jar de la versión binaria de AGEDevel.

PD3: sí, uso NetBeans...

(1 edit)

¡¡¡Juanjo, maquinaaaa!!!


Te diría que te pasases por la siguiente dirección del CAAD por si quierea compartirlo allí. Seguro que Al-kharizmi se lleva un alegrón :D


http://foro.caad.es/viewtopic.php?f=31&t=6282


Pinta bien el enfoque ;)

¡Gracias!

El caso es que no puedo registrarme en el foro... Soy un poco torpe... ¿Cuáles son las dos primeras cifra de PI, para ver si voy en buen camino...?

¡Salud!

¡Buenas!

Estoy pensando en otra interfaz para AGE. Ya lo intenté hacer para una aventura propia que, por supuesto, no terminé. 

 La idea es integrar el motor como bot de Telegram. El teléfono lo llevas encima casi todo el día, y sería fácil acceder desde la app de telegram (tanto para smartphone como para web).

 Lo que no caigo ahora mismo es si habrá alguna función de AGE que no pueda implementarse en la interfaz del cliente de mensajería instantánea...

 Otra cosa interesante que permite el bot de telegram, es que puedes ejecutarlo en cualquier ordenador, aunque no tengas una dirección IP fija. Esto mitiga en parte la necesidad de buscar alojamiento en servidores de pago.

 ¡Salud!

¡Buenas!

 Esta mañana he creado otro prototipo de interfaz para AGE. Se trata de un bot para Telegram.

 Podéis probarlo en Telegram si invocáis al bot: @aetherial_game_engine_bot . Pero tengo que tener el portátil encendido XD. Y no sé cómo se comporta si hay varios jugadores intentando acceder, aún.

 Como en la implementación anterior, coge la aventura de ejemplo "Insecto". No graba las partidas, ni hay sonido... Es solo una prueba de concepto. Pero es fácil añadirle funcionalidad...

 Una captura: