2015-01-22 Los juegos no se hacen solos. Es necesaria mano de obra dispuesta a pasar de ideas sin valor a productos lucrativos y para llegar a este punto hacen falta herramientas. Herramientas que nos permitan modelar, hacer texturas, iluminar… prácticamente todo. Si el desarrollador tiene una grúa y no una burra tirando de un cargado carro, será más eficiente desarrollando. De ahí la importancia de conseguir la herramienta que mejor se adapte a nuestras necesidades, pues el estamento anterior es falso si lo que queremos es transportar unas cebollas al pueblo de al lado. ¿Para qué una grúa? En términos absolutos el progreso real de la industria se puede medir en la eficiencia de las herramientas que produce. Siempre que aparece algún tipo de software o proceso que reduzca el tiempo necesario para hacer lo mismo que se hacía antes, se consigue que el desarrollador pueda invertir todo ese tiempo extra (respecto al pasado) en experimentar (y por tanto crear nuevas herramientas derivadas de ello con un poco de suerte) o invertirlo en partes creativas del desarrollo. Win to win.
En este proceso en busca de la eficiencia (como la inversión que se tiene que hacer para desarrollar un videojuego es 80% o más en salarios, el tiempo es oro) para obtener desarrollos más baratos pero igual de eficientes, toma el punto de partida simbólico en los game engines. No son juegos ni son lenguajes de programación, sino que son un nexo para facilitar hacer juegos mediante lenguajes de programación básicos. O al menos eso es lo que eran.
Todas las grandes compañías de la industria se han puesto más o menos de acuerdo en un tema candente; el trabajo del programador es cada vez más hacer herramientas para los artistas y diseñadores más que crear el funcionamiento de los juegos. Y en estos términos la programación visual es la piedra sobre la que gira el concepto.
¿Qué es la programación visual?
La programación visual es programar sin tener que picar código, cosa que no significa programar sin saber programar. Mediante una interfaz gráfica nos pasaremos el día uniendo cajitas mediante flechitas para crear… juegos enteros. Por ejemplo, podemos crear una cajita que se active cuando el jugador se acerque a una puerta en el escenario y cuando se active, crear una flecha que va a transportar la información de esta cajita (que se disparará cada vez que el jugador se acerque a la puerta) y decirle a la puerta mediante otra cajita que se mueva durante 3 segundos 70 cm a la derecha. Dos cajitas y una flecha. Así hemos creado una puerta automática.
Sin embargo, quedarse con que la programación visual se usa única y exclusivamente para crear eventos dentro del escenario es quedarse corto. Desde que en Unreal Engine 3, Epic Games sacudió todo el tablero de juego creando el editor de materiales por nodos y posteriormente con Kismet (el predecesor de los blueprints en Unreal Engine 4), cada vez son más los engines que se decantan por ofrecer módulos de programación visual robustos y potentes.
En mi experiencia personal, y para que sirva de ejemplo, programé MIND: Path to Thalamus al 100% con programación visual. Esto incluye el tornado del principio, el gigante, los cambios climáticos, avanzar y retroceder en el tiempo, el sonido, los logros, el boss final… todo. Todo menos el menú (que es al 80% programación visual y 20% construido en Adobe Flash) y el poder agarrar y dejar las esferas. Esto era tan específico y único que para ser eficiente (dedicándole meses seguro que lo podría haber hecho yo pero no me podía permitir invertir tanto tirmpo en ese aspecto) decidí contratar a José Ladislao para que lo resolviera. Al ser algo tan intrínseco del juego y además tener la imposibilidad de crear clases mediante programación visual en Unreal Engine 3, era necesario resolverlo mediante “programación tradicional”: picando código. Ladis realizó un trabajo excelente, le pagué por ello y fin de la historia. O no.
Como Epic Games ha decidido dejar de dar soporte a la realidad virtual para UE3, no me queda más remedio que pasar todo el juego a Unreal Engine 4. Todo el juego. Y como además Unreal Engine 4 ha sido reescrito desde zero, no existe botón mágico de exportar > importar. Hay que volver a construirlo todo. Personalmente, si hay algo que me ha sorprendido de Unreal Engine 4 es su sistema de blueprints. Es como kismet de UE4 pero esta vez si que se pueden crear clases (incluyendo controladores de jugador y modos de juego) mediante los blueprints. Para mi propio asombro, en 6 horas de trabajo no solo había reecho el sistema de Ladis, sino que le había incluido unas cuantas mejoras pensando en futuros proyectos. Por supuesto esto no significa que Ladis sea mal programador, todo lo contrario. Algo que yo era incapaz de hacer, él lo supo resolver y sin embargo, para hacer lo mismo en Unreal Engine 4 no necesité ayuda de nadie (sin contar a San Google).
Lo realmente fascinante de la programación visual es que tienes que saber programar para poder utilizarla. Es decir, si no sabes de vectores, no podrás detectar hacia donde está mirando el jugador y hacer algo con esa información. Uses programación tradicional o gráfica. Quizás a los diseñadores simplemente nos resulta más cómodo leer la información de la programación visual porque podemos ver el flujo de la información y lo tenemos ordenado en un esquema visual comprensible. Una cascada de texto coloreado resulta mucho menos inteligible para mí.
Como en todo, la programación visual es una herramienta y aunque nos haga ser más eficientes todo tiene un precio. Por ejemplo, los Blueprints de Unreal Engine 4 son 10 veces más lentos que programar directamente en C++ lo mismo. Sin embargo, Unrealscript, el lenguaje de programación tradicional de UnrealEngine 3 también era 10 veces más lento. En todo caso, si lo que el desarrollador busca es eficiencia máxima ajustando los recursos al Bit, la programación visual no es la solución pero, ¿en cuantos proyectos esto es indispensable?
Inicio › Foros › La programación gráfica o cómo programar sin programar
Debes estar registrado para responder a este debate.