¿Debería el arte preocuparse por el receptor de este? ¿Al hacerlo no estamos usando una herramienta del capitalismo más duro? ¿La mercadotecnia? ¿Debería un artista cerrar su proceso creativo y dejar que el público sólo esté en contacto con una obra finalizada? ¿Cuántas veces hemos escuchado historias de piezas que alejan al público de los recintos escénicos, museos, etc.? ¿El arte es un acto sensible o un acto de comunicación o ambas e incluso más?
Nos es necesario tomar una postura para hacer teatro relacional. Ese teatro de dispositivos donde se quiere transmitir una experiencia de participación donde el espectador se vuelve un actor más. Ahora, todo esto que acabamos de asentar nos vuelve a colocar en que la atención del público debe pensarse como un juego, reglas incluidas**. Y cuando miramos en cómo tratan al usuario los desarrolladores de juego, existe un proceso muy particular el cual, dependiendo del tipo de pieza, se vuelve importante o no existente en el modelo de producción de arte. Hablamos de presentar a público la pieza antes de estar terminada. En la estética relacional es impensable hacer esto, pero en el territorio hegemónico narrativo, por ejemplo, del mundo del teatro, no es muy común presentar la obra inacabada. ¿Acaso esto será un error? ¿Acaso no deberíamos preocuparnos por la experiencia que recibe la gente? ¿No debería estar incluida como compromiso social en cualquier tipo de arte?
Aproximadamente un año después del desarrollo de Portal (videojuego de plataforma y rompecabezas en primera persona), los testers (probadores de juego) empezaron a retroalimentar una situación muy particular. Los probadores, al ser entrevistados, comentaban algo como "ese fue un gran tutorial, no puedo esperar para jugar el juego real"***. He aquí un pequeño gran problema, lo que estaban probando era el juego real. A pesar de jugar alrededor de 14 acertijos hechos a mano, a los jugadores claramente les faltaba algún elemento vital que les dijera que esto era, de hecho, un videojuego terminado.
Y así, después de mucho diálogo y retroalimentación, la compañía que desarrollaba el juego de Portal, Valve decidió que el juego necesitaba un antagonista: alguien que hiciera retroceder al jugador, que lo motivara a seguir adelante y que pusiera estos acertijos en contexto. Decidieron que el sentimiento que tenía que desarrollarse era que el jugador estaría en un entrenamiento para derrotar a un jefe. El resultado final fue GLaDOS: una suprema inteligencia artificial con un ingenio mordaz, pasivo-agresivo y claramente en contra del jugador. GLaDOS se burla de ti durante el juego y te engaña. Todo el juego conduce a un enfrentamiento culminante uno contra uno en su cámara central. Y gracias a una escritura aguda y una actuación de voz asesina, se ha convertido en una de las villanas de videojuegos más icónicas de todos los tiempos.
Pero, dice Robin Walker de Valve, "su génesis comienza con un proceso sencillo en el que intentamos resolver el problema central del juego en Portal"****.
Seguramente se puede pensar que el personaje de GLaDOS nunca hubiera existido si no fuera por estos comentarios, este es sólo uno de los innumerables ejemplos muestra del valor de las pruebas de juego. Hay muchísimas historias de éxito de retroalimentación clave del proceso de creación de los videojuegos que incluso se vuelve un proceso estandarizado de la producción de videojuegos. Absolutamente cualquier compañía o equipo de trabajo que desarrolla un juego, mete dentro de su proceso creativo el de probar los dispositivos de juegos.
Ahora, este proceso de prueba no debe confundirse con el control de calidad que se usan para eliminar errores. O pruebas de enfoque que se hacen para la investigación de mercado. Cuando Valve se refiere a las pruebas de juego se refieren a aquellas pruebas que consisten simplemente en ver a las personas jugar durante una parte del juego, a veces pidiendo que llenen un cuestionario o haciendo una entrevista al final, y luego usar lo que ven y escuchan para impulsar cambios en el diseño del juego*****.
Valve usó pruebas de juego para asegurarse de que la curva de aprendizaje fuera perfecta. Usaron la retroalimentación para eliminar momentos de frustración. Usaron los comentarios y las reacciones para asegurarse de que los jugadores notaran los objetos clave o para mejorar el ritmo, ajustar la dificultad y para asegurar que la historia fuera coherente.
Las pruebas de juego incluso condujeron al estilo visual icónico del juego, con esas paredes y el suelo blancos estériles. Originalmente, el juego presentaba entornos abarrotados y sucios, pero a los testers les resultó difícil identificar los elementos clave del rompecabezas.
En una prueba, un jugador pasó media hora tratando de empujar un estante hacia un botón, mientras ignoraba por completo una caja cercana.
Kim Swift, uno de los desarrolladores clave del proyecto, dice que las pruebas de juego son "lo más importante que aprendimos desde que llegamos a Valve"+.
Así es como funciona en el método de trabajo de Valve. Empezar con un objetivo: por ejemplo, hacer un rompecabezas que sea claramente legible y suficientemente difícil para crear una satisfacción al resolverlo. Siguiente paso, intentar alcanzar ese objetivo, diseñando algo, en el ejemplo de Portal, una cámara de prueba, por decir algo. A continuación, se evalúa si el diseño alcanzó ese objetivo haciendo una prueba de juego. Y si no cumple con el grado, se cambia el diseño y se repite el proceso.
Valve continúa con este proceso iterativo hasta que "ya no es terriblemente doloroso ver las pruebas de juego", dice el desarrollador David Speyrer++. Quizás, dados los temas de sus juegos más famosos y los modelos de producción actuales de los videojuegos, es apropiado que Valve vea el desarrollo de juegos como un problema de ingeniería o un estudio científico.
El ex psicólogo interno de Valve, Mike Ambinder, dice que "vemos nuestros diseños de juegos como hipótesis y nuestras pruebas de juego como experimentos para validar estas hipótesis"+++. ¿No vale la pena tomar en cuenta este tipo de modelos de producción?
Debemos recordar que las pruebas de juego no son exclusivas de Valve. Debemos reiterar que todos los desarrolladores de juegos obtienen comentarios de los jugadores en algún momento del proceso (y también en algunos modelos de producción artísticos). Pero la diferencia es que Valve está obsesionado con él, hasta un grado, digamos, casi religioso. Ambinder llama a las pruebas de juego "la parte más importante del proceso de desarrollo del juego". Newell lo llama "nuestra arma secreta".
Valve hace pruebas de juego, inclusive, desde las etapas más tempranas de desarrollo. Swift y su equipo comenzaron a realizar pruebas de juego de Portal después de solo una semana de comenzar a desarrollar el juego en Valve, a pesar de que sólo tenían una sala a medio terminar para mostrarle a la gente. Y luego lo empezaron a implementar más a menudo.
Portal se probó prácticamente todas las semanas.
Hacían una prueba de juego el viernes, discutían los resultados el lunes, aplicaban las lecciones el resto de la semana y volvían a probar el viernes.
Hay varios tipos de prototipos, como: prototipos físicos o de papel, prototipos visuales, prototipos de digitales, etc. Un solo proyecto puede requerir varios prototipos diferentes, cada uno de los cuales aborda una pregunta o característica única.
La metodología que ha seguido ONIRISMOS, A.C., para crear las obras-juego (Play[s]) antes de presentarlas a público, es una prueba en tres etapas de prototipos:
PROTOTIPO DE PAPEL
Esta técnica de prototipado de baja fidelidad se basa en la utilización de materiales tan básicos como lápiz, el papel y las tijeras para la creación de prototipos simples, pero enormemente versátiles.
El objetivo de un prototipo de papel no es probar o verificar lo bonito que es el diseño, sino que se trata de verificar si los usuarios son capaces de realizar sus tareas con la interfaz propuesta. La utilización de esta técnica de prototipado no precisa incorporar avances tecnológicos; sólo es necesario que capture la funcionalidad del sistema y que comunique la información y sus interacciones adecuadamente.
Esta técnica de prototipado consiste en dibujar en un papel, sin entrar en grandes detalles estéticos, las interfaces que se van a probar y valorar. Los diferentes estados de la interfaz se van dibujando en hojas separadas y mediante un proceso de ordenación que el diseñador determina permite que el usuario final interactúe con este material simulando el funcionamiento del sistema.
En el proceso de 1569: El misterio, para revisar el avance y funcionamiento de los acertijos que se usarían, el equipo creativo hizo uso de este tipo de prototipado para entender el funcionamiento de los dispositivos. A partir de este punto, es más fácil entender la complejidad de lo propuesto, y ajustar dificultad de resolución.
Este tipo de prototipado no es extraño para el diseñador Alain Flores++++. Explicaba, en pláticas con estudiantes, que la forma de trabajo en la que desarrolla su trabajo es usar el bocetaje. Al final, el bocetaje es un prototipado de papel, para que se entienda de otro modo.
PROTOTIPADO ALPHA
El prototipado Alpha es la primera versión del producto a ser construido. No se pretende que sea completamente funcional. En su lugar, es principalmente usado para propósitos de prueba para ayudar a establecer la dirección de las futuras iteraciones eliminando características y aspectos de diseño inviables al principio del proceso. Aquellos elementos que sobreviven esta etapa se pasan a la siguiente, que por lo general se conoce como la etapa beta.
Trasladando el proceso de producción escénica, el prototipado Alpha funcionaría al presentar el dispositivo diseñado desde el papel, pero ya puesto en práctica con público. En el caso del proyecto de Amantes Anónimes, se presento frente al cuerpo del doctorado y en el veinte aniversario de ONIRISMOS, una serie de ejercicios con un breve contexto del universo de la obra.
Se presentaron dinámicas pensadas para la obra, pero sin mucha dramaturgia. Aún sin ahondar mucho en el contenido, la idea era encontrar la manera correcta de relacionarnos con el dispositivo, antes de escribir algún tipo de texto. Se pensó de manera muy general la contextualización de la situación para que también el usuario pudiera entender hacia dónde se quería llevar el proyecto y que desde esa premisa pudieran dar retroalimentación del proyecto.
PROTOTIPADO BETA
Una vez teniendo idea del dispositivo, una vez trabajado el guión se procede al siguiente nivel de prototipado. El Beta es una versión más o menos funcional del producto sobre la base de los descubrimientos y las decisiones tomadas durante la fase alfa. Sin embargo, en general, hay errores fijos y problemas de diseño aún por resolver en este punto en el proceso. Este prototipo se utiliza luego como base para las etapas finales de desarrollo.
En el caso del proyecto Abuela Fiera, como parte de la entrega de avances para Creadores Escénicos 2022, se elaboró un prototipado Beta. Ya habiendo trabajado con un texto de la dramaturga Estefanía Norato y grabando con las actrices Vania Belmont, Minah Cerviño, Elba Nallely Maros, que, con la asesoría de Paolina Orta, crearon un previo del proyecto en formato digital+++++.
Antes de cerrar este apartado es necesario comentar que la metodología no fue probar una vez el proyecto en cada etapa y listo, sino que fue necesaria de una presentación múltiple en cada etapa para poder recabar información suficiente para poder avanzar al siguiente paso. En ese sentido hay que regresar a ver el proceso de Valve para presentar las veces que sean necesarias y pulir el dispositivo como fue con el proyecto La fiesta.
Partamos sobre la premisa de presentar las veces que sea necesario el dispositivo ante distintos tipos de personas.
La devoción por probar juegos tiene mucho más sentido en el contexto de lo que sería el desastroso desarrollo del primer juego de Valve, Half-Life. Aproximadamente dos meses antes de que se suponía que Half-Life se publicara, Valve se dio cuenta de que el juego era injugable~.
El desarrollador dijo que no podías jugar el juego completo, ninguno de los niveles se unía bien y había serios problemas técnicos con la mayor parte del juego. En general, el juego simplemente no estaba funcionando.
La única opción real sobre la mesa era desechar todo y empezar de cero. Pero esta vez, harían las cosas de manera diferente, lo que lleva a dos filosofías de desarrollo de juegos que todavía están presentes en el estudio hoy en día.
1. Las cuadrillas.
Las cuadrillas son donde el personal se divide en pequeños equipos multidisciplinarios, cada uno de los cuales se hace cargo de una pequeña parte del juego~~ (Esto será importante también en los modos de producción).
2. Pruebas de juego.
La otra estrategia son las pruebas de juego frecuente, desde el punto más temprano de desarrollo.
Esta vez, si el dispositivo no funcionaba, querían saberlo de inmediato.
Entonces, aproximadamente tres meses después del desarrollo del Half-Life reiniciado, comenzaron las pruebas de juego. Encontraron jugadores al azar en tiendas de videojuegos o de viejos registros de usuarios de computadoras. Los sentaban frente al juego y solo los miraban jugar.
Cada prueba daría como resultado docenas de cosas que debían corregirse, cambiarse, agregarse o eliminarse del juego. Y este nuevo proceso funcionó: esta versión de Half-Life fue un gran éxito, ahora es visto como uno de los juegos más importantes e influyentes jamás creados. Valve usaría ampliamente las pruebas de juego en todos sus juegos futuros.
Por nuestra parte, esta misma metodología de producción se implementó en el proyecto de La Fiesta (montaje que se produjo para presentarse en el marco del Festival Internacional de Teatro Universitario en Teatro Santa Catarina, UNAM en septiembre de 2019).
La Fiesta tiene como motor principal un juego, a su vez, basado en Lobos de Castronegro. Diseñado por Philippe des Pallières, Lobos es un juego de roles ocultos en el que los jugadores se dividen en dos equipos. Lobes y aldeanes. Les aldeanes desconocen quienes son sus compañeros y en cada ronda, a través de un debate deben decidir qué jugador se eliminará para lograr acabar con los lobes, esto se repite hasta que se eliminan a todes les lobes o les aldeanes son diezmados.
En la obra La Fiesta, seis mejores amigues se han reunido para celebrar un convivio que demuestre su amistad. Sólo que se han invitado a más personas (el público), porque la verdadera razón por la cual se reúnen y que termina fracturando la amistad, es hacer de la fiesta un juicio. Dentro de la ficción de la obra, la semana pasada une de elles cometió una agresión sexual durante otra reunión nocturna.
El público, entonces, deberá entrevistar a les involucrades para lograr desenmascarar quién, de les seis, es el culpable.
La dificultad aumenta ya que cada función se elige al azar al o les culpables.
Para poder hacer ese proyecto, les intérpretes desarrollaron y estudiaron a fondo la situación de los personajes. Y disciplinariamente, cada semana probábamos el dispositivo frente a gente. Por más que quisiéramos imaginar qué podría preguntar el público o cómo reaccionarían, nada nos preparaba mejor que testear el dispositivo frente a gente que no conocía el proyecto.
Incluso este proceso de revisar semanalmente el dispositivo nos ayudaba a asegurar que nuestra historia se ligara lo más coherentemente posible. La retroalimentación al final del dispositivo nos ayudaba a detectar problemas de lógica o de continuidad y de ritmo.
En alguna sesión nos agarraron desprevenidos preguntando por el número de la víctima, a partir de ese día tuvimos que decidir que la víctima estaba fuera de comunicación para no tener que depender de que la gente esperara que contestara llamadas o que entrara ese personaje ausente.
El probar el dispositivo continuamente nos ayudó a redondear ese proyecto para las presentaciones que se aproximaban.
Al igual que Valve, hay mucha información que se desprende del testeo. En Portal 2, se descartó un tipo de pintura que te permitía caminar sobre las paredes, cuando hizo que varios probadores se sintieran mareados. Para probar una nueva tecnología con la realidad virtual, en Half-Life: Alyx, Valve aprendió que la tolerancia de un jugador para estar parado mirando a la gente hablar era significativamente menor en la realidad virtual, por lo que tuvo que acelerar el ritmo del juego.
El comportamiento de los jugadores nos ayudó a navegar el desarrollo de la realidad virtual, dice Christine Phelan de Valve. Y aquí viene uno de los descubrimientos más importantes de abrir el procedimiento de producción: Casi podrías pensar en el jugador como un diseñador más. Apenas hay un momento en el juego que no haya sido mejorado por lo que los probadores nos dijeron y nos mostraron a través de su comportamiento de juego. Entonces, desde Half-Life 1 hasta Half-Life: Alyx, las pruebas de juego han sido una herramienta invaluable para Valve~~~.
Es este procedimiento que nos regresa también por el lado del Teatro Político. Considerar al público como un miembro importante del desarrollo de la pieza. Revisar nuestra relación de poder con el receptor de la obra. Darle la importancia y el tiempo necesario para desarrollar los proyectos relacionales.
Al final, podemos tomar pequeñas metodologías del mundo de producción de los juegos para aplicarla a nuestras propuestas relacionales.
La primera metodología es probar el proyecto desde etapas tempranas.
Valve dice que las pruebas de juego son donde hacemos la gran mayoría de los cambios más importantes en nuestro juego. Por lo tanto, tratamos de hacerlo lo antes posible en el proyecto, para obtener el máximo valor de él~~~~.
Cuando se identifica un problema desde el principio, se tiene tiempo para volver a la mesa de dibujo y desarrollar una solución efectiva para el problema. Pero al hacerlo demasiado tarde puede afectar la recepción final de la obra.
La segunda metodología sería: probar a menudo (en la medida de lo posible).
Por lo general, Valve realiza pruebas todas las semanas, para asegurarse de que están iterando constantemente sobre los comentarios de los jugadores. Esto también conduce a una gran cantidad de datos. Al tener un gran número de personas mirando el juego, Valve puede buscar tendencias comunes en los comentarios y evitar modificar el juego en función de algunos valores atípicos extraños. Cuanta más experiencia tenga al ver a las personas interactuar con sus diseños, mejor podrá adelantarse a esta retroalimentación en el futuro.
La tercera metodología sería: cállate y mira.
Una prueba de juego debe tratar de simular la experiencia real de jugar el juego. Lo que significa que los observadores deben permanecer en silencio durante la prueba: sin pistas, sin orientación, sin respuestas a preguntas candentes.
Este tipo de ejercicios era muy común desarrollarlos en clases de dirección escénica. Les docentes pedían dirigir una escena con ciertas características. Se agendaban presentaciones en clase. Se presentaban las escenas y después se recibía la retroalimentación. Muchas veces, docentes como Artús Chávez o Rubén Ortiz, particularmente eran muy claros que, en el momento de recibir comentarios, primero debían escuchar los expositores a la retroalimentación. Ya después uno podía hablar, si quería o quedaba honor para hacerlo.
Las entrevistas y los cuestionarios posteriores al juego que aplicaba Valve ciertamente pueden ocurrir, después de la prueba, pero a menudo obtenían más observando a los jugadores que hablando con ellos. Observando su lenguaje corporal, también, sus respuestas.
Sin embargo, quizás la metodología más importante es que los comentarios de las pruebas de juego son solo datos, y depende del diseñador cómo se interpretan, filtran y aplican esos datos.
Es importante desarrollar criterio suficiente para saber aprender de la retroalimentación cuidando de adaptar la propuesta a los caprichos y deseos de todos los probadores de juego que aparezcan en el proyecto. Al final se puede correr el peligro de terminar con un juego simplificado. Habrá que ver los datos con un objetivo claro. Un dispositivo específico que se quiera hacer, para una audiencia específica. Una experiencia determinada. Un sentimiento, etcétera. Usar las pruebas como medios de comprobar la tesis del proyecto relacional.
Por lo tanto, es crucial que todo el equipo que vaya a desarrollar el proyecto esté acostumbrado a recibir retroalimentación, tener claros los objetivos y tener un pensamiento crítico aplicado a la actividad para trabajar y aportar ideas necesarias para el funcionamiento del dispositivo.
No estamos solos construyendo un juego, necesitamos del otre.
*
+
++