¿Olvidates tu contraseña?

La programación visual o cómo programar sin programar

2015-01-22
4 comentarios

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.

programacion-grafica-branch-blueprint-unrealengine4-ue4-developers-videojuegos-fallofzehngames

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?

programacion-grafica-branch-blueprint-unrealengine4-ue4-trace-physdevelopers-videojuegos-zehngames

Imagen de perfil de Carlos Coronado

Carlos Coronado

107 entradas como autor
Desarrollador de videojuegos por elección, jugón por pasión. Mi curiosidad por jugar a videjuegos y sobretodo intentar entender porque los videojuegos me gustaban tanto me ha llevado a enfocar mi vida a intentar desarrollar esas mecánicas que nos absorben a todos. Me obsesiona la magía, los detalles, los matices, los buenos guiones y textos, los pequeños momentos del día a día y Warren Spector.

Etiquetas:

, , , , , , , , , ,

Inicio Foros La programación gráfica o cómo programar sin programar

  • Imagen de perfil de Carlos CoronadoCarlos Coronado
    Jefe de claves
    #60755

    Nunca ha sido tan lógico y simple desarrollar comportamientos en videojuegos. Blueprints y UE 4

    Lee el artículo completo en http://www.zehngames.com/developers/la-programacion-grafica-o-como-programar-sin-programar/

    Imagen de perfil de jggjgg
    Participante
    #60756

    Antes de nada, y sin ánimo de ofender ni sonar demasiado pedante, creo que utilizar programación gráfica aquí es un error cuando a lo que nos referimos realmente es a la programación visual. Sé que es una sutileza, pero esa sutileza es lo que diferencia el programar la parte gráfica de una aplicación o videojuego del uso de nodos o ‘cajitas’ y sus conexiones para programar.

    Y después de este comentario que me valdrá el odio de Carlos xD, yo soy un absoluto fan de la programación visual desde que utilicé Kismet de UDK durante el desarrollo de Project Silcharde hace unos años. De hecho, en la Game Jam del año 2013 mi reto personal fue hacer el prototipo con Kismet sin picar una línea de código. Y CASI lo consigo. Beat Hunter estaba hecho todo con Kismet, excepto por 100 líneas de código, las cuales necesité para crear 3 nuevos nodos que, o bien Kismet no ofrecía o no me dió tiempo a encontrar o utilizar bien (la presión de una jam a veces nubla xD). Realmente, se puede hacer un juego con programación visual tal y como dice Carlos y ha demostrado con Mind. Obviamente todo depende de la complejidad del diseño que tengas en mente para el juego, pero para eso también se ofrece la posibilidad de crear nuevos nodos, y parece que con los Blueprints de UE4 eso se ha mejorado mucho.

    Imagen de perfil de Carlos CoronadoCarlos Coronado
    Jefe de claves
    #60764

    Oh, jgg no tengo ningún problema en reconocer los errores léxicos que suelo tener. En resumen formamos parte de una industria que bebe el 100% de su terminología del inglés y me suelo colar muchas mucha veces así que acepto tu corrección al 100%. Voy a cambiar programación gráfica por programación visual 😉

    Muy buena pinta el Beat Hunter. A mi también me pasó con MIND que no me quedó más remedio llegado cierto punto que crearme nuevos nodos pero por suerte con los blueprints de UE4 esto ya no es necesario. Ahora todo es mucho más automático y a mucho menos bajo nivel 🙂

    Imagen de perfil de Ñuño MartínezÑuño Martínez
    Participante
    #60994

    Me ha gustado que dejaras claro que para programar visualmente (te me adelantaste, jgg) hay que saber programar. Estoy cansado de los articulillos estilo Yahoo! de “Programar sin saber programar” que engañan a la gente. Así claro, más de la mitad de los juegos que hay en Android son el mismo juego con gráficos diferentes…

    Ahora le estoy echando un vistazo a Multimedia Fusion de Clickteam, que también es visual, y si no fuera por mi experiencia anterior en programación me costaría mucho más hacer nada.

    Imagen de perfil de DanielDaniel
    Participante
    #61353

    Blender 3D, también permite programar visualmente, con su sistema de logic bricks

Viendo 5 publicaciones - del 1 al 5 (de un total de 5)

Debes estar registrado para responder a este debate.