El año pasado 2018, se lanzó en Estonia una serie de producción teatral llamada Tale of the Century. A lo largo del año, 22 teatros locales presentaron al público sus interpretaciones de los últimos cien años de la historia de Estonia. En el sorteo, al Teatro Ruso se le asignó el tema del futuro de Estonia.
Cada uno de nosotros tiene sus propias ideas sobre cómo sería el futuro: a qué le tememos y con qué soñamos. Sin embargo, no queríamos crear una obra que simplemente le dijera a la audiencia cómo el estrecho círculo de personas en el teatro ve el futuro. Es por eso que planteamos esta pregunta a las personas que realmente van a vivir en el futuro, es decir, los niños y jóvenes de Estonia, de 3 a 19 años. Recibimos respuestas tanto en ruso como en estonio de ciudades y pueblos en todos los rincones del país. Hubo cientos de ellos y estamos extremadamente agradecidos por todos ellos.
Cada respuesta que recibimos fue única, pero al revisar los materiales recopilados, notamos algunas tendencias y patrones claros. Una gran cantidad de mundos futuros posibles, tanto atractivos como horribles, tomaron forma a partir de las respuestas de los niños. Sin embargo, hay algo que une estos mundos.
La historia nos lleva al año 2118. Estonia está bajo una cúpula protectora. Hemos aprendido mucho, incluso cómo extender la vida humana. Los personajes principales son una pareja de ancianos llamada Linda y Timo. Hace cien años, cuando eran niños, tenían fantasías sobre el futuro en el que ahora viven. De hecho, son los mismos niños que ayudaron a crear esta obra. Durante la obra, estos personajes se lanzan a diferentes versiones de Estonia en el año 2118 en función de cómo vota la audiencia.
Por supuesto, el rendimiento no comienza cuando sube el telón, sino mucho antes. Después de procesar todas las respuestas, identificamos los principales caminos posibles para el futuro según los niños, desde el estado tecnológico hasta el ecológico. Dado que el futuro no está predefinido, sino que depende de las elecciones que hagamos todos, los posibles caminos para el futuro se dividieron en historias cortas vinculadas por la historia general de los personajes principales y sus familias.
El diseño del escenario se asemeja a un juguete de construcción que puede tomar cualquier forma y realizar cualquier función en manos de los niños. También tiene la forma de un gráfico, un objeto matemático abstracto especial que nos permite describir y modelar muchos fenómenos del mundo real, como las redes viales, los modelos organizativos de las empresas, Internet o la variedad de elecciones que las personas hacen, elecciones que pueden convertirse en diferentes tramas.
Cuando se representa en un gráfico, los posibles desarrollos de la trama forman una estructura compleja y de múltiples ramificaciones.
La utopía a menudo conduce a la distopía y el camino al infierno está pavimentado con buenas intenciones. Las escenas están unidas por la lógica de la dramaturgia. Teniendo en cuenta todas las opciones posibles para el futuro inspiradas en las fantasías de los niños, tuvimos muchas historias. Era muy importante no repetir ninguno de ellos durante una actuación. Por ejemplo, si la audiencia vota por una utopía, esto conducirá a una distopía, o si la audiencia rechaza la utopía, deben hacer otra elección. Hemos tenido situaciones en las que los votos se han dividido casi por igual y la decisión final ha dependido de 2-3 votos.
Además de la tarea dramatúrgica, hubo muchos otros desafíos técnicos: los sofisticados sistemas de control que manejan cientos de LED en el escenario, los trajes creados ingeniosamente para cada versión del futuro por una de las mejores diseñadoras de teatro estonias Rosita Raud (esto es un desafío principalmente para los actores que tienen que cambiarse de ropa rápidamente cuando finaliza la votación) y, por supuesto, el sistema de votación que impulsa la historia y se basa en un modelo gráfico. Esto es lo que me gustaría contarles con más detalle.
Toda la música fue tocada en vivo por
MODULSHTEIN
Para que sea más fácil de entender, ingresemos una presentación
Estamos en la historia multicultural. Todos los idiomas y géneros se mezclan. Todo es aceptado El segmento de rendimiento comienza con un boletín de noticias que explica el contexto de la siguiente escena a la audiencia en una mezcla de 5 idiomas.
Irónicamente, Jelena Solomina es una verdadera presentadora de televisión nacional y una figura pública muy conocida.
En el futuro multicultural, todo es divertido. Semenova jr. Organiza una reunión con sus padres, donde presenta a su novio, que usa una mezcla de ropa árabe y de ballet. Después de las presentaciones, todos van a una fiesta
Al final de la escena, se abre la votación. La pregunta principal es si Estonia irá por este camino o no. Y si es así ...
La utopía se convertirá en una distopía. Se acortan todas las libertades y se introducen nuevas restricciones. De repente, las fuerzas especiales cierran el partido y clasifican a las personas en grupos. Algunas personas son bienvenidas y van hacia la derecha hacia el futuro brillante, mientras que otras tienen que quitarse la ropa y dirigirse hacia la izquierda hacia la máquina de ejecución.
La solución técnica
Estos son los requisitos que establecemos para nuestro sistema:
- El sistema debe recolectar votos, mostrar los resultados en tiempo real y tomar decisiones al respecto.
- El sistema debe seleccionar líneas argumentales en función de los resultados de la votación, abrir nuevos votos y cambiar entre líneas argumentales.
- El sistema debe comunicarse con la audiencia utilizando lenguaje natural.
- El sistema debe ser administrado por el subdirector detrás de escena, con estadísticas completas sobre los estados en curso y los votos.
De hecho, este era otro actor llamado EMA ("Madre" en estonio), una inteligencia artificial que se ha convertido en una realidad en el futuro. EMA dirige a la audiencia a través de la trama, manifestándose en las diferentes versiones del futuro. También inicia la votación, cuenta y presenta los resultados, y mueve la jugada a lo largo de la trama en función de los resultados de la votación. Toda la EMA se escribió desde cero en los 1,5 meses anteriores al estreno. Dado que las tramas, varias personalizaciones y las transiciones de gráficos evolucionaban constantemente a medida que la obra tomaba forma de acuerdo con las decisiones del equipo de guionistas y el director, no fue posible comenzar con el desarrollo antes.
El auditorio podía albergar a 600 personas, por lo que las personas debían poder votar usando sus teléfonos y nosotros necesitábamos poder recibir y procesar todos estos votos en menos de un minuto. La opción de desarrollar una aplicación móvil se descartó de inmediato, porque descargar e instalar una aplicación requiere un esfuerzo adicional: nadie descargará su aplicación si no es Facebook o Google. Además, admitir diferentes tipos y modelos de teléfonos habría requerido un desarrollo separado, lo que no era realista, ya que solo teníamos 1,5 meses y un desarrollador. Además, el cliente móvil habría tenido que estar en dos idiomas: estonio y ruso. Por lo tanto, necesitábamos una aplicación web optimizada para teléfonos móviles.
Se necesitaba otra aplicación web como backend administrativo para controlar el sistema: iniciar / detener, activar rondas de votación, monitorear el estado de la votación en curso, etc.
Y en tercer lugar, y lo más importante, necesitábamos coordinar la interacción de EMA con la audiencia.
Aquí, es necesario presentar el concepto de "super", algo que era nuevo para mí. El "super" es la cortina delantera que baja y oculta el escenario. Es reflexivo y le permite mostrar varias proyecciones, como comunicados de prensa (a los que volveremos más adelante) o la pantalla EMA que muestra información sobre los resultados de la votación y las elecciones realizadas por el público.
Así que tenemos un gráfico complejo, un sistema de votación y tres sistemas frontend, que deben interactuar con los espectadores y el administrador (Svetlana Shushina, una increíble asistente de dirección).
Graph
Comencemos con el gráfico. La estructura de datos, en este caso, las diferentes versiones del futuro de Estonia y las posibles transiciones entre las escenas según los resultados de la votación, tuvieron que almacenarse en algún lugar. Las bases de datos relacionales estándar no son adecuadas para almacenar datos de gráficos por varias razones. Para nosotros, los requisitos esenciales fueron el almacenamiento flexible de datos, el almacenamiento de transiciones de estado, enlaces a archivos de audio según el estado actual, y así sucesivamente.
La elección obvia fue Neo4j, el software de gestión de bases de datos de gráficos líder en el mundo. Siete de las diez principales compañías tecnológicas del mundo lo utilizan. Ofrece tecnología madura, velocidad, conveniencia y una excelente comunidad, que realmente no deja otra opción para este tipo de soluciones.
Modelamos los escenarios construidos por los guionistas como un gráfico en Neo4j. Aquí hay un ejemplo de cómo se ven los giros y vueltas de la trama desde dentro de Neo4j.
Al ser un sistema nativo para la representación gráfica, las ventajas que ofrece Neo4j son la flexibilidad y la ausencia de una estructura fija. Esto facilitó el cambio y la conexión de líneas argumentales y la adición de nuevas versiones de audio.
Backend
Al elegir la tecnología para el lado del servidor, dudamos entre Python y Java. Eventualmente, elegimos Java debido a su velocidad y confiabilidad a la vez que tenía requisitos claros, y también debido a Spring Boot, que admite Neo4j de fábrica.
El lado del servidor se implementó en Spring Boot. El servidor recopila votos, cambia de "super" a los siguientes estados cuando finaliza la votación, acepta comandos del administrador, proporciona estadísticas, etc. También maneja el registro de usuarios y envía datos de votación (la apertura o cierre de una votación y las opciones disponibles) a los clientes frontend.
Luego llegamos a la parte más notable de la tarea. La idea general era que el componente que se muestra en el "super" - EMA - tenía que poder hablar con la audiencia. Tenía que preparar a la audiencia para votar, anunciar las opciones de votación, iniciar y finalizar la votación, anunciar los resultados y, según la elección de la audiencia, sugerir las opciones para la próxima votación o dar una introducción para la próxima escena. Esto significaba que el audio tenía que ser dinámico y estar preparado sobre la marcha. Teniendo en cuenta que la cantidad de opciones es enorme, la duración de cada archivo de audio es diferente y la sincronización es importante (por ejemplo, la votación debe abrirse solo después del anuncio "¡La votación está abierta!"). Esta no fue una tarea trivial.
Entonces el sistema terminó teniendo dos centros de control.
El primero es el servidor : almacena el estado actual de la trama, proporciona estadísticas, maneja el registro de usuarios, recolecta votos y se asegura de que cada persona pueda dar solo un voto.
El segundo es el "super" , que comienza y finaliza la votación, muestra el progreso y los resultados de la votación, y así sucesivamente.
Frontend
El "super" se implementó en Vue.js. Inicialmente, el plan era construir dinámicamente el audio usando la API de Google Speech, pero no podíamos garantizar que no hubiera latencia de red. Por lo tanto, se eligió otra opción y grabamos los archivos de audio individualmente usando Google Speech.
En total, tuvimos 55 clips de audio. Los datos sobre qué archivos de audio deben reproducirse en qué estado se almacenaron en el gráfico junto con los estados. Como estábamos lidiando con JavaScript, colgamos los archivos de audio y ordenamos las llamadas una encima de la otra como si fueran uvas. Por lo tanto, no dependimos del hecho de que los archivos de audio tenían varias longitudes y terminaron con una solución bastante universal.
Inicialmente, el sitio web del cliente móvil se escribió en VueJS, pero en las pruebas nos dimos cuenta de que había un problema de incompatibilidad que afectaba a algunos modelos de teléfonos móviles. Intentamos resolver el problema con los transpiladores de Babel, pero a medida que se agregaron varias configuraciones, el volumen de la página creció, y aunque la aplicación web comenzó a funcionar en algunos teléfonos, se rompió en otros. Finalmente, el cliente móvil fue reescrito en Vanilla JS. Como resultado, terminamos con un sistema distribuido.
El volumen final del sistema (el archivo JAR) fue de 146 megabytes. La empresa de telecomunicaciones Telia nos proporcionó un servidor virtual al precio simbólico de 1 euro por mes, por lo cual estamos muy agradecidos y con una calidad de servicio increíble.
La primera prueba en vivo fue en la oficina de Playtech, que resultó ser bastante divertida.
El ritmo de trabajo se aceleró antes del estreno. Las expectativas se elevaron aún más por el hecho de que el presidente de Estonia iba a asistir al estreno. Se detectó un último error media hora antes del estreno y no hubo tiempo para probar la solución, por lo que durante las primeras actuaciones, la prueba del comportamiento del sistema en caso de todas las posibles tramas futuras se realizó en paralelo en la máquina local del desarrollador detrás del escenas, de modo que sería posible preparar un plan de acción por adelantado si surgiera algún problema.
Hay un hecho interesante que me gustaría destacar. Mostramos los nombres de las personas que votaron en tiempo real en la pantalla de votación en la cortina delantera. Usamos la plantilla de animación de Vue para esto, y durante la primera presentación, alguien en la audiencia ingresó un "símbolo asesino" como su nombre al registrarse, lo que rompió la animación y la visualización de las plantillas de Vue. Posteriormente, abandonamos esta solución (que muestra nombres en transiciones animadas) y cambiamos a jQuery. VueJS se usa solo para "super" para plantillas, administración de audio y estados de conmutación.
La actuación recibió muchas críticas positivas en la prensa. Algunos de ellos:
Estonio:
https://kultuur.postimees.ee/6402024/millised-me-eestlased-olemehttps://www.ohtuleht.ee/893816/mari-lill-uks-asi-on-raakida-vene-keelt-tanaval-hoopis-teine-asi-teha-seda-teatrilaval-Ruso:
https://rus.postimees.ee/6147704/nashe-zavtra-v-zerkalah-utopii-i-antiutopiihttps://rus.postimees.ee/6141942/budet-ne-budet-net-nichego-opasnee-budushchegohttps://rus.err.ee/859086/russkij-teatr-pokazhet-spektakl-budet-ne-budet-na-festivale-draama-v-tartuhttps://m.ee.sputniknews.ru/culture/20180826/12340797/otkrytije-sezon-russkij-teatr-teatraljnoje-sobytije-god.html?mobile_return=noEn el Festival de Drama en Tartu, la ovación de pie duró casi 5 minutos.
Fue una aventura increíble debido a la energía loca y la dedicación de las personas involucradas en el proyecto. Me quito el sombrero ante todas las personas que participaron en la creación de esta obra.
Director - Artjom Gareev
Compositor, Productor– Aleksandr Zedeljov
Visual - Aljona Movko
Disfraces: Rosita Raud
Luces - Anton Andrejuk
Coreografía - Olga Privis
Dramaturgo: Karin Lamson, Mari-Liis Lill, Jelena Chicherina, Laura Kalle
Video - Nikolay Alhazov
Programación y solución de TI: Aleksandr Tavgen, Anna Agafonova
Luces LED - Aleksander Sprohgis
Animaciones - Martin Yakush
Música - Modulshtein
Marten Altrov - Clarinete, clarinete bajo
Aleksej Semenihhin– Muestras, efectos de sonido
Aleksandr Zedeljov: guitarra, sintetizadores, ableton
Voces: Anna Dydyna
Asistente de dirección Svetlana Shushina
Actores:
Natalja Dymchenko, Aleksandr Zhilenko, Daniil Zandberg, Dmitrij Kordas, Ekaterina Kordas, Aleksandr Kuchmezov, Viktor Marvin, Natalja Murina, Jelena Tarassenko, Eduard Tee
Sergej Furmanjuk, Leonid Shevcov, Jelena Jakovleva
Estudio de teatro ruso: Deniss Volkov, Polina Grinjova, Nina Zagvozdkina, Anastassija Koleda, Natasha Kristensen, Anastassija Masalova, Sandra Minosjan, Sofia Mihaljova, Katrin Mägi, Mihhail Pashuk, Katrin Seljugina, Kristina Sorokgt, Sofia
Escritor de tecnología - Sigrid Maasen