Programando una demo desde una perspectiva ingenieril
Suena un poco pretencioso y quizá hasta repelente utilizar la expresión del título. Perspectiva ingenieril, le faltan dos suspiros para ponerse a hablar del colegio de informáticos... ¡pues no! No van por ahí los tiros. Hay una serie de errores clásicos al construir una demo. Todos hemos caído en ellos alguna vez, y muchos, repetidamente. Si aplicásemos un enfoque más ingenieril a la hora de llevar a cabo el proyecto, podríamos evitar muchos de esos errores. Éstos son los más comunes:
Emprender el proyecto sin planificarlo
¡Probablemente éste sea el error más típico! Todos hemos empezado una producción sin nada más que una vaga idea de lo que queremos obtener, sin layout ni bocetos ni música ni nada. Cada miembro del grupo se pone a hacer lo que cree que le corresponde, sobre la marcha, y cuando llega el momento decisivo, el de integración, los problemas se van multiplicando conforme se trata de añadir nuevos elementos. Ejemplo: en la euskal 10 se dijo de hacer una demo que sería el novamás, la Third Reality. Cada uno se puso a hacer efectos por libre, al llegar a la party más coders se apuntaron a la idea, y finalmente cuando empezaron a integrar código (el sábado por la mañana), las diferencias tan dispares entre plataformas (unos usaron linux y otros windows, otros un modelo de cámara diferente al de los demás...), la ausencia de elementos tan básicos como una interfaz para reproducir una canción (que no estaba acabada por no saber qué efectos habrían ...) y en general el agobio de ver que cada nueva adición provocara 20 errores más, hicieron que nunca se presentara la demo...El síndrome de la panacea
Este error clásico de la ingeniería del software es también muy típico en las demos. Consiste en, a mitad de desarrollo de una, averiguar que existe una forma de programar diferente, y decidir cambiar a esa forma inmediatamente, porque será mejor y más efectivo. Típicamente lo que suele ocurrir es que ese cambio hace perder un tiempo precioso en adaptarse a la nueva plataforma, y finalmente por no se puede acabar la demo. Ejemplo: durante el desarrollo de la demo be::q2 de necrostudios, a alguien se le ocurrió la idea de pasar el código de los efectos a dll’s. Como consecuencia, perdimos un día entero de demomaking corrigiendo errores para usar una tecnología que finalmente se desechó. Otro ejemplo podría ser el pasar de directX a opengl (o viceversa) sin la suficiente tranquilidad como para permitirse el lujo de adaptarse a la nueva plataforma sin morir de estrés.El cuento de la lechera
Esto tiene mucho que ver con el problema de falta de objetividad personal. Mucha gente se plantea metas demasiado altas, producto de la impaciencia. Por ejemplo, sin apenas dominar conceptos de geometría (puntos, rectas, trigonometría, transformaciones, etc) se lanzan a construir un ultra-super-mega motor 3D que tendrá vertex-shaders, sistemas de partículas, detección de colisiones y física en tiempo real y... ¡la lista es infinita!. Es una verdadera lástima que la gente no sea más humilde y capaz de autocensurar sus pretensiones –al menos, mientras no tenga la habilidad para materializarlas-, ya que habitualmente estos castillos en el aire acaban hundiendo en su caída al coder fantasioso, que típicamente opta por odiar para siempre a la scene y a su propia capacidad para programar. Simplemente por ponerse metas demasiado lejanas para el momento. Hay que elegir un camino progresivo, en el cual cada paso es un poco más complicado que el anterior. Pero no insuperable. Por cierto, este tipo de delirios de grandeza suelen venir acompañados de una prisa y una falta de tiempo impresionantes. Ejemplo: la nunca presentada third reality. Iba a tener niebla, metaballs, fuego, art2D, raytrace, blablabla, ¡y además duraba más de 10 minutos! Todo esto se tenía que hacer en un mes (con exámenes incluídos) y sin ningún código de base previo.Sin documentar
Suele ocurrir también que pensamos que con que entendamos el código nosotros ya vale. Lo que pasa es que vemos ese mismo código dos semanas después y a menos que sea un obvio printf, nos quedamos mirando la pantalla y pensamos: Hum... ¿Me abducieron? ¿He sido yo? Con lo que perdemos un tiempo hasta recordar cómo funcionaba aquello. Lo mismo ocurre si le tenemos que pasar el código a algún compañero de grupo para que nos eche un cable o para que trate de encontrar algún error que nosotros no somos capaces de dilucidar. Ejemplo: creo que no hace falta en este caso... todos hemos caído ;-)¡Probar es de tontos!
¿Cuántas veces se ha colgado una demo en la compomachine? ¿Y cuántas veces no funcionaba más que en el ordenador del coder? A menudo se desprecia la utilidad de las pruebas, sin pensar en que pueden sacar a la luz fallos realmente gordos que en otro caso quedarían ocultos o saldrían aleatoriamente en el momento más inesperado.Algunos ejemplos:
- Rutas de ficheros apuntando a directorios que sólo existen en el ordenador del coder (como c:\temp\misdemossonguays\dibujo.jpg).
- Librerías que no se incluyen en el zip de la demo (no incluir bass.dll o fmod.dll...) y aunque en el ordenador del coder están en c:\windows\, no tienen porqué estarlo en la compomachine.
- Enlazar librerías dinámicamente que no tienen por qué estar instaladas en la compomachine (por ejemplo, hubo una época en que ví muchos fallos de ausencia de MFC42D.DLL ... hasta que instalé el visual studio, que lo lleva).
- Probar sólo en tarjetas de la misma plataforma que el ordenador del coder: esto va por las diferencias entre ATI y Nvidia. Un ejemplo son las líneas que aparecen en los GL_QUADS en las demos Decadence de threepixels y Scene of the girls de ppg cuando se ejecutan con una ATI, pero que no aparecen con una Geforce.