Partida Rol por web

A ver si yo me pongo también al día y puedo responderte con calma esta noche (española) Matute, que mi intención es revisar hoy el Autorol para ver que posibilidades tengo de abrirlo al público en formato 'jugar'. Gracias por recopilarme los pendientes, me vendrá genial para centrarme porque estos días estuve con los tableros (¡que ya están casi listos también!).

Lo que te aclara Udas de las escenas de control va bien encaminado y a la noche os lo amplío pero un detalle: el jugador sí que puede ver lo que ponéis en una escena de control. Si tiene un texto éste se añade a la escena resultado. Y si el sistema pasa por varias escenas de control consecutivas los textos se van 'acumulando'.

Espero ponerme con ello esta noche y explicarlo bien.

Con el tema del puente se me están liando varias cosas en el trabajo, así que me temo que la revisión de todo esto quedará para el jueves/viernes, que es festivo y puente, y tendré la cabeza más fresca para programar la Natilla :)

When you can. It´s your time.

Una duda que me acaba de surgir: en una variable se puede poner una imagen? O quizá existe algún modo de poner la url de la imagen y con código ponerla en el texto?

Explico un poco el motivo: voy a crear una serie de espacios para guardar objetos en mi partida, y quiero poner imágenes para esos objetos, como un espacio vacío si no llevas nada. Pero había pensado poner un item que fuera almacenando las imágenes para luego ponerlas todas juntas (dado que no sé usar frames y tampoco sé si con frames lo podría hacer).

¿Alguna idea? ¿Se puede hacer lo que planteo?

Respuesta rápida: Sí. Las variables tienen incluso un campo imagen (para cuando son objetos de inventario) pero también otro para poder almacenar imágenes que cambian. Lo que no sé es si los puse públicos... tengo que revisarlo.

Respuesta elaborada: como mañana no me ponga con el Autorol 2.0 me va a quedar hasta el fin de los tiempos. Me he tomado un puente sabático (¿eso existe?) y ahora voy a una partida por vídeo en Discord y a las 20:00 tengo la gala de la Umbrionada. Pero mañana ¡fijo que lo retomo por fin! ¡Tiene que ser!

Yo tampoco hice demasiado este fin de semana. A ver si la semana que viene avanzo un poco más.

En realidad a fines de la semana pasada me di cuenta que estaba usando un montón de escenas que podían ser resueltas con una sola, usando variables para marcar las diferencias entre cada caso y me dedique a armar la escena general (control de puertas) y comenzar a cambiar cada apertura y cierre de cada puerta (originalmente era una escena por cada caso) por la asignación de variables y el llamado a esa escena general para luego borrar las escenas que ya no usaba más. Mi idea es, esta semana terminar los cambios y resolver las pocas puertas que no había resuelto originalmente

Sin embargo, mientras estaba con eso descubrí un tema más que creo debes verificar. Estuve viendo que puedes hacer un {{ Escena | Texts }} direccionado a una escena que, a su vez tenga otro {{ Escena | Texts }}. Más allá que a mi me resultó muy cómodo (no deja de ser una sub-rutina que a su vez llama a otra sub-rutina), creo que puede generar problemas de recursividad.

Sea porque alguien haga un Texts direccionado a la misma escena que lo llama o que desde una escena A se haga un Text a la escena B que a su vez lo haga a la escena A original, está claro que, en ambos casos, se producirá un loop infinito.

No quise probarlo, dado que estoy casi seguro que se va a pinchar. Eso no me preocuparía tanto (después de todo es obvio que va a pasar), sino que no se como afectaría al servidor que se produzca un ciclo infinito de asignaciones.

No digo que lo impidas, pero si creo que sería interesante que por lo menos verifiques que no afecte al servidor.

¡Madre mía que malvados estos Cuervos que nos chapan el chiringuito!

A mí me ha salido del revés el tema de vacaciones y no he tocado ni una línea de código (cosa que tampoco veo mal, desde otro punto, porque he desconectado al 100%). Esta semana será una montaña rusa en el trabajo (el regreso siempre cuesta) pero mis planes (jaja) son que en la siguiente empiece a montar todo lo pendiente de Autorol & Natilla. Así que os iré informando.

Buenas.

La semana que viene preparo con Sharak la puesta de largo del Autorol 2.0 para montarle una web en condiciones (en realidad será parte de la Natilla aunque tenga un 'frontal' específico de momento para el arranque) y hoy he terminado el sistema de importar/exportar mediante scripting. Mi intención es que antes de que finalice enero esté ya abierto a los jugadores (libre) y a creadores de historias (seleccionados).

Entre hoy mañana dejaré listo el sistema para importar (de hecho eso ya está) y exportar scripts. Pondré también las instrucciones sobre escenas de control, algunos ejemplos complejos de su uso (he creado, como Matute, un sistema de escenas de control que simulan rutinas de videojuego) y el scripting (cada vez estoy más convencido de que el scripting será una herramientas de 'traspaso' pero ahora mismo veo infinitamente más cómodo trabajar directamente en la plataforma que mediante scripts).

De Matute y Udas no tengo ninguna duda de que están 'en activo' pero me parece que los demás no. Si alguien quiere permanecer en esta partida a partir de la semana que viene que me avise por aquí, de lo contrario los saco de la partida. No hay problema ni compromiso. Yo soy el primero que ha tenido que dejar esto 'colgado' por motivos externos, pero no tiene sentido tener escenas de beta-testers que no beta-testean ;)

Evidentemente, yo me quedo. Hay una partida que estoy haciendo que la he dejado mucho tiempo colgada, pero que me gustaría terminar. Lo malo es que es complicada, quizá demasiado, pero quiero intentar seguir con ella. A ver si tengo tiempo.

Y luego, claro, para las dudas y eso esto está genial. Como dijiste, 6 ojos ven más que dos.

Una cosa: lo que hagáis aquí permanecerá cuando abramos Autorol 2.0. Los usuarios, de primeras, sólo podrán ver las partidas 'aprobadas' pero vosotros podréis invitar a quien queráis como 'beta-testers' (tendrán que ser usuarios registrados, pero todos los umbrianos están registrados por defecto). Evidentemente si sólo son pruebas o experimentos (podéis abrir más de una sin ninguna limitación) las podéis borrar cuando queráis.

or mi parte he estado muy ayway en navidad y post-navidad, pero aun tengo las ideas de la partida-homenaje a la señora presidente.

asi que venga, let's go. Aparte de que os he seguido leyendo y quizá pueda usar lo que aprendí de mat y de Udas

Obviamente sigo.

En algún momento dijiste que lo que tenía en la cabeza no era fácil de desarrollar y, como en su momento te reconocí, tenías razón!

Sin embargo avance bastante. Ya resolví totalmente los siguientes temas:

* los movimientos, incluyendo aperturas y cierres de aberturas y otras formas de traspasarlas (incluso sufriendo daño si los dados y las característica del PJ no ayudan),

* la información de inicio (que es variable en función de lo que definan los dados que será la partida y cuanto tiempo (y % de contagio) esté dispuesto a utilizar el PJ para saber cosas que lo puedan ayudar)

* la generación del PJ (y la dificultad con que se quiera encarar la partida),

* la ayuda (tanto la pantalla general como los detalles de todo que ya está desarrollado)

Ahora estoy avanzando con los distintos modos curación que depende de que objeto utilice el PJ para curarse, sea en Puntos de vida o porcentaje de contagio (ya está definida la ayuda y más del 50% del desarrollo)

Y en cuanto termine, espero a partir de la semana que viene, avanzaré con los temas que me quedan:

* lo relacionado con la asignación (al azar) de objetos en los contenedores y las búsquedas en los mismos (generando, si los dados y características no ayudan, ruido al realizar la búsqueda).

* la finalización de las partidas con la asignación de un puntaje en función de como se haya resuelto la historia, para poder comparar performances entre distintos jugadores.

* la definición (variable) de donde estarán los bichos malos al inicio de la partida, siendo a su vez variable la cantidad de bichos que pueda haber (en función de la suerte y el nivel de dificultad seleccionado) y,

* lo más difícil, los combates, no tanto por el combate en si (aunque preveo por un lado distintos tipos de ataques, por otro que los combates también generen ruido y en tercer lugar la posibilidad de que los combates sean uno contra uno ó uno contra muchos), si no por incluirles a los bichos la inteligencia de que por un lado que ataquen de forma distinta según si son uno o muchos y que sean capaces de acercarse al combate (incluso abriendo puertas) y agregarse al mismo si escuchan ruido

Supongo que si tengo que definir un porcentaje de avance del proyecto en general (como lo tenía previsto), ya desarrolle el 50%. Solo que me queda el 50% más complejo!!

Me quito el sombrero Matute, no solo por lo ambicioso de tu proyecto sino porque lo estás haciendo 'a pelo', sin un manual de instrucciones, mientras intentas descifrar para que vale cada cosa.

Aprovecho para comentaros que he añadido ya los frames.

¿Qué son los frames?

Pues son 'partes de la pantalla'. Ahora podéis tener dos escenas visibles a la vez en el sistema. Esto es útil para tener, mientras diseñamos, una escena continuamente visible que muestre las variables. Luego, en la partida final, puede hacer las veces de ventana de estado (energía, inventario, etc). Están en la solapa de datos básicos de la partida.

Por defecto deberíais tener un único frame (ppal) cuya escena inicial es la escena de comienzo de la partida.

Podéis añadir otros frames y especificar para cada uno cual es la escena que se visualizará.

Por ejemplo podéis crear una escena que sea PANEL-CONTROL con este texto:

Variable X: {{x}}
Variable Y: {{y}}

No necesitáis conectarla con nada.

Luego os vais a frames y añadís un nuevo frame, de ancho 4 (por ejemplo) al que le pongáis como escena inicial 'PANEL-CONTROL'.

El otro frame (el principal) lo modificáis y le ponéis un ancho de 8 (por ejemplo, recordad que las columnas visibles en pantalla siempre suman 12).

Al reiniciar la partida veréis ambas escenas una al lado de la otra de forma continua.

Así en la ppal os vais moviendo y en PANEL-CONTROL veis los resultados de las variables. La ventaja más importante es que podéis modificar PANEL-CONTROL en cualquier momento para que muestre más o menos variables. O para que ejecute una acción cada vez que se muestre (por ejemplo que sume un turno cada vez que aparezca en pantalla).

No sé si me he explicado bien. Mañana espero darle una vuelta al manual.

Cita:

Y, sabiendo (o con un manual de instrucciones) lo hace cualquiera ;-)

Interesante, me gusta lo de los frames. Un par de preguntas respecto a los mismos
1. Como añades uno (no veo el botón de añadir)
2. Solo se pueden definir frames en columnas? o pueden ser las primeras filas?
3. Entiendo que los botones (links) funcionan en ambas ventanas en simultáneo, no?

- Botón: ahora debería estar disponible. Se me coló un permiso.

- Van en columnas primero y en filas después. Explicación abajo.

- Los botones afectan a todo pero el frame que se actualiza (de momento) es el afectado. Es decir: si hay un link en el frame de la izquierda y lo pulsas se actualiza el frame de la derecha con respecto al enlace (carga esa escena en la izquierda) pero el de la derecha también se refresca (por lo que lo que suceda con las actualizaciones de variables le afecta). En una prueba avanzada que estoy haciendo he llegado a poner links en un frame y otro con lo que tengo a la izquierda la acción (con enlaces de movimiento) y a la derecha equipación y estrategia (con sus propios enlaces a subpantallas de inventario, reglas, etc).

Ya veo el botón.

Respecto a los frames, como declaras uno (o más) dentro de otro? EDITO: YA lo vi!

De cualquier manera, más allá de eso, si entendí la lógica entiendo que si creo 2 frames, ambos de 12 puntos, va a quedar uno arriba del otro. Puede ser?

Respecto a que es lo que actualiza cada link, tengo forma de que pulsando un botón a la derecha, cambie la pantalla de la izquierda? Estoy pensando en usar ese frame (derecho) no solo para el estado del PJ e inventario, sino para los comandos globales (los que siempre estarían disponibles, por ejemplo el botón de ayuda, o algunos que pueden estar o no - como el de curación, que depende si tengo objetos para curar -). Entonces, la idea sería que, por ejemplo, si pulso el botón AYUDA (a la derecha), la pantalla de la izquierda me muestre la ayuda. Es posible o es un disparate?

Otra pregunta, hay alguna forma de "dibujar" una linea que ocupe todo el ancho de una escena?, porque con "----" depende del ancho de pantalla del que lee

Para dibujar una línea de ancho de escena sería con el comando <hr/>, en breve estará disponible (como en el ckeditor). También se podrán aplicar fondos, recuadros, etc.. a cada frame.

Si algo tiene 12 espacios de ancho, efectivamente, desplaza todo lo demás a la siguiente línea.

Que un frame afecte a los frames aledaños está previsto pero de momento no funciona. Habrá una opción en los enlaces que indique que Frame es afectado por su pulsación (todos o unos concretos) pero es algo para la segunda vuelta (una vez arraquemos el Autorol). Se puede simular gracias a las escenas de control globales llamadas con el decorador |texts. Es algo que pondré en un ejemplo dentro de poco en cuanto termine la demo del concepto de 'marchas al oeste'.

Aunque por la tarde espero subir el tutorial en este hilo estoy charlando con Miles Teg sobre las funciones de Autorol y he incluído una exportación del scripting de la aventura que usaré para el tutorial explicando muy someramente como funciona. El scripting lo veo últil para escenas donde hay un montón de variables en juego (añadir una a una es un coñazo) aunque esta tarde igual meto un botón que permita introducir todas las consecuencias y/o condiciones escribiéndolas en líneas, en vez de 'añadir', 'escribir', 'aceptar'. Y así el scripting me temo que iría quedando relegado al tema de exportar la historia para tenerla fuera de Autorol y/o importar/exportar cosas entre historias.

De hecho en lo de exportar está previsto que en la edición 'Premium' para autores y usuarios con carné se pueda exportar el Autorol en formato librojuego de toda la vida, con sus marcadores y enlaces. Incluso que lo exporte en PDF. Es algo que, después de todo el trabajo, resulta trivial. Bien cierto es que las aventuras más complejas (como la que hace Matute o alguna de las que prepararo yo) serán inviables en formato papel por el uso de variables y demás... pero oye, es una opción para historias más sencillas.

Chemo, no se que hiciste, pero perdí el acceso al modo edición de historias.

Puede ser que justo estés tocando algo?

¿Te da algún error? ¿Qué sucede exactamente?

Sí que subí una actualización para poder meter varias condiciones y consecuencias de golpe escribiéndolas a mano, pero deberías poder acceder a tu historia sin problema. Dime que fallo te da.