CAAD

Comunidad de Aventuras Conversacionales y Relatos Interactivos
Fecha actual 19 Sep 2020 01:01

Todos los horarios son UTC + 1 hora




Nuevo tema Responder al tema  [ 10 mensajes ] 
Autor Mensaje
NotaPublicado: 16 Sep 2004 17:07 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 10 Sep 2004 00:17
Mensajes: 3093
Ubicación: Chile
Adeptus escribió:
[...] Por cierto, el comentar los juegos podrí­a servir para poner on-line juegos recién hechos, una suerte de Beta-Testing pública, siempre es bueno tener la mayor cantidad de opiniones posibles :wink:


Abro, con este quote de un posting de otro foro, una discusión sobre la mejor manera de realizar el Betatesing de un juego de aventuras.

Veamos:

Axioma: la mejor manera, desde el punto de vista de la productividad, es en vivo y en directo: betatester y autor lado a lado frente al juego.

...lo que no siempre es posible, desde luego.

Así­ pues ¿qué alternativas nos quedan?

Obviamente, las alternativas son todas remotas; betatester y autor no geográficamente cosituados: ambos en lugares distintos (se entiende, ¿no? :P ).

De las remotas, distinguimos dos:

1. Sincrónicas: betatester y autor interactuan simultáneamente. En este caso, jugar y simultáneamente usar sesiones de IRC, messenger (la marca da igual), chat y/o terminal de texto sincrónico (grabando la sesión, como apoyo) es, creo yo, lo más parecido a la opción en vivo y en directo.

... pero:

f(diferencias horarias, diferencias geográficas, trabajo) =
el método remoto sincrónico no siempre es posible

...lo que nos lleva a la alternativa más común:

2. Asincrónicas: aquí­, no tengo recetas. Lo que para mí­ ha funcionado razonablemente bien es:

a) Autor enví­a versión beta a tester
b) Tester la juega, anotando su comentarios en lí­nea con la salida de texto
c) Autor recibe los comentarios del tester, los implementa (algunos, todos, ninguno: discusión por email...)
d) Se genera nueva versión del juego y repetir desde a)

Notar que este procedimiento funciona mejor con un betatester a la vez.

Bueno, esos son mis planteamientos.

¿Comentarios, ideas?

_________________
[Incanus] - Sígueme en itch.io
El Escritorio - Blog Aventurero y Literario


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 16 Sep 2004 18:23 
Desconectado
xyzzy

Registrado: 09 Mar 2004 22:50
Mensajes: 9150
Cada betatester tiene su propio sistema, y me refiero a betatesters comprometidos, no a gente que eventualmente se ofrece a testear una aventura, la juega y si da la casualidad que se encuentra un bug pues bien, y sino pues también.
Yo betatesters por vocación solo conozco a Urba y a mí­ misma; y cada uno tenemos nuestra técnica depurada a través de montones de testeos y retesteos. Recuerdo que una vez pensamos en hacer equipo y no nos pusimos de acuerdo precisamente por el tema de que nuestra forma de trabajar no era la misma.
Lo que hacen falta son betatesters comprometidos con su tarea, capaces de jugar y rejugar la misma aventura las veces que haga falta hasta el aburrimiento, las técnicas usadas es lo de menos, porque cada uno encontrará la suya propia.


Arriba
 Perfil  
 
NotaPublicado: 16 Sep 2004 19:09 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 10 Sep 2004 00:17
Mensajes: 3093
Ubicación: Chile
Bueno... que el compromiso es necesario, a qué dudarlo. No sabré yo de eso... :wink:

Pero la duda es: ¿cómo le hacen?

¿masomeno cómo lo he puesto escrito más arriba u otro? Por mi propia experiencia (Jene y Urba saben de ello) que el método no da lo mismo.

Cueeeenteeen...

_________________
[Incanus] - Sígueme en itch.io
El Escritorio - Blog Aventurero y Literario


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 16 Sep 2004 19:23 
Desconectado
xyzzy

Registrado: 09 Mar 2004 22:50
Mensajes: 9150
2. Asincrónicas:
Creo que ese es el método que seguimos ambos, tanto Urbatain como yo.

En lo que diferimos notablemente es en que él prefiere hacer un betasteo en paralelo, con varios betatesters a la vez, testeando la misma versión; y yo prefiero hacerlo de modo secuencial, una versión y un solo betatester.

Las razones ya las discutimos en su dí­a, a mí­ no me gusta emplear mi tiempo en encontrar los mismos bugs que están encontrando otras tres personas, ni postear el bug que otra encontró dos dí­as antes cosa que yo no tengo manera de comprobar. Tampoco me parece cómodo que un autor tenga que atender a la vez a los requerimiento de tres o cuatro betatesters, me parece que es para acabar de los nervios. ;)


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 16 Sep 2004 19:34 
Desconectado
Guionista
Guionista
Avatar de Usuario

Registrado: 09 Mar 2004 21:54
Mensajes: 378
Ubicación: La red
Pero cuando funcionaba el mud era genial hacer el testeo sincronico :)

a ver si lo resucitamos algun dia


Arriba
 Perfil  
 
NotaPublicado: 16 Sep 2004 20:00 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5312
Ubicación: Coruña
Incanus escribió:
Abro, con este quote de un posting de otro foro, una discusión sobre la mejor manera de realizar el Betatesing de un juego de aventuras.
(...)


Estoy de acuerdo en todo lo que dices, básicamente los métodos que yo utilizo son los que tú has mencionado: el ideal (estar con quien prueba la aventura en directo, que como dices es la mejor manera de testear pues te proporciona más información que cualquier otra), el sí­ncrono remoto (haciendo que el tester juegue la aventura por telnet o por IRC, mientras yo veo lo que va poniendo y le hablo por el IRC o mandando broadcasts) y el así­ncrono (por correo y tal). No conozco ningún método que no entre en alguna de esas categorí­as.

Centrándonos en el testeo sí­ncrono, proponí­a hace unos dí­as en la lista que se podrí­a pensar en crear alguna aplicación o módulo -estoy pensando en el AGE- especí­fica para el testeo. Si esto se hiciese bien, podrí­a conseguir que el testeo de aventuras fuese un proceso más rápido y eficiente.

La idea básica que proponí­a yo era la siguiente: el testeador juega la aventura a través de Internet. Pero los comandos que introduce el testeador no van directamente al motor del juego para que los procese; sino que antes pasan por el autor. El autor puede confirmar un comando, en cuyo caso pasará al motor y será interpretado de forma normal, o bien interceptarlo, en cuyo caso el autor puede modificar la respuesta del parser mandándole él algún mensaje al jugador.

De este modo, lo que se consigue es que el proceso de testing no se vea interrumpido por los posibles bugs o fallos de diseño del relato interactivo. Si nuestro juego acepta el verbo "tirar" pero no "lanzar", y el jugador pone "lanzar", nosotros podemos apuntar "lanzar" en nuestro to-do list para añadirlo, y a la vez interceptamos la entrada y hacemos que el parser responda como si se hubiese puesto "lanzar" para que el jugador pueda seguir testeando como si no hubiese pasado nada. En el caso de que ni siquiera hubiésemos considerado tal acción, siempre podrí­amos explicárselo al jugador con un mensaje.

Las preguntas que me hago al respecto de esta aplicación, y que todaví­a no me han sido contestadas de todo, es si (1) la gente usarí­a tal aplicación o módulo si existiera o tal vez es algo muy bonito pero demasiado complicado, y (2) hay alguna otra cosa que fuera conveniente incluir en una utilidad así­.

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)


Arriba
 Perfil  
 
 Asunto:
NotaPublicado: 16 Sep 2004 21:51 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 10 Sep 2004 00:17
Mensajes: 3093
Ubicación: Chile
jenesis escribió:
2. Asincrónicas:
Creo que ese es el método que seguimos ambos, tanto Urbatain como yo.

En lo que diferimos notablemente es en que él prefiere hacer un betasteo en paralelo, con varios betatesters a la vez, testeando la misma versión; y yo prefiero hacerlo de modo secuencial, una versión y un solo betatester.

Las razones ya las discutimos en su dí­a, a mí­ no me gusta emplear mi tiempo en encontrar los mismos bugs que están encontrando otras tres personas, ni postear el bug que otra encontró dos dí­as antes cosa que yo no tengo manera de comprobar. Tampoco me parece cómodo que un autor tenga que atender a la vez a los requerimiento de tres o cuatro betatesters, me parece que es para acabar de los nervios. ;)


Sí­... bueno, yo empecé (precisamente) Betateseando con Jene y Urba, y sencillamente fui incapaz de hacer un buen betatesteo (dedicado, atento... y educado, vaya) con dos personas simultáneamente.

Creo que, sí­ncrono o así­ncrono, el betatesteo ha de ser unipersonal (autor vs 1 tester) o de lo contrario resulta desquiciante (para el autor, claro está).

Si son varios testers, pues en fila (sí­ncrono o así­ncrono); un tester prueba hasta que se aburre/satisface (lo que primero salga :P) de testear y se pasa al siguiente de la lista (gracias por la espera, Jene :D ). Es lo más honesto y eficiente.

No se qué experiencia tendrá alguien más en el betatesteo multipersonal (así­ncrono o sí­ncrono); habrí­a que oirlas... pero después de una probada (y fue suave, ¿eh? 2 testers a la vez, no más) no me apetece repetir. :oops:

¿Comentarios?

_________________
[Incanus] - Sígueme en itch.io
El Escritorio - Blog Aventurero y Literario


Arriba
 Perfil  
 
NotaPublicado: 16 Sep 2004 22:09 
Desconectado
xyzzy

Registrado: 09 Mar 2004 22:50
Mensajes: 9150
Al-Khwarizmi escribió:
[

El autor puede confirmar un comando, en cuyo caso pasará al motor y será interpretado de forma normal, o bien interceptarlo, en cuyo caso el autor puede modificar la respuesta del parser mandándole él algún mensaje al jugador.]


Os centrais todo el rato en ver el testeo como una forma de conseguir que el "parser" entienda en todo momento al jugador, y el testeo es mucho más que eso.
Ese motor está genial, pero no va a impedir que un contenedor no tenga fondo, o que puedas tocar con la mano a un avión que vuela sobre ti a 5000 metros de altura. O que un grifo se pueda abrir cien veces seguidas sin necesidad de cerrarlo y nunca termine de llenar un cubo que has puesto debajo.

Al-Khwarizmi escribió:
[
Las preguntas que me hago al respecto de esta aplicación, y que todaví­a no me han sido contestadas de todo, es si (1) la gente usarí­a tal aplicación o módulo si existiera o tal vez es algo muy bonito pero demasiado complicado, y (2) hay alguna otra cosa que fuera conveniente incluir en una utilidad así­.


Pues todo depende del numero de autores que quieran ver sus aventuras testeadas. La verdad es que en todo el tiempo que estuvo ZX en el mud del canal, solo se testearon dos aventuras; la de "Drácula" y "A veces..." pero entonces parecí­a que no habí­a tanto interés en testear las aventuras. Ahora parece que la cosa ha cambiado, y es posible que la gente se interese.
Yo de todos modos preferirí­a que como en "inform" hubiera un "undo" en todos los intérpretes y que no hiciera falta ningún filtro que resolviera el intento a la primera; o sea puedo intentar "tirar", undo, "arrojar", undo, "lanzar", undo, "atinar". Eso me ha mostrado cuatro posibles verbos que pudieran no estar soportados en la aventura. Con el filtro, solo hubiera visto el primero.

Saludos


Arriba
 Perfil  
 
NotaPublicado: 17 Sep 2004 10:00 
Desconectado
Samudio
Samudio
Avatar de Usuario

Registrado: 09 Mar 2004 16:16
Mensajes: 5312
Ubicación: Coruña
jenesis escribió:
Ese motor está genial, pero no va a impedir que un contenedor no tenga fondo, o que puedas tocar con la mano a un avión que vuela sobre ti a 5000 metros de altura. O que un grifo se pueda abrir cien veces seguidas sin necesidad de cerrarlo y nunca termine de llenar un cubo que has puesto debajo.

Bueno, yo no digo que ese hipotético módulo vaya a resolver todos los problemas del testeo, con que ayudase un poco y fuese útil me conformarí­a. Además, por eso he pedido ideas adicionales para añadirle, para ver si sale alguna idea con la cual pueda resolver más problemas. Si tienes alguna para ayudar con ese tipo de situaciones que dices, no dudes en decí­rmelo :)

jenesis escribió:
Yo de todos modos preferirí­a que como en "inform" hubiera un "undo" en todos los intérpretes y que no hiciera falta ningún filtro que resolviera el intento a la primera; o sea puedo intentar "tirar", undo, "arrojar", undo, "lanzar", undo, "atinar". Eso me ha mostrado cuatro posibles verbos que pudieran no estar soportados en la aventura. Con el filtro, solo hubiera visto el primero.


Por desgracia la forma en que está diseñado el AGE, desde el propio modelo teórico para arriba, hace poco viable implementar un Undo genérico, rápido y que funcione bien. La cosa tiene varios problemas: el primero es qué es lo que deshaces (en la máquina Z supongo que deshaces un turno; pero en AGE no hay turnos sino unidades de tiempo). El segundo y principal es que en el AGE el programador de aventuras puede hacer prácticamente cualquier cosa, y lo que hace no tiene por qué ser invertible. En la máquina Z, el undo se implementará - que me corrijan si me equivoco - deshaciendo las propias instrucciones de la máquina Z. Pero AGE no se basa en una máquina virtual así­, y el programador puede hacer cosas que no son invertibles, como llamar a funciones de la API de Java.

La consecuencia es que la única manera viable de implementar un undo es guardar el estado del juego cada vez que al jugador se le pida una entrada, tener almacenados los últimos estados y que el undo sea sencillamente restaurar el anterior. (lógicamente no serí­a necesario almacenar el estado en el disco duro pasándolo a formato XML, como cuando uno le da a "guardar" y "cargar"; pero como mí­nimo habrí­a que copiarlo todo en memoria).

Esto evidentemente tiene el inconveniente de que serí­a lento (no sé hasta qué punto porque no lo he probado; pero me imagino que como mí­nimo lo suficiente para notarlo a simple vista, salvo tal vez en juegos muy pequeños) y gastarí­a memoria. Pero, como dices, el undo es útil en el betatesting. Así­ que supongo que lo que podrí­a hacer serí­a añadirle al motor un modo "testing" o "debug", de manera que al poner ese modo las aventuras se ejecutarí­an más lento pero a cambio tendrí­as el undo. En el modo normal, se ejecutarí­an más rápido y no lo tendrí­as.

Por cierto, ¿las aventuras en Z dejan hacer undo cuando se juegan sin ser para testear, o hay una opción para deshabilitarlo? Porque jugar con undo es un sacrilegio, que te maten y hacer undo... pfa... :x

_________________
Actúa siempre de tal modo que las decisiones de tu voluntad pudiesen servir como preceptos de una legislación universal (E. Kant)


Arriba
 Perfil  
 
NotaPublicado: 17 Sep 2004 10:48 
Desconectado
xyzzy

Registrado: 09 Mar 2004 22:50
Mensajes: 9150
Al-Khwarizmi escribió:

Por cierto, ¿las aventuras en Z dejan hacer undo cuando se juegan sin ser para testear, o hay una opción para deshabilitarlo? Porque jugar con undo es un sacrilegio, que te maten y hacer undo... pfa... :x


Si, de hecho yo casi nunca le doy a reiniciar, salvo que se quede en un punto crí­tico en el que el número de turnos trancurridos desde una acción predeterminada no te impida dejar de morir una y otra vez. xDD
Lo del modo debug para AGE estarí­a bien. :)


Arriba
 Perfil  
 
Mostrar mensajes previos:  Ordenar por  
Nuevo tema Responder al tema  [ 10 mensajes ] 

Todos los horarios son UTC + 1 hora


¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 3 invitados


No puede abrir nuevos temas en este Foro
No puede responder a temas en este Foro
No puede editar sus mensajes en este Foro
No puede borrar sus mensajes en este Foro

Buscar:
Saltar a:  
Desarrollado por phpBB® Forum Software © phpBB Group
Traducción al español por Huan Manwë para phpBB-Es.COM