EPOPEIA Demosystem v1.2

enlar/rgba

Copyright Eneko Lacunza 2004. Se publica este documento al dominio público, permitiendo su copia, distribución y modificación libre.

1. El sistema de demos Epopeia

1.1. Objetivos

Los objetivos del sistema son los siguientes:

  1. Trasladar el trabajo del montaje de una demo desde los coders al diseñador de la demo.
  2. Ayudar en el proceso de pruebas y creación final de la demo.
  3. Aislar la demo lo máximo posible de la plataforma de ejecución.

La motivación principal para crear el sistema fue principalmente el 1º, aunque el 2º punto es muy interesante. La idea es conseguir que la creación de efectos e infraestructura para una demo sea lo más industrial posible.

Cuando se crea un efecto, éste pasa por diferentes estados, algunos de los cuales pueden ser:

  1. Ejecutable de prueba de concepto
  2. Parte de una demo en construcción
  3. Parte de una demo acabada
  4. Reutilización en otras demos

Las diferencias entre versiones o estados del mismo efecto pueden consistir en varios elementos:

Debemos tratar de simplificar y aislar los efectos de estos problemas, de forma que desde el primer estado de prueba de concepto, sea posible incorporar el efecto en cualquier estado de la cadena con el mínimo esfuerzo posible, donde idealmente el paso sea automático y exento de trabajo.

Por último, aislar los efectos y el montaje de la demo de la plataforma de ejecución permitirá que la demo se pueda portar fácilmente y que se pueda colaborar mejor entre el equipo de desarollo de las producciones, especialmente si en el equipo hay individuos que usan diferentes sistemas.

1.2. Diseñando y montando sin coders

El sueño de todo coder es tener algo para que los grafistas de su grupo puedan trasladar a la pantalla lo que tienen en mente sin que uno tenga que estar a su lado cambiando líneas de código y recompilando cada detalle.

Para esto hace falta un sistema con el que el diseñador pueda dirigir la demo de la manera más sencilla y potente posible.

La sencillez podría incluir elementos como que el diseñador no tenga que saber C, C++ o el lenguaje elegido para la programación de la demo; que no tenga que saber recompilar fuentes; que no necesite un entorno de desarrollo (ni compilador...) instalado; que el montaje se haga de forma gráfica; que se pueda añadir funcionalidad y efectos al sistema mediante plugins separados que los coders puedan preparar independientemente; etc.

Respecto a la potencia, los elementos a considerar son la posibilidad de extender el sistema sin cambiar (compilar) el núcleo, máxima sencillez para un mínimo de problemas, posibilidad infinita de amplización de efectos, capacidad de control total sobre la secuencia y montaje de partes de la demo, etc.

Las primeras decisiones a la hora de empezar a implementar Epopeia fueron las siguientes:

1.3. Creación de efectos == construcción de ladrillos

Para evitar errores y trabajo en el proceso de desarollo e inclusión final de efectos y otros elementos como motores 3D, es necesario que desde el principio consideremos estos efectos como unidades independientes, bloques con los que podemos construir demos, como si de ladrillos se tratara.

Para conseguir esto, el sistema de demos debe tener un sistema de plugins mediante el cual podamos enchufar los bloques al sistema para hacer la demo.

Al crear un efecto, lo creamos directamente como plugin y hacemos las pruebas mediante un script del demosystem mínimo que demuestre las posibilidades del efecto y permita comprobar fallos y corregirlos. Esto permite pulir el efecto, a la vez que podemos enseñarlo al resto del equipo de desarrollo y adicionalmente, estos pueden directamente irlo incorporando en la producción sin más esfuerzo que incluir el código script necesario para parametrizar cuando comienza, acaba, etc. y añadir el fichero de plugin.

De esta forma, ¡tenemos un efecto que, desde el primer momento de su creación, es posible incorporar a una producción sin compilar ni modificar ni una línea de código, ni necesita ninguna otra ayuda de un coder!

1.4. Aislando la plataforma del arte

Debemos aislar lo máximo posible el control del entorno de ejecución de lo que verdaramente es la demo. Para conseguirlo, debemos aislar lo mejor posible:

En nuestro caso, se opta por adoptar OpenGL como el sistema gráfico estándar, de forma que la inicialización del entorno de renderización corre a cargo del sistema de demos, y los efectos pintan usando comandos OpenGL. También hay infraestructura para usar framebuffer (apenas testeada o usada).

El sistema de sonido se aisla de forma que solo se indica el fichero de música y cuando empieza y acaba.

El sistema asimismo provee del timing necesario a los efectos de 2 formas diferentes, dependiendo de la necesidad de precisión y granularidad requerida para la sincronización y movimiento.

Por último, el sistema se encarga de gestionar las llamadas de interfaz de usuario (tecla ESC, teclas auxiliares para avance, etc. durante el montaje) de forma que los efectos no tienen que controlar nada. No queremos bucles while(!key_pressed()) nunca más! :)