Eficiencia del Software contra Eficiencia de Desarrollo

–¿Cual es más importante?–

Hace meses escribí una serie de 10 entradas que no quise publicar y tal vez nunca publique sobre como la programación degeneró en los últimos 40 años. Y una de las razones por las que no quiero publicarla además de no rantear de a gratis es porque he visto lo que les hacen en internet a programadores que expresan ciertas ideas. Por lo que olvidé el tema hasta hace poco que en un video sobre como las computadoras parecen diseñadas para fallar me topé con el comentario de la foto. Denle click para agrandarla si quieren leerlo.

Todo lo que traté de explicar en ese escrito que me tomó dos meses el programador de este comentario lo resumió en tres palabras: Bottled Web Applications. O en español aplicaciones web embotelladas. Nunca había visto que alguien definiera tan bien el software de estos dias.

En el comentario también explica el cómo llegamos a esto y por qué una computadora parece volverse más lenta con el paso de los años. Y es lo mismo que he escrito en este lugar por años y años. Así que esta vez voy a presentar las cosas desde un punto de vista por completo diferente: El de los negocios.

Desde los inicios de la computación comercial han existido dos figuras rivales que trabajan juntas: El programador y el hombre de negocios. El primero quiere divertirse con las computadoras y el segundo hacer negocios rentables. Y no son capaces de sobrevivir uno sin el otro. Por eso muchos equipos han tenido por lo menos estas dos figuras. Wozniak y Jobs de Apple para dar un ejemplo. Este par se encarga de que sea posible vivir del software. Y ahí es donde el problema comienza. pues como ya he dicho, un programador puede crear software si tiene una computadora, tiempo disponible y sus necesidades básicas cubiertas. Por contraparte, manejar un negocio de software puede ser muy pero muy caro para alguien que no es programador. Pues tiene que pagar salarios a los programadores, el software siempre se tarda más de lo esperado, los buenos programadores son muy escasos y costosos y siempre algo puede salir mal y hacer que todo el trabajo se pierda. El desarrollo de software tiene demasiadas cosas impredecibles que traducidas a dinero son costos millonarios. Y esos costos se tienen que compensar de alguna manera. Y la búsqueda de una solución a este problema es lo que nos trajo las actuales Bottled Web Apps.

Para hacer software de la máxima calidad sin ser uno mismo programador hay que conseguir primero buenos programadores, ponerlos a vivir como monjes en un templo tecnológico que cubra todas sus necesidades humanas y digitales y esperar lo mejor. Y esas serian las condiciones ideales en las que los programadores fueran buenos, se llevaran bien unos con otros, trabajaran a toda su capacidad y entendieran a fondo la tecnología con la que trabajan. Y aún así podría haber retrasos causados por la reparación de bugs o cambios inesperado en las especificaciones. En esas condiciones si que sería posible calcular presupuestos y fechas de entrega con márgenes de riesgo aceptables.

Pero como sabemos la realidad es diferente: Los programadores buenos son difíciles de encontrar, pueden llegar a ser muy conflictivos o tener costumbres que no ayudan a la producción. No viven en monasterios apartados sino en oficinas ruidosas llenas de gente muy diversa (trollface) que los desconcentra. Además la tecnología puede fallar o no estar disponible y los requisitos del proyecto pueden cambiar de modo caprichoso. Así que hacer software de la máxima calidad no es rentable en la mayoría de los casos. Pero es posible producir software con una calidad que sea lo bastante aceptable para venderlo a un precio mayor que el que costó producirlo. ¿Y cómo lo lograron?

Como vivir del software sin saber programar

Desde que se descubrió que había personas dispuestas a pagar dinero real por secuencias inmateriales de números almacenados en un soporte de datos barato los señores del monóculo, el smoking y el sombrero de copa quisieron llevar la producción de esas cadenas de bits al mismo nivel en el que tenian a la producción industrial: Es decir tener instalaciones llenas de trabajadores intercambiables felices de ganar el mínimo y que hicieran tareas sencillas que cualquiera pudiera hacer mientras entonan canciones alegres.

Pero los malvadísimos programadores no estaban dispuestos a trabajar en esas condiciones y como eran muy pocos podian amenazar con irse sabiendo que nadie podría ocupar su lugar. Pero la mano de obra tan especializada no era el único problema al que los señores del dinero se enfrentaban. El otro problema era el propio software. Desarrollar software propio desde cero era arriesgado y muy tardado. Ellos querian comprar piezas ya hechas y ponerlas en una banda transportadora de un lado y que el software saliera del otro lado ya terminado. Ensamblado por una hilera interminable de monos amaestrados tal y como se hacía en las armadoras de automóviles. Pues era más barato pagar por el derecho de usar esos componentes de software a otra empresa y darle bananas a los monos amaestrados que pagarle a sus propios y poco cooperativos programadores.

¿Pero de donde salió el término «app»?

Aquí voy a meter una de mis historias que no se si ya la había contado: Una vez un viejo programador me explicó el origen de la palabra «app» o Application para referirse a los programas de computadora. Al parecer en la antiguedad había dos tipos de desarrolladores: Los que programaban sistemas complejos y avanzados capaces de controlar fábricas y negocios enteros eran conocidos como Programadores de Sistemas o System Programmers. Mientras que muy por debajo de ellos estaban los programadores principiantes que apenas si podian escribir programas pequeños que leian datos como texto y números que le pasaban al sistema grande. Esos eran los Programadores de Aplicaciones. Pues en ese entonces una «aplicación» era una hoja de papel en la que un cliente escribia sus datos y la entregaba a alguien más para obtener un producto o servicio. Y un software de aplicación o «app» hacía exactamente eso.

Y llegan las Bottled Web Apps

Ahora que sabemos el origen del término «app» volvamos a como se hizo más barato y rápido el desarrollo de software. Primero se consiguió rebajar el nivel necesario para entrar creando métodos que permitian intercambiar a la gente. O sea que ya no hacía falta aguantar el sano nivel de autoestima de los programadores de sistemas porque los de aplicaciones eran igual de efectivos y cobraban menos. Luego llegaron las soluciones embotelladas que resolvian los puntos más complicados del sistema y lo único que había que hacer para tener nuevo software era pagar por esas botellas llenas de soluciones mágicas y desorcharlas. Pero todavía faltaba algo: El software no era lo suficientemente bonito y los clientes, al no tener idea de programación juzgaban un software por lo bonito que se veía en sus pantallas. O díganme: ¿Cuantas veces han estado dispuestos a pagar más por un software que se ve igual al anterior pero que fue modificado para que corra de manera más rápida y confiable? La mayoría de los usuarios no se dan cuenta de las mejoras si no se las explican a la hora de correr el programa por primera vez.

Pero había otro problema: Los programadores que sabian de gráficas por computadora ya habian sido expulsados de la empresa. En especial los que sabian de 3D. ¿Cómo se atrevian a pedir un mejor trato nada más porque le entendian a esas privilegiadas e incomprensibles matemáticas? Y como el único que podía hacer cosas estéticas en pantalla era el típico diseñador gráfico que pintaba los letreros del supermercado por menos del mínimo se les ocurrió algo brillante: ¡Usar la tecnología pensada para hacer sitios web para desarrollar todo tipo de software!

Y así, de la noche a la mañana hubo una explosión de color y sonido. Una imagen JPEG cuya codificación desarrollaron grandes ingenieros de la informática y la óptica ahora se podía abrir con una breve linea de texto con el nombre del archivo. El llenado de información había pasado de una serie de llamadas para leer, escribir y codificar datos alfanuméricos en una simple descripción de una caja con una etiqueta. La interactividad y el diálogo entre la máquina y el usuario ya no requería de un ciclo que actualizara la pantalla varias veces por segundo y leyera las teclas. Y lo mejor de todo: Ya no había necesidad de conocer el hardware porque ya casi cualquier sistema contaba con un navegador web. Si acaso había que preocuparse por distinguir entre la peqeña pantalla de un smartphone y un monitor de pared de 42 pulgadas. Y esa información ya la daban los propios navegadores.

¿Y se logró algo? Pues al menos para los que hacen el software a punta de talonario si. Pues ahora basta con que tengan una idea loca y prometedora (disruptora le dicen) para que un millonario que no sabe nada de programación les de dinero. Luego buscan a un grupo de autodenominados geeks que conozcan la herramienta web de moda esa semana. Ya que los tiene los mete a una oficina alquilada que llena de figuritas para «verse geek» y en un tiempo no mayor a dos años ya tiene una flamante «Bottled Web App» que puede venderle a algún cliente grande, distribuirla por medio de una tienda de apps o «regalarla» para vivir de la publicidad y las microtransacciones. Si la app es un éxito el que pagó para que se la hicieran se hará millonario y si no lo logra podrá comenzar todo el proceso de nuevo con otro inversionista, otra tecnología que se ponga de moda y otro grupo de desarrolladores más jóvenes. Porque obvio hay que dar una imagen profesional y nadie quiere programadores treintones y cuarentones con experiencia en tecnología del año pasado pudiendo elegir entre una gran diversidad (trollface) de desarrolladores jóvenes y entusiastas que se tomen selfies que cobran como becarios.

Nada es gratis.

Si todo este maravilloso ecosistema emprendedor que permite a gente que no tocó una PC antes del Facebook enriquecerse haciendo juegos en los que exhiben sus más ocultos y retorcidos traumas sexuales es gracias a una cosa: El enorme poder de las computadoras de hoy. Para que se den una idea un procesador barato de este 2017 es capaz de ejecutar decenas de miles de millones de instrucciones en un segundo. Hasta algunos millones de millones de operaciones de alta precisión matemática en caso de una PC gamer con GPU o gaming rig como le dicen ahora. Puede predecir lo que el usuario va a hacer y aceptar 3 de cada cuatro veces y adelantarse a lo que va a pasar. También puede ejecutar instrucciones en desorden y presentar los resultados como si se hubieran leido una tras otra. Ahora pienten en cualquier programa en el que tengan que escribir texto o hacer click en alguna imagen. Casi siempre hay un retraso de casi un segundo entre que ustedes presionan la tecla y el programa reacciona mostrando la letra o el menú desplegable.¿En serio se necesita una decena de miles de millones de operaciones para reaccionar a la presión de un botón y dibujar una imagen de unos cuantos miles de pixeles? Pues si. Porque las instrucciones de una Bottled Web App no equivalen a instrucciones del CPU como se hace en ensamblador. Pasan por muchos procesos para poder ejecutarse. Así que el dinero que el empresario se ahorró al contratar a un inepto y la simple linea que ese inepto copypasteó de un tutorial en un minuto al final terminó pagándolo la computadora del usuafio final y por extensión su dueño al tener que comprar una computadora más avanzada para hacer lo mismo que su padre hacía a su edad con una PC con la tecnología de hace 20 años.

¿Pero lo vale? Al menos para quienes ponen el dinero si que lo vale. Por otro lado, hacer software que aprovechara el hardware a su máxima capacidad como se hacía en el pasado aunque teóricamente sería posible representaría un verdadero reto. Por eso muchos prefieren software razonablemente bueno para que la gente pague por él. O como dicen en inglés: «You can have it right, or you can have it right now» (puedes tenerlo bien hecho o puedes tenerlo ahora mismo)

Por eso pocos se arriesgan a hacerlo. Muchos incluso dirian que es imposible. Pero todas las cosas son imposibles hasta que alguien las consigue. Y cuando eso sucede son los que pagan por ese software los que más se benefician.

Ya no quiero programar videojuegos 2D

–O el viaje a un espacio donde no hay plaga indie–

Quería hablar sobre la plaga indie pero luego de escribir unas 10 entradas que no quise publicar decidí dejar de lado el asunto y concentrarme en la parte que a mi me afecta. Y para que la plaga indie no me afecte he tomado la decisión de no participar más en el desarrollo de juegos 2D.

Antes de explicarlo mencionaré una teoría de conspiración que dice que tras la segunda guerra mundial gobiernos muy poderosos estaban preocupados porque el arte fuera usado como propaganda política y para desacreditar a los artistas manipularon los mercados de arte y a la prensa especializada para que cosas que no tenian ningún mérito artístico fueran consideradas arte moderno. Así que no me extrañaría enterarme que algo similar está pasando con los videojuegos. Pues sospecho que alguien está sacando provecho de esta ola de juegos injugables, caros, que no tienen nada de programación y que cuando llegar a estar bien hechos a lo más que llegan es a parecerse a juegos de hace más de 20 años. ¿Pero quién gana con todo esto? ¿La prensa del videojuego que habla de los indies como estrellas?¿Los que cobran por poner a la venta esos juegos y que muchas veces nadie paga por jugar?

No tengo idea de quién se esté beneficiando con la plaga indie pero se muy bien a quienes está perjudicando: A los desarrolladores. Antes de la plaga indie no conocí a ningún programador de videojuegos que tuviera problemas económicos. Pues los que no podian llevar al mercado sus propios juegos como mínimo eran contratados para programar el juego de alguien más sin más requisitos que presentar un código que funcionara. En cambio, ahora la inmensa mayoría no tiene trabajo y los pocos que lo tienen deben elegir entre ser parte de eso que llaman ahora la industria y aceptar trabajos donde los tratan bastante mal o vivir de las bases de datos y destinar el poco tiempo que les quede a hacer sus proyectos personales. Los programadores de videojuegos pasaron a sufrir los mismos problemas que los artistas han sufrido durante toda su historia.

¿Pero por qúe ya no quiero programar juegos 2D? Pues porque cualquier juego 2D que programe por mucho que lo programe en ensamblador y logre implementar efectos visuales impresionantes o consiga a buenos artistas para que me hagan los assets nunca va a llamar más la atención del gamer promedio que un juego indie cualquiera hecho en game maker o herramienta juegomática similar con código reciclado una y otra vez y arte con estilo de fanart tumbrezco. Y peor aún si a eso le agregamos que hay juegos indie que se vuelven muy famosos por alguna razón ridícula. Alguna de las razones más ridículas que conozco y que han disparado las ventas de juegos indie son: Que un youtuber lo hizo famoso por burlarse de él, por copiarse descaradamente el estilo de un juego antiguo para ganarse a su fandom, que el que le llevaba el café al programador de un juego clásico quiera hacer una «secuela espiritual» de un título cuyo código nunca tocó o que los personajes sean material para la infame Rule 34.

El asunto es que mientras me mantenga en el 2D siempre va a haber otros juegos indies que llamen más la atención del gamer por cosas sobre las que no tengo ningún control. En cambio en el 3D el dominio de los indies no es tan fuerte. De hecho hasta ahora no he visto ningún juego indie 3D que no parezca estar incompleto, que tenga un control que responda del todo bien o que se compare a nivel visual y de gameplay con un juego de tiempos del Playstation 2 para acá. Y cuando digo juegos indie 3D me estoy refiriendo a juegos indie «powered by» engines 3D como Unity o Unreal, con modelos 3D hechos en Maya o Zbrush y a veces hasta con motion capture. Estos indies a pesar de tener acceso a herramientas para hacer juegos de calidad comercial simplemente no llegan al nivel que el gamer promedio esperaría encontrar en un juego 3D. ¡Y tengo que aprovecharme de eso!

¿Pero por qué los indies no pueden hacer juegos 3D decentes aunque les den las herramientas, el dinero y la capacitación para hacerlos? Sospecho que esto tiene explicación en la genética. Pues los indies que hacen juegos que explotan los motivos ridículos de éxito ya mencionados son particularmente malos para pensar en tres dimensiones o entender conceptos matemáticos que hacen funcionar un buen juego 3D. Y no nada más me refiero a los programadores. Pues entre los indies no hay tantos modeladores y animadores 3D como dibujandes de sprites. O gente que pueda diseñar niveles en los que la percepción del espacio sea clave para jugarlos como los juegos de plataformas o FPS. De ahí que la inmensa mayoría de los juegos indie 3D medianamente exitosos sean «walking simulators» o puras conversaciones y nada de acción. Pero lo mejor de que los indies no sean tan buenos en general con el 3D es que ciertos grupos de indeseables con los que no quiero tartar en esto de hacer juegos parecen huir del 3D casi tanto como de la programación. Y eso ya es más que suficiente para alejarme lo más que pueda del desarrollo de juegos en 2D.

¿Pero por qué no había tomado más en serio el 3D desde antes? Pues porque yo mismo que se como funciona pensé que todavía no tenía el nivel para hacer un proyecto decente y decidí comenzar con algo pequeño. ¿Pero en serio un juego 3D siempre es más dificil de hacer que uno 2D? Esto tal vez sea un mito porque hay juegos 2D que parecen sencillos de hacer o con un aspecto demasiado «retro» cuyos personajes tienen animaciones de cientos o miles de frames que le tomarian meses o años de trabajo a un indie que trabajara en solitario y en sus ratos libres. Mientras que un juego 3D puede lograr todo tipo de tomas con rotación, escala, deformación e iluminación en tiempo real en menos de una semana a partir de un único modelo 3D y rutinas que implementaran las ecuaciones de proyección 3D y multiplicación de matrices y vectores. De hecho ahora mismo me vienen a la mente muchos juegos 3D que perfectamente pudieron haberse hecho en 2D porque el gameplay era bidimensional pero en 3D primitivo con modelos que parecian cartones de leche todo se veía más impactante. Como muchos shoot’em up o matamarcianos de mediados de los noventa.

¿Pero qué tan simple puede ser un juego 3D? No se me ocurre ningún juego 2D que no pueda rehacerse en 3D sin cambiar su gameplay. Pero adaptar el modo de juego 2D al 3D es algo por completo distinto. En mi opinión lo que hace que un juego 2D sea portable al 3D es la rotación. Un juego donde la rotación sea parte del gameplay, por ejemplo el antiguo juego Asteroids! de cuando apenas empezaban las arcades se ha adaptado al 3D muchas veces y en todas ha quedado un muy buen juego. Mientras otros juegos 2D, particularmente los de plataformas clásicos no la han tenido tan fácil. Y en los pocos casos en los que se ha logrado dar el salto al 3D como por ejemplo en Mario Bros se ha tenido que agregar cuando menos la rotación en el eje normal al plano del terreno. Así que recuerden. No importa que tan de plástico industrial con efectos de luz surrealistas tenga su juego. Si no hay rotación de la cámara por lo menos en un eje entonces su juego 3D no es realmente un juego 3D. Ya no hablemos de desplazamientos en los 3 ejes.

¿Y yo que voy a hacer? Pues no me queda otra que huir de la plaga indie. Y para eso tendré que salir corriendo o volando según el sistema de coordenadas en la dirección a la que apunta el eje Z.

Las ventajas de usar archivos de texto como salida de programa

–O por qué la instrucción para mostrar cosas en pantalla se llama PRINT–

¿Alguna vez se han preguntado por qué el comando o instrucción de salida de información en la mayoría de los lenguajes de programación se llama «PRINT»? Por ahora si digo cosas como printf o print piensen en una ventana que muestra el resultado de un cálculo o algún mensaje del tipo Hola Mundo y los más viejos de ustedes tal vez piensen en palabras que aparecen en cascada en ventanas de editores de comandos. Pero la verdad es que la historia del PRINT es mucho más antigua que los monitores de las computadoras.

Hace décadas cuando las computadoras comenzaban no había una forma facil de obtener los resultados de sus operaciones. Primero dichos resultados se representaron como luces que encendian y apagaban y pulsos eléctricos que se perdian pero no fue sino hasta que las computadoras pudieron representar información legible para humanos que se volvieron verdaderamente útiles y la primera forma en que esta información pudo ser representada fue en forma de texto. Y esos textos salian por la boca de las impresoras. Las impresoras son en si mismas un tema fascinante en computación pues muchos de los protocolos de comunicación y representación de información fueron creados específicamente para ellas. De hecho alguna vez leí en un libro muy viejo sobre computadoras que si a uno le daban a elegir entre una impresora y un monitor lo mejor era elegir la impresora pues al tener la información representada en un medio físico como el papel sería mejor a la hora de compartirla con otras personas, agregarla a documentos o simplemente guardarla en un archivero en la oficina. Cosas que por supuesto no podríamos hacer con un monitor. Otra ventaja de la impresora en esa época era que los monitores antiguos tenian muy poca resolución y resultaba complicado leer en ellos y aún a la fecha existe gente que no es capaz de leer directamente en una pantalla de computadora.

Otra referencia a la importancia de los archivos de texto la tenemos en los antiguos programadores de UNIX que daban consejos tan útiles a inicios de la computación como ahora para quienes comienzan a programar y uno de esos consejos era que siempre la salida de los programas fuera en forma de archivo de texto pues estos archivos son muy fáciles de leer sin importar el tipo de tecnología que estemos manejando y hacer programas que trabajen con textos es cosa facil. De hecho, en mi experiencia como programador pasé bastantes años sin saber lo importante que era sacar información por medio de archivos de texto porque me confiaba de otros sistemas de salida de datos como la tradicional salida de mensajes por la pantalla y ya cuando programé en ensamblador llegué a usar archivos binarios puros que leia en editores hexadecimales cuya lectura muchas veces me resultaba más tardada que la programación en si misma. Pero mejor pasemos a ver todas las ventajas de los archivos de texto como salida de programa una por una.

1.- No dependes tanto del sistema

Cuando comencé a programar en ensamblador para Windows (Win32) la peor parte para mi era sacar información básica de lo que el programa estaba haciendo. Algo tan sencillo como mostrar el valor regresado por una función o mostrar el contenido de los registros de propósito general requería hacer toda una serie de tareas que iban desde llamar a una función que pedía todos los datos de ejecución del programa hasta la forma como debian de representarse en pantalla. Incluso la función menos elaborada que era TextOut requería un proceso equivalente a pedirle permiso al sistema para escribir, decirle exactamente donde debía de hacerlo y luego avisar que ya se había terminado de escribir. Y si uno quería que el formato fuera un poco más sencillo de leer tenía que llamar funciones de formato de texto una de las cuales tenía no menos de 30 parámetros. En ese entonces usé la humilde MessageBox para sacar datos a pantalla pero aún así tenía que hacer muchas cosas con la salida porque MessageBox solo mostraba valores en ASCII sin formato y para mostrar datos numéricos había que convertirlos primero. Y lo peor fue que cuando comencé a programar en modos de pantalla completa todo lo anterior no me sirvió para nada porque las funciones de salida de texto de Windows no trabajan igual en estos modos. Al final tuve que hacer sprites a mano de números y letras para poder mostrar información en programas fullscreen.

Otra cosa que intenté fue usar más el debugger para saber lo que pasaba en el programa pero no siempre pueden correrse programas en el debugger y menos si se trata de programas con interacción en tiempo real como los videojuegos. De haber sabido en aquella época que el contenido de todas esas variables que no podía ver lo podía guardar en un archivo y luego con otro programa convertirlo en un archivo de texto que podía revisar con calma en el mismo editor de código me hubiera ahorrado muchísimas horas de trabajo y tal vez ya tendría terminados varios juegos. Sin duda esa es una de las cosas que le diría a mi yo del pasado si algún dia pudiera regresar en el tiempo.

2.- Los datos escurridizos no se pierden

Si la salida del programa la quieres para buscar algún bug no hay nada como usar archivos de texto. Pues puedes guardar el contenido de las variables que sospechas que tienen el error en forma de table de modo que cuando el programa falle el archivo de texto te muestre la situación que tenian los datos antes de fallar y durante la falla y en caso de que la falla no crashee el sistema completo también puedes tener datos de lo que pasó después.

Pongamos por ejemplo de que un arma no funciona siempre, que a veces hace el daño al objetivo y otras pasa a través de él sin afectarlo. Si guardamos el contenido de las variables en cada ciclo del gameloop mientras disparamos contra los monstuos y luego sacamos esos datos en forma de tabla tal que cada renglón sea un ciclo del gameloop y cada columna una variable veremos qué es lo que pasa cuando la bala y el monstruo deberían de hacer contacto y descubrimos que a veces no hay contacto porque en cierto ciclo del gameloop la bala apareció detrás del monstruo cuando este avanzaba hacia nosotros. Un error bastante común. Si en lugar de archivos de texto hubieramos escrito en pantalla el contenido de la variable que indica el impacto no hubiéramos podido ver como las variables interactuaban entre ellas o el valor hubiera cambiado demasiado rápido para poder percibirlo con los ojos.

3.- Buscar datos es facil si usas el propio editor de código

En un programa real los datos no son constantes sino que cambian con el tiempo. Podemos hacer un archivo de texto gigante con varios miles de lecturas de esos datos con respecto al tiempo y si queremos encontrar algún dato en específico podemos usar la función de búsqueda de texto del editor de código. También podemos usar otras opciones del propio editor como buscar todos los momentos en los que una variable tuvo un cierto valor o encontrar mensajes de error del sistema.

4.- Puedes compartir la información con otros programadores

Tener un archivo de texto con la salida del programa ayuda a encontrar errores o a entender el funcionamiento interno cuando uno no programó el sistema original

5.- Los datos pueden examinarse por otros medios

Muchos programas tienen que recibir ajustes antes de liberarse. Por ejemplo un juego puede necesitar balanceo de las armas y los items para evitar que algún objeto demasiado poderoso o muy debil vuelva el juego injugable e injusto. Muchas veces eso se hace introduciendo los datos del juego en una hoja de cálculo y viendo como reaccionan los datos a los cambios. Y si tenemos un texto con esa información hacer esto es tan sencillo como copiar y pegar

6.- Documentar se reduce a un simple copy-paste

Esto no necesita presentación. Si queremos guardar datos sobre el funcionamiento del código o explicarlo en una presentación basta con hacer copy-paste o incluso escribir en el propio documento creado por el programa y entregarlo.

7.- Podemos darle formato a los datos para hacerlos más sencillos de leer.

Si bien un editor hexadecimal sirve para leer cadenas ASCII y datos en formato de 8 bits la cosa se complica cuando tenemos datos de 32 bits en little endian, estructuras de datos compuestas por diferentes tipos y longitudes de bits o valores en punto flotante. Y aunque el editor pueda representar los datos en diferentes formatos no siempre podrá hacerlo distinguiendo de uno por uno. Si quisiéramos ver el contenido de una estructura compleja primero tendríamos que encontrar en qué parte del archivo hex comienza y convertir los datos a mano. Pero si usamos un archivo de texto podemos hacer un programa independiente para que haga todo eso por nosotros. Así podríamos captar el contenido de todos los datos de un vistazo sin necesidad de traducir nada. Un ejemplo de esto son los valores de punto flotante que podrian reescribirse tanto en notación exponencial de base dos como en formato base 10 con su punto decimal o detectar cuando aparezca un valor como un Infinito o un NaN. Por ejemplo es más sencillo reconocer el valor Uno positivo en punto flotante si leemos «1.0» en lugar de 3F800000.

8.- Hacer un programa que cree estos archivos es sencillo.

Otro de los mandamientos de los antiguos sabios del UNIX era que es mejor hacer muchos programas pequeños que hicieran una única cosa sencilla y bien hecha a un programa gigante que hiciera muchas cosas complicadas y con dudosa calidad. Y esto también aplica a la salida por archivos de texto.

En un proyecto cualquiera puede programarse una rutina que saque los valores de salida en forma de un archivo binario puro y esta rutina puede eliminarse en la versión final. Luego aparte podemos hacer un programita que tome como entrada ese archivo binario y produzca un archivo de texto que es el que vamos a usar. Hacer este programita sería cosa sencilla y lo único dificil sería programar las rutinas de conversión de datos binarios a cadenas ASCII y esas mismas rutinas podrian servirnos para otros proyectos. De hecho podríamos hacer uno de estos programas para cada proyecto importante que tengamos y lo único que cambiaríamos sería la parte donde se indica donde están los datos y qué hacer con ellos. Tampoco tendría ningún tipo de interacción y ejecutarlo se reduciría a presionar un botón o hacer un archivo de proceso por lotes que lo ejecutara luego de correr el programa principal. Y esto es posible porque los archivos de texto en realidad no tienen formato como tal. Cada byte es un símbolo ASCII y algunos de esos símbolos indican cosas como Nueva Linea, Tabulador o espacio en blanco. Por lo que producir una salida de texto se reduce a poner los datos en formato ASCII, combinar con otras cadenas de texto ASCII para darle forma y luego la cadena final que no sería otra cosa que un array de bytes guardarla como un archivo con extensión TXT y todo esto es tan rápido que ni nos enteraríamos de que tal programa está ahí. Al final bastará con cargar el archivo creado en un editor de texto cualquiera. Aunque editores capaces de recargar los mismos archivos al presionar un botón son los mejores para mantener la información actualizada.

Saben, escribiendo esta nota recordé que no importa cuantas cosas se hagan hoy con las computadoras. No importa si se usan para negocios, juegos o hacer vida social. Lo único que hacen y siempre han hecho es procesar datos en forma numérica y darnos información en un formato que podamos entender. Todo lo demás que creamos que hace la computadora en realidad es trabajo hecho por seres humanos. Por eso no debemos perder nunca de vista que la información es poder y que aquellas cosas de las que carecemos de información nunca las tendremos bajo nuestro poder. Por eso siempre tengan información actualizada de todos sus proyectos y que mejor que hacerlo recurriendo a los humildes y amistosos archivos de texto.

¿Por qué los mexicanos somos tan malos para programar videojuegos?

–El Eslabón Perdido de 8 bits–

Aunque ustedes no lo crean en México ha habido muchos esfuerzos para desarrollar videojuegos durante los últimos 20 años. Incluso en cierto momento del 2010 muchas fuerzas se pusieron en marcha para echar a andar lo que pudo haber sido la EA de latinoamérica. Hubo un publisher que invirtió mucho dinero para sacar adelante proyectos en colaboración con empresas internacionales tan importantes como Konami, SquareEnix o la mismísima Nintendo. Había tratos para distribuir los juegos en muchas partes del mundo y una enorme campaña publicitaria. ¿Pero qué pasó al final? Supongo que el que ustedes que me leen no hubieran sabido de la existencia de esta elite del desarrollo de videojuegos de México lo dice todo.

Ya en serio, se lo que pasó y puedo decirlo porque yo lo vi muy de cerca y en tiempo real. La gente que contrataron no tenía idea de como se programaba un videojuego y no pudieron terminar a tiempo algo decente. El resultado obviamente fue malo y no se vendió. Y si, ya se que si me han leido desde aquellos años creen que saben lo que voy a decir, pero esta vez tengo una nueva teoría de por que en México somos tan malos para programar videojuegos y esto lo veo porque aunque ya hay grupos independientes que nada tienen que ver con aquel fracaso multimillonario si que el problema de no poder programar un juego con rendimiento de hardware decente o cuyo costo de producción sea mínimamente redituable se repite una y otra vez.

Antes de entrar al tema voy a trollear un poquito. Verán, en ese entonces yo creía que la culpa de la ineptitud de los mexicanos para programar videojuegos tenía razones culturales o académicas más que históricas, pues veía que en ese período en el que nació lo que aquí se llama «La H.Industria» todos parecían provenir de o buscar emplear a gente del mismo origen. Pero luego me tocó ver grupos que no tenían nada que ver con esa demografía que intentaban hacer juegos y fallaban por su ineptitud en la programación y cuando lograban sacar algo jugable el nivel de ventas no era suficientemente alto para recuperar lo invertido.

Pero bien. ¿Por que los mexicanos somos tan ineptos para programar videojuegos? Mi nueva teoría es que en el pais no se vivió una época que si se vivió en paises como Estados Unidos, Japón, Inglaterra e incluso España. En esa época fue cuando se crearon muchas de las grandes empresas de videojuegos que todavía existen o afamados creadores de videojuegos aprendieron a programar. Una era en la que las computadoras no servian para tantas cosas como ahora y que cualquiera que poseyera alguna sin importar su edad, clase social o nivel de estudios podía usarla para aprender a programar, crear videojuegos y hacerse famoso. Esa era fue la de las microcomputadoras de 8 bits.

Las microcomputadoras de 8 bits eran poco más que juguetes. Por la décima parte del valor de una computadora de verdad uno podía comprarse uno de estos aparatos similares a un teclado de computadora gordo que podía conectar al televisor de casa cual si se tratase de una consola de videojuegos. Y al igual que estas sus capacidades eran bastante reducidas: Procesadores de 8 bits a 3 o 5 megaHertz (una milésima de velocidad de una PC barata del 2016), memoria RAM de 64 kilobytes o menos en la que no cabría ni el ícono de escritorio de un juego actual y almacenamiento secundario que en caso de existir se hacía en cintas de cassette iguales a las usadas para la música y que podian tomar varios minutos en leerse. Estos sistemas aunque baratos eran incompatibles entre si de modo que un programa o juego para una consola podia no funcionar en otra y si se ‘porteaba’ el resultado era por completo distinto cuando no deprimente. En el continente americano las máquinas de 8 bits dominantes eran marca Commodore basados en el chip 6502 que era el mismo del NES, en Europa las Amstrad y ZX Spectrum basadas en el Z80 y en Asia la MSX o otros sistemas también encontrados en las regiones anteriores.

Pero lo mejor de los sistemas de 8 bits era toda la comunidad que se había creado alrededor de ellos: Programadores entusiastas que se reunian a comparar y compartir software creado por ellos mismos, revistas que publicaban artículos sobre como programar estos sistemas y hasta números con códigos completos que cualquiera que entendiera su funcionamiento podía teclear en su casa, o incluso aunque no lo entendiera podía hacerlo funcionar mientras no cambiara ni una sola letra.

Ese período histórico como ya dije fue clave en paises donde ahora si que existe una verdadera industria de videojuegos. Pero ahora veamos lo que pasó en México y que aunque algo tuvo que ver el problema que había con la importación de computadoras, en el caso de sistemas de 8 bits esto no fue tan malo, pero si que pasaron otras cosas bastante raras.

El Ataque de los Niños Gigantes

Para empezar, mientras que en paises como los ya mencionados estos sistemas se popularizaron tanto que vender juegos grabados en cintas de cassette era buen negocio en México los sistemas de 8 bits no se vendieron tanto. Pero no porque fueran sistemas muy caros sino porque había un extraño estigma alredor de las microcomputadoras que hasta hoy no se si fue un error en las campañas publicitarias o habría razones genéticas hasta ahora no descubiertas. Y es que es hasta esta época con el Youtube y los podcast que me enteré que en otros paises quienes usaban estas computadoras eran programadores y aficionados a los videojuegos o «gamers». En México no recuerdo haber visto que a los gamers les interesaran estos sistemas tanto como las arcades o consolas como el NES o las todavía funcionales Atari 2600. Los usuarios mexicanos de las computadoras de 8 bits eran en su inmensa mayoría una extraña especie a la que en ese entonces clasifiqué como «Niños Gigantes». Pues se trataba de sujetos casi en su mayoría hombres que a pesar de ser mucho más altos que el promedio de la población sus cuerpos eran blandos y redondeados como los de los niños, casi carentes de barba, aunque a algunos ejemplares les crecian barbas pobladas al comenzar a trabajar para distinguirse de los otros machos de la manada. Y sin barba, su edad resultaba casi imposible de determinar sin buscar indicios en su ropa que revelaran su pertenencia a alguna empresa o escuela. En público era casi imposible encontrarlos a más de un metro de distancia de sus madres que casi siempre eran mujeres de vestir conservador y trato confiado con desconocidos y quién decidía todo por ellos como que juegos debería de comprar de acuerdo a su contenido. Mi trato con los niños gigantes era contradictorio, pues si bien siendo ya un geek en potencia y teniendo tema para hablar con ellos me daba miedo terminar convertido en uno o por lo menos si lograba llevarme bien con ellos hacía todo lo posible por llevar esa convivencia lejos de las miradas condenatorias de los normies.

En internet la única referencia remota que he encontrado sobre la relación entre los Niños Gigantes y las computadoras de 8 bits son comentarios sobre que los usuarios de esos sistemas no eran tan competitivos ni afectos a los juegos de acción rápida como los jugadores de arcades o consolas. En cambio preferian juegos más «meditativos» y pausados que resultarian incomprensibles para los jugadores de hoy. Tal vez lo más parecido sería una combinación de aspacto de Visual Novel con el gameplay de un juego de estrategia por turnos y muchos comandos de texto o menus desplegables. Es más, una vez escuché a uno de estos Niños Gigantes que trabajaba en el departamento de computación de una escuela secundaria referirse a las consolas como «Un desperdicio de tiempo y de dinero» y que era mucho mejor inversión una Commodore Amiga. Y si bien ese modelo específico de computadora (que no era ya de 8 bits) era muy bueno y tenía muchos juegos no era nada facil de conseguir en las tiendas y sus juegos en mi ciudad eran por completo inexistentes.

Ensamblador V.S. BASIC

Pero volvamos con el tema de la programación. Algo interesante de las computadoras de 8 bits es que se podian usar para programar pero los únicos dos lenguajes de programación funcionales eran Ensamblador y BASIC. Creo que no tengo que decirle al publico habitual que los verdaderos programas se hacian en ensamblador y el BASIC era meramente una cosa para los muy pero muy principiantes. Y algo que si noté es que nunca vi a un Niño Gigante programar una Commodore o un ZX Spectrum en ensamblador. Al menos no en México. Mi teoría es que la presencia de esa extraña y blanda especie en la escena de las computadoras de 8 bits tenía algo que ver con que la publicidad con que las ofrecian las presentaban como herramientas para el aprendizaje y no como computadoras o consolas de videojuego programables. Recuerdo especialmente un anuncio de la XE de Atari que la presentaban como una herramienta de aprendizaje para que la compraran los padres y como una consola de videojuegos para que atrajera a los niños normales. Otra razón por la que dudo que hubiera muchos niños gigantes programando en ensamblador es que programar en él requiere de mucho tiempo y esfuerzo y una de las características de los padres que criaban a dichos ejemplares tenian la férrea política de no permitirles estar con una computadora o consola de juegos por más de una o dos horas al dia.

Pero el daño ya estaba hecho. Mientras que en otros paises había cientos de programadores que habian hecho juegos en ensamblador para que otros miles de gamers los jugaran en sus sistemas de 8 bits en México los pocos programadores de ensamblador de 8 bits que pudieran haber existido nunca pudieron comercializar sus juegos porque los pocos que tenian una de estas máquinas eran en su mayoría los mullidos Niños Gigantes y lo más seguro es que sus madres nunca les hubieran permitido jugar videojuegos no educativos con la excusa de que eran «violentos». Personalmente yo no recuerdo haber visto una computadora de 8 bits mas que una vez en una tienda, pero casi siempre se comentaba que «el amigo de un amigo o el primo de un amigo» tenia una. Cuando el tiempo pasó hubo un pequeño movimiento de programadores para computadoras en los noventa pero la mayoría de las computadoras de 16 y 32 bits eran tan caras que no era negocio producir y vender juegos para PC en el pais. Lo peor fue cuando aparecieron las redes sociales y las computadoras pasaron a ser un accesorio más de la casa o de moda en el caso de los smartphones en lugar de algo exclusivo de programadores, gamers y geeks. Ahora vamos con más de mi teoría.

La era de las leyendas quedó atrás…

Una de las cosas que más he defendido es que los programadores tienen sus propias leyes para juzgarse entre ellos y que lo único que hace la diferencia entre un programador y otro son sus códigos. Los programadores comienzan desde niños o adolescentes a programar mientras curiosean con las máquinas. Aprenden por si mismos y prueban su código una y otra vez hasta que logran que la PC haga lo que ellos quieren. Yo mismo puedo decir que mi espíritu de programador disminuyó mucho en la era del internet «normie» y cada vez me cuesta más trabajo ver las nuevas computadoras como veia mi viejo Pentium 100mHz que programaba en ensamblador para Windows 95 luego de que el BASIC, C y C++ en ese orden me fueron quedando pequeños. Me hubiera gustado programar una Commodore o un Spectrum en ensamblador y enviar mi juego a algún pais en donde estos sistemas si que estaban en manos de gamers. Ahora si me pongo nostálgico tal vez pueda programar algo para emulador y que lo jueguen unos pocos aficionados a la retroinformática.

¿Y cual fue el efecto de que en México no hubiéramos tenido una era de desarrollo de videojuegos en 8 bits? Pues que nunca tuvimos programadores de videojuegos que valoraran la eficiencia. Se dice por ejemplo que en España el negocio de los videojuegos decayó cuando se popularizaron las computadoras de 16 bits porque no había tantas y los juegos eran mucho más fáciles de copiar gracias a los discos flexibles. Regresando a México vagamente recuerdo que cuando a las computadoras de 8 bits les quedaba poco alguien intentó hacer un concurso de programación pero no supe en qué acabó. Y en cuanto a la programación de videojuegos «profesional» esta comenzó a dar señales de vida en una época en la que el estandar era una PC de 32 bits con Windows, tecnología de aceleración gráfica y almacenamiento óptico. O sea nada que ver con sistemas de 8 bits con 64k de RAM y menos de un megabyte de almacenamiento magnético. No estuve ahí pero cuenta la leyenda de que los primeros intentos costaron demasiado y las ventas no fueron suficientes. Situación que sigue repitiendose al dia de hoy.

Todo esto puede explicar el por qué la actitud prejuiciosa y narcisista de la H.Industria al negar la posibilidad de que existieran programadores de videojuegos fuera de su selecto círculo. Y si bien tenian algo de razón porque al no haber una era de desarrollo local de 8 bits no hubo programadores también olvidaron que dentro de su propio círculo tampoco iban a encontrarlos. Lo más cercano que pudieron encontrar debió ser alguna variación (no digo descendientes porque dudo que pudieran reproducirse de manera natural) de los Niños Gigantes de los ochenta cuya experiencia personal se limitaba al BASIC y una cosita despreciable de C++ desde Visual Studio con la que copypasteaban los ejemplos del SDK de DirectX y en lo profesional a hacer cosas de bases de datos. Es por esto que la inmensa mayoría de los mexicanos que actualmente quieren programar videojuegos tienen tantos problemas: Porque no vivieron la época en la que había que programar el hardware al máximo y si son muy jóvenes nunca tuvieron a un maestro que si hubiera vivido en esa época porque en este pais esa época nunca existió.

¿Y como podríamos recrear la época en la que las grandes leyendas de la programación de videojuegos aprendieron sus habilides? La cosa sería muy dificil porque el mundo de hoy es otro. Sería como enseñarle a sobrevivir en la naturaleza a alguien que nunca ha salido de la ciudad y que cree que las fieras de la selva son como los animalitos de las películas de Disney. Un niño o joven que hoy quiera aprender a programar videojuegos se vería abrumado con todo tipo de herramientas como los engines, editores multimedia y 3D muchos de los cuales podría descargar a su computadora desde el primer dia. Pero oh sorpresa vería que no sabe usar ninguno y que tiene que pagar una fortuna en libros, cursos y certificaciones para aprender a usarlos y luego de algunos años y muchísimo dinero invertido se daría cuenta de que él solo no va a poder hacer un juego exitoso porque no cuenta con los 500 millones de dólares para desarrollar algo como el siguiente GTA ni nadie le dará la décima parte de eso para hacer su jueguito indie injugable y se retirará a manejar bases de datos si es que lo suyo era la programación o a ser ayudante de publicista si quería hacer juegos pero se asustó al ver que programar requería saber matemáticas.

De momento de lo único que estoy seguro es que si alguna vez aparece una verdadera empresa de videojuegos en el pais no va a ser gracias a inversionistas ni «gente importante» sino al esfuerzo de grupos pequeños que desarrollarán sus proyectos desde cero, con sus propios recursos y el tiempo libre que les quede luego de un pesado dia de trabajo o escuela. Gente que no esperó a que alguien abriera una universidad de programación de videojuegos para tomar un libro de programación e implementar los algoritmos explicados en él. Que tampoco va a esperar a que alguien le pague un salario para hacer juegos ni mucho menos se quejará de que es poco si tiene la inmensa fortuna de encontrar a un incauto dispuesto a pagarle. Pues en otros paises grandes leyendas de los videojuegos comenzaron de la nada y México no tiene por que ser la excepción. Y recordando algo que dijo uno muy relacionado con el género FPS: «Para hacer videojuegos lo único que necesitas es una PC, mucha dedicación y una buena provisión de comida congelada». Aunque por supuesto estas palabras fueron dichas a mediados de los noventa cuando no había redes sociales, video en streaming ni apps de mensajería que distrajeran a los programadores de su monástica labor. Por desgracia esa era de dificultades donde se forjaron los mejores no regresará a menos que ocurra alguna clase de equivalente informático de un apocalipsis zombie. ¿O será acaso que quien lo logre ya vive actualmente en su propio mundo apocalíptico encerrado, sin dinero ni tiempo libre y si muchísimos problemas para hacer juegos? ¿Estará leyendo esto ahora mismo? Eso sólo el tiempo lo dirá.

El 2D actual es menos eficiente que el 3D

–O por que los personajes parecen marionetas de papel–

Al momento de escribir esto estoy a pocas horas de haber regresado de una de las convenciones de comics a la que hasta ahora le he sacado mayor partido como programador. Pero no piensen que conocí a grandes desarrolladores de juegos con los que pude aprender técnicas o cerrar tratos sino todo lo contrario. Sin proponérselo me enseñaron cosas de programación que llevaba tiempo sin entender del todo. Pero comencemos con la historia.

Hace tiempo que ya no iba a las convenciones de comics de Monterrey porque ya no me ofrecen nada que no pueda ser comprado (o descargado) por internet. Sin embargo voy cuando invitan a alguien relacionado con el desarrollo de videojuegos. He visto gente que intentaba hacerse millonaria cambiándole cosas a un ejemplo de un tutorial de Flash, un grupo que quiere hacer proyectos que abarquen todo lo vendible posible pero no han podido hacer videojuegos porque no saben programar, un expositor que se me escapó y por perseguirlo acabé en una situación similar a la de Homero Simpson cuando fue al Circo Francés y de un tiempo acá una incontable cantidad de escuelas donde por un precio comparable a estudiar una carrera universitaria en una universidad privada te leen la ayuda de algún software y entregan un papel que dice que les pagaste. Pero esta vez la experiencia sería un poquito diferente.

Pues estaba yo de troll en internet cuando me entero que en la convención había dos conferencias que parecian estar relacionadas con la programación de videojuegos: La primera era sobre «Gráficos 2D para Videojuegos» y la otra sobre creación de personajes para videojuegos (o eso creí) RPG. Estas pláticas serian dadas en la «sala de talleres» justo al final del infame Pasillo de los Perdedores. Para los que no saben de estos eventos, toda convención de comics desde la famosa Convención de San Diego California hasta esas que hacen en pueblos pequeños donde todavía llega el internet, tienen una sección para expositores que no tuvieron suficiente dinero para pagar un stand de verdad ni son lo bastante reconocidos para que una empresa seria se los pague. Pero consegur un espacio en esa zona es muy barato comparado con los precios en las áreas para expositores de verdad. En el Pasillo de los Perdedores podemos encontrar dibujantes que quieren dar a conocer sus obras, otros que venden dibujos y manualidades de personajes que no son suyos y de vez en cuando algún artista local que ha logrado un modesto grupo de fans gracias a los webcomics. Pero quedémonos con la parte de la programación.

La Sala de Talleres se encontraba justo al final del Pasillo de los Perdedores. Luego de una plática de una escuela de dibujo en la que mencionaron como hacer que una obra se viera totalmente diferente con 2 clics del mouse (o más bien del stylus de la Wacom) por fin comenzó la esperada plática sobre Gráficos 2D para videojuegos

Hago una pausa para comentar algo a los más jóvenes. Yo soy lo bastante viejo para recordar como era la animación americana en las décadas de los setenta y ochenta y aunque ya desde entonces se usaban computadoras para hacerlas fue a partir de mediados de los noventa que las máquinas de los animadores tuvieron suficiente poder para crear la mayor parte de la animación con mínima intervención humana. Algo similar está ocurriendo con las actuales computadoras y smartphones. Así que alguien nacido hace menos de 20 años no ve ninguna diferencia de calidad pero los de mi generación si detectamos que en las primeras animaciones de ese tiempo u otras recientes pero de bajo presupuesto los personajes parecian ser marionetas hechas con recortes de papel en lugar de auténticos dibujos animados. Aunque hay más cuadros de animación el movimiento es demasiado plano y lineal. Sin embargo producir animación de esta forma es bastante barato y el público al que va dirigido el producto que son en su mayoría niños pequeños no es demasiado exigente. Lo que deja mayores ganancias a los productores.

Pues bien, en la plática el expositor mostró un software para manejar imágenes llamado Spriter. Creó una figura articulada a partir de unas pocas imágenes que se repetian en diferente tamaño y posición, le dio un ‘esqueleto’ y luego lo animó indicando algunos cuadros clave y dejándo que el software interpolara los cuadros intermedios. El resultado final fue una de esas cosas que ahora llaman «Sprite Sheet» que son archivos gráficos enormes con todas las posiciones posibles de los personajes. Y según dijo quien dio la plática esa sprite sheet se la pasaban al nerd apestado que era el único que le sabía mover al engine en turno. Al final de la plática algunos nos acercamos a la mesa para seguir haciendo preguntas y soltó algunas cosas que ya conocía bien por mis batallas con la H.Industria: Que si los engines, que si los makers, que si las tienditas de assets y todo de lo que me quejo siempre. Pero lo que fue nuevo es que se le salió decir que lo que muchos ‘profesionales’ hacian era bajarse códigos de juegos ya hechos y cambiarle los assets para sacar a la venta juegos nuevos. En si nada que no supiera ya.

La segunda conferencia que creí yo sería sobre como hacer personajes para juegos RPG acabó siendo en realidad unos pocos consejos de dibujo dados por un artista tradicional en lapiz y papel. No dijo nada sobre RPG ni a nivel videojuego ni a nivel juego de mesa pero dio algunas ideas para dibujar. Tal vez si a la plática se hubiera llamado «Como empezar a dibujar tus propios personajes» habría atraido más a artistas principiantes que valoraran esos consejos en lugar de a puros codetrolls como yo.

Y ahí acabó la que sería mi visita a una convención de comics que más ha hecho por mi cruzada Gamedev hasta ahora. Pero de esa experiencia saqué dos conclusiones: La primera es que si voy como expositor a un evento como esos no debo de hablar de nada de programación porque a la mayoría les va a estallar la cabeza y la segunda es que si presento un juego este debe de estar al nivel de un juego de verdad o seré un monito más en el Pasillo de los Perdedores. Pero ahora comencemos con mi ranteo sobre como eso que ahora llaman «videojuegos 2D» está mucho más cerca en cuanto a requerimientos de hardware de un juego 3D moderno para PC Master Race que de un videojuego de la era de 8 o 16 bits sin importar que tan «retro» intenten hacerlo parecer.

Los actuales gráficos 2D son en realidad 3D aplanado

Para explicarlo rápido, actualmente necesitan una mejor computadora para correr un juego «2D» como Castle Crashers o Heartstone que para jugar el no tan viejo Doom 3 que era un juego 3D en toda regla. Y es que en realidad los videojuegos «2D» actuales son en realidad videojuego 3D «aplanados». Para generar un miserable cuadro de animación en un juego 2D actual se emplean los mismos algoritmos de los juegos 3D, los ‘sprites’ son en realidad polígonos planos con iluminación y textura que se rotan, posicionan, escalan y recortan vectorialmente. Se ordenan del más lejano al más cercano y se aplican diversos algoritmos de filtrado de color para mantener la imagen en cierta calidad. Es como si tuviéramos un juego 3D en el que los objetos en lugar de tener volumen fueran planos como esos anuncios de figuras de cartón de cuerpo entero y estuvieran dispuestos muy juntos casi uno sobre el otro.

Si esto no fuera suficiente, la poca optimización de memoria que pudo haberse logrado usando unas pocas imágenes cuya combinación forma imágenes más grandes se pierde a la hora de usar una sprite sheet. Personalmente no creo que ningún engine decente admita una sprite sheet o peor aún un atlas de textura sin hacerle algún tipo de procesamiento antes de usarlo en el juego. Pues tomar los cientos de sprites y reacomodarlos dentro de la memoria para ser mostrados puede requerir mucho más código que el necesario para mostrarlos durante el gameplay. Además las animaciones cíclicas son altamente redundantes. En otra época un personaje podía tener diferentes partes intercambiables de modo que podían armarse muchas animaciones diferentes a partir de unos pocos sprites o ajustaban los sprites de modo que cuando se hiciera un cambio este fuera mínimo. Por ejemplo que un guerrero hiciera el mismo movimiento con los brazos al atacar sin importar si su arma era un cuchillo,un mazo o una espada.

Los verdaderos gráficos 2D de la época anterior a los juegos 3D optimizaban la memoria y el trabajo del CPU o los coprocesadores gráficos. Usaban únicamente valores enteros y un byte de memoria podía representar varios pixeles. Las resoluciones eran muy bajas para tener animaciones fluidas sin desperdiciar RAM y los colores que podian ser tan pocos como 16 o menos se combinaban de maneras ingeniosas para aparentar diferentes efectos como transparencias o efectos de luz. Se usaban operaciones de lógica binaria para componer las imágenes individuales en otras más elaboradas. No había cambios de tamaño ni rotaciones porque no había capacidad vectorial ni de punto flotante y cuando algún programador muy pero muy bueno implementaba algo así era recalculando por software cada uno de los pixeles con algoritmos que usaban aritmética entera y desplazamientos binarios. Un juego completo de NES podía medir 100 kilobytes o menos que es el equivalente a un archivo de imagen de muy baja resolución y uno de 16 bits como de Super Nintendo o Sega Genesis/Mega Drive unos 2 megabytes que es menos que una foto típica tomada con un smartphone barato que uno sube a las redes sociales. Todo eso se resume en una palabra hoy desconocida por los que se creen profesionales: Optimización. Que significa obtener el mayor provecho posible con los recursos disponibles.

Un brazo dibujado por nadie

Antes de seguir con lo de la optimización haré referencia a una escena de Los Simpson en la que Bart compra una celda de animación de Tomy y Daly (Itchy & Scratchy) por 300 dólares con la tarjeta de crédito de Homero pero cuando recibe el esperado paquete se desilusiona al ver que apenas se trata de un dibujo de un pequeño brazo y mucho espacio vacío. Ni siquiera un personaje o escena completa. Así que con la esperanza de recuperar el dinero perdido intenta venderlo en la tienda de historietas y ahí el coleccionista antes de echarlo a la calle le muestra un dibujo enmarcado y dice algo así como «Este es un original autografiado por un artista famoso y lo que traes ahí es un brazo dibujado por nadie», aunque al final se apiada de él y aunque no le paga en efectivo le ofrece cambiarlo por una mercancía que no se vendió. Esta escena es clave para entender el final de esta entrada. Ahora sigamos hablando sobre a donde se fue la optimización en los juegos 2D.

La optimización todavía existe pero ya no está en el código ni en los chips de memoria. Ahora la optimización está en la mano de obra. Antes era posible hacer un videojuego que corriera en un hardware insignificante porque quienes lo programaban eran los mejores y los mejores eran difíciles de encontrar. Hoy en cambio el hardware es de lo mejor y los desarrolladores son los insignificantes. Hoy cualquiera que tenga dinero e iniciativa puede contratar por migajas y durante pocos meses a gente que puede sacar productos en poco tiempo y esos productos ya no necesitan ser eficientes porque «al hardware le sobra poder». Los desarrolladores de videojuegos comienzan pasar de ser rockstars a esclavos sacrificables a los que se les puede hacer trabajar tiempo extra sin paga y echar a la calle cuando el proyecto termina. Algo así como pasó con los animadores japoneses que trabajan todo el dia y ganan menos que un recolector de basura.

No me gusta esta nueva forma de trabajar que tienen las nuevas empresas grandes en las que se contrata a cientos o miles de artistas o desarrolladores y se les pone a hacer tareas insignificantes e intercambiables. Hoy a lo más que puede aspirar alguien es a ser recordado como «el dibujante de X superhéroe entre los años tal y tal» o poder ir al cine y decirle a quien les acompañe: «yo participé en los efectos de esa película animada en 3D. ¡Hice el rigging del codo de ese extra que se ve a lo lejos!». Tal vez por eso esta vez en el Pasillo de los Perdedores pude encontrarme con (por lo menos) 20 artistas que trabajan para Marvel, un estudio completo que diseño personajes para Zynga, 3 prestigiosas escuelas de efectos especiales reconocidas internacionalmente y hasta un director de animación que trabajó para Cartoon Network y que actualmente está participando en cierto largometraje francés que de este lado del mundo solo es conocido por sus parodias para adultos hechas en Flash (y que tiene la misma calidad que la original). Me pregunto como era posible que gente tan importante estuviera en el Pasillo de los Perdedores mientras que en los espacios dedicados a los invitados de honor lo más que había eran algunos actores de voz casi retirados, extras de programas pasados de moda y olvidados hace años y un montón de attent… digo, ehem… gente disfrazada.

Con eso en mente salí del centro de convenciones mientras pensaba que si yo hubiera nacido 20 años después seguramente nunca hubiera sabido de la existencia de la programación en ensamblador y probablemente ni siquiera me hubiera dedicado a programar. Tal vez hubiera hecho lo que muchos de los que van a esos eventos hacen y decidiera estudiar algo relacionado con efectos especiales y manejo de software 3D con la esperanza de algún dia poder hacer mi propio videojuego. Pero también, cuantos de esos geeks a los que les interesan estos temas nunca sabrán el verdadero nivel de programación que hay tras un buen juego 3D y por lo tanto nunca se convertirán en programadores pudiendo serlo. Me apena pensar que cuando empecé a programar uno podía llegar a hacerse famoso con un videojuego programado por él y sus amigos en su propia casa y ahora la maquinaria está tan automatizada que a lo más que uno puede aspirar es a que su trabajo llame la atención de entre otros cientos de trabajos sobre una mesa de un reclutador y que nos pongan a hacer tareas sencillas como colorear digitalmente, limpiar dibujos a lapiz o portear rutinas de código ya hechas por otros programadores. Si en aquella época uno soñaba con hacerse famoso y vender piezas de arte original ahora lo más que puede uno producir y vender es tan insignificante como la celda de animación de «un brazo dibujado por nadie» que compró Bart Simpson. Ya no hay espacio para la grandeza.

Todos los Videojuegos son Wargames parte 3

–Como la computadora puede simular y jugar un juego de mesa–

Tercera parte de la serie sobre la relación que existe entre los antiguos Wargames y los actuales videojuegos. En las dos primeras partes vimos como un wargame de hace 100 años puede ser definido por una computadora y en la segunda el como una situación tan sencilla como la de un ataque a un enemigo virtual que dura menos de un segundo requiere tantas comparaciones y validaciones numéricas. En esta tercera entrada veremos que todos los videojuegos tienen algo de wargame.Repasemos algunos elementos comunes a todos los wargames.

Miniaturas o Fichas

Las miniaturas con las que se juegan los wargames tales como los soldados, tanques, obstáculos naturales, bases y cualquier cosa que tome parte en la acción también tiene su lugar en los videojuegos y es con lo primero que los jugadores interactuan en un videojuego. Lo que cuando aprendí a programar se le llamaban «Datos», cuando llegó la H.Industria llamaron «Assets» y de un tiempo acá oigo que nombran como «Props». Las Miniaturas son para la computadora conjuntos de datos que la computadora usa para representar cosas en la pantalla: Monstruos, héroes, armas, items, obstáculos, escenas y cualquier otra cosa con la que el jugador interactue en pantalla. De hecho los datos o assets del juego es lo que el jugador ve. Incluso si se tratara de un videojuego en modo texto las letras y números que muestran la información en pantalla cuentan como assets. Una cosa interesante es que la mayoría de los datos que forman estas miniaturas virtuales son inútiles para la computadora si no tienen información que sea usada por las reglas del juego. ¿Pero qué sentido tendría jugar un videojuego en el que no sabemos qué está pasando?

Turnos

Tal vez lo más elemental de un wargame y un videojuego es el concepto de turno. En cada turno uno de los jugadores puede hacer algo, ya sea un movimiento, un ataque o puede usarse como unidad de tiempo para medir la duración de acontecimientos. Pues bien. Todos los videojuegos desde los tediosos RPG por turnos hasta las aventuras 3D de acción rápida multijugador usan turnos. El corazón de un videojuego se llama Gameloop y se trata de un ciclo que se repite eternamente o hasta que ocurra algo que haga que el juego se termine. En cada ciclo se leen las entradas del usuario, se actualiza la acción y se despliega la escena. Estos turnos pueden durar tan poco como unos pocos milisegundos para los juegos más rápidos. Ese turno es clave para la interacción y si no lo tuviéramos no sería posible que el jugador pudiera controlar nada. Para ponerlo de modo más sencillo pensemos en un menú de opciones en el que nos movemos por las opciones con las flechas y seleccionamos una con un botón. En cada ciclo del gameloop se lee si presionamos una flecha y si lo hacemos la opcion cambiará, si no presionamos la opción permanecerá igual. Y si se detecta que presionamos el botón la opción seleccionada en ese momento se tomará como entrada. Y para distinguir entre una opción y otra puede ser algo tan sencillo como incrementar o decrementar un contador cada vez que presionamos una flecha. Volviendo a los turnos. En lo que conocemos como juego por turnos el turno no termina hasta que el jugador ha hecho su acción y en los juegos rápidos el turno termina cuando al jugador se le acaba el tiempo. Como ya se dijo, si los turnos son lo bastante rápidos se da la impresión de que todo se mueve a la vez.

Tablero

Los wargames se juegan en una mesa sobre la que se acomodan las miniaturas y los videojuegos aunque no cuentan con mesa si que usan algún tipo de universo en el que ocurre la acción. Para los juegos de una sola pantalla ese universo puede ser el monitor pero la mayoría de los juegos actuales usan el monitor como ventana para contemplar una pequeña parte de un universo más grande. Para ubicar algo en ese universo usamos coordenadas tridimensionales XYZ. Ese campo de juego tiene límites de modo que en todo momento las coordenadas siempre están dentro de un rango de valores. Para ejemplificar pensemos en un tablero de ajedrez de 8 cuadrados por lado y un total de 64 casillas. Podríamos tomar como coordenadas x,y cualquiera de estas casillas e ignorar la coordenada z. La computadora necesita controlar ese campo de juego para saber en todo momento donde están los elementos del juego y como interactuan entre ellos.

Varas y plantillas

Los wargames usan varas de longitud determinada para medir distancias y plantillas de cartón o plástico para ver si dos miniaturas están a menos de cierta distancia una de otra o cuales miniaturas están dentro de un área determinada. La computadora usa algoritmos geométricos para medir distancias o ver si alguna de sus miniaturas virtuales están dentro de una cierta área. Existen muchos diferentes algoritmos que pueden programarse en una computadora que funcionan como las varas y las plantillas. Pues aunque un humano puede orientarse en el plano o en el espacio de manera natural y saber donde están las cosas la computadora no puede. Y por eso recurre a esos algortmos geométricos y por supuesto a la Geometría Analítica que en lugar de regla y compás usa números con los que puede trabajar mejor la computadora.

Dados

En los wargames y otros muchos juegos de mesa se usan dados. El dado de 6 caras es el más común pero en algunos juegos se usan dados de 4, 10 o hasta 100 caras. Estos dados se usan para darle al juego algo de emoción y simular eventos que no están del todo bajo el control del usuario. La computadora tiene sus propios dados en forma de algoritmos que generar un número dentro de un cierto rango de acuerdo con alguna regla. Y si bien existen algoritmos para generar números matemáticamente aleatorios usables en cálculos científicos hay otras formas de conseguir números más o menos aleatorios sin tantos problemas como el tener un contador que cuente de manera indefinida entre el rango buscado y que cuando el jugador apriete el botón de acción se tome un número de ese contador. Si el jugador nunca ve ese contador y no sabe que él mismo dio la orden de leerlo al presionar el botón para él será una acción aleatoria. Algo similar puede hacerse con los relojes internos del sistema.

Tablas de atributos de personajes

Esto no tengo que explicarlo. Los wargames tienen tablas que definen las capacidades de los personajes en forma numérica. Esos mismos números pueden guardarse en la memoria de la computadora y ser leidos según vaya desarrollándose la partida.

Todo tipo de reglas de juego

Los wargames se juegan siguiendo una serie de reglas que deciden todo lo que puede hacerse en el juego y como definir los resultados de cada situación. Esas mismas reglas se pueden programar en los videojuegos. De hecho si al código de un videojuego le quitamos todo lo relacionado con interacción con el usuario, despliegue de la escena y control del hardware lo que nos queda es el mismo conjunto de reglas del manual del wargame pero escritas en una forma que la computadora pueda leer y ejecutar.

Ahora veamos muy rápido como un juego clásico que uno creería que nada tiene que ver con los wargames tiene todos estos elementos. Me ahorro lo de los turnos porque todo código interactivo los tiene. Y aunque no lo crean voy a hablar del Tetris.

Tetris.- En Tetris el tablero es una cuadrícula por la que se mueven las piezas y se puede programar como un array de enteros donde el contenido de cada elemento del array indica lo que hay en esa posición. Ya sea que esté vacio o que haya algo ahí. Las miniaturas son por supuesto las piezas pero si miramos de cerca las 7 formas posibles se forman por 4 cuadrados pequeños que miden exactamente lo mismo que los cuadrados de la cuadrícula que forma el tablero de juego. Por lo que cada pieza puede caber en un rectángulo de 4 por 2. Las varas de medir y plantillas en este caso son los propios cuadros del tablero de juego de modo que cuando uno de los subcuadros que forman las piezas detecta que en la posición inferior hay otro cuadro ocupado automáticamente la pieza se pega a la estructura y una nueva pieza cae. Los dados entran en la parte que decide cual pieza sigue. En Tetris las piezas no caen de modo arbitrario. Piezas como la barra larga o el cudrado aparecen menos veces que las piezas T, L o Z y pasado cierto nivel lo único que cae son piezas Z que son particularmente difíciles de acomodar. Y en cuanto a las reglas estas son simples. Se empieza con el tablero vacio y van cayendo piezas de acuerdo a la regla ya mencionada. Cada que una pieza aparece pasan una cierta cantidad de turnos antes de que caiga un paso a la vez y esa cantidad de turnos de espera será menor conforme la dificultad aumente. Si alguno de los cuadros que componen la pieza no puede seguir cayendo porque algo impide su caida (o avance por el terrreno según un wargame) la pieza se integra a lo ya caido y aparece otra nueva pieza. Si una o más lineas horizontales se completan estas desaparecen y todos los cuadros ya caidos se deslizan abajo tantas lineas como se hayan completado y se ganan puntos. El juego se termina cuando se ha completado el límite de lineas o cuando ya no hay espacio en el tablero para acomodar más piezas.

En la siguiente entrada hablaré sobre como estos elementos se repiten en otros tipos de juegos. Aunque algunos juegos puede parecer que les falta alguno de estos elementos la verdad es que si los tienen. Pero eso es algo que como jugadores tal vez nunca hayan notado.

CMPGPV: Programador vs Idea Guy

Como convertir una idea en código fuente

Todo proyecto comienza con una idea y esa idea debe de ser expresada de algún modo. En esta entrada comenzaremos a discutir la primera fase del manejo de proyectos grandes de programación enfocado a juegos: La fase del espionaje y el Idea Guy.

Sin entrar en detalles un Idea Guy es alguien que no programa, no dibuja, y en realidad no hace nada que se refleje directamente en el juego. Pero es el que tiene esa idea genial que quiere compartir con el mundo. En el mejor de los casos el Idea Guy puede tener cierta idea de como escribir una historia y construir los diálogos del juego. Aunque fuera de los RPG o juegos muy narrativos el Idea Guy termina siendo cualquier desocupado con iniciativa que invita a otros que si saben hacer algo a hacer un juego. En esta entrada veremos como tomar las ideas geniales de este personaje y obtener información de programación a partir de sus ocurrencias.

Pensemos en una situación típica: Ustedes pertenecen a un grupito de nerds que quieren hacer un videojuego. Entre ellos hay gente que sabe dibujar en papel, manejar editores gráficos, hacer sonidos y música y por supuesto alguien que tiene una muy pero muy buena historia que quiere dar a conocer al mundo en formato jugable. De este grupo ustedes son los programadores. Personajes que hacen el trabajo que nadie del grupo entiende ni quiere entender pero que se aguantan porque no les queda mas remedio. Entonces va la pregunta ¿Como convertir todas esas conversaciones llenas de ilusión e interminables documentos de texto con faltas de ortografía en un código de un videojuego?

Créanme, he estado en muchas de estas pláticas y se de lo que hablo. Los de las ideas pueden tener toda clase de historias y personajes geniales y los que manejan los paquetes de creación de contenido pueden saber como usarlos pero ustedes como programadores no deben dejarse arrastrar por los detalles. Al menos no todavía. Mas bien deben de ejercitar su capacidad de abstracción y pensar en términos de reglas y de información. Lo primero que deben de tener en cuenta es que todo programa de computadora o subrutina que lo componga tiene una cosa en común: A todos les entra información por un lado y les sale transformada por otro. ¿No lo creen? ¿Creen que eso es cosa aburrida de administración? Pues no es así. Aún en el mas loco de los videojuegos se cumple esa regla. El código de un videojuego toma los gráficos, el sonido creado por los artistas como entrada y las señales enviadas desde el control del jugador, lo procesa de acuerdo a las reglas con las que está programado el juego y al final genera una salida de datos que el hardware de video y audio muestran como una animación multimedia interactiva. Y este código a su vez puede descomponerse en módulos mas pequeños por los cuales circulan los datos del juego. La fase del espionaje consiste en convertir esos textos interminables que describen el videojuego en un conjunto de unidades de datos y de control. Volviendo a la analogía de la guerra esta etapa consiste en identificar los blancos y las unidades enemigas y definir que posiciones debemos de controlar para tener oportunidad de ganar. Y aunque suena aburrido y complicado verán que es un proceso bastante mecánico que bien puede ser auxiliado por un programa de procesamiento de cadenas de texto sin mucha ciencia.

Un ejemplo de idea de las que valen 10 centavos la docena:

Otra cosa aunque esto tal vez ya lo sepan si saben algo de programación de videojuegos: Las ideas valen 10 centavos la docena. No importa que tan genial o lucrativa se escuche una idea, si no hay videojuego jugable que lleve a la realidad esa idea esta no vale nada. Ahora veamos un ejemplo de una de esas ideas de menos de un centavo que bien pudo basarse o no en un famoso videojuego de la era de 8 bits del NES.

Ejemplo práctico: Digamos que el Idea Guy y los artistas quieren hacer un videojuego de plataforma donde el protagonista sea un ninja. Si no les gustan los ninjas mas adelante veremos otros ejemplos pero lo que el escritor puede presentarles es un trozo de texto como este:

«El juego cuenta la historia de un ninja que busca vengar el asesinato de su padre y viaja a occidente donde sospecha se esconde el culpable. Armado con su espada, su gran agilidad y conocimientos ancestrales se abre camino por lugares como ciudades controladas por pandillas, selvas llenas de fieras y templos antiguos protegidos por fanáticos. Su búsqueda de venganza lo lleva a descubrir una conspiración para revivir a un antiguo demonio cuyo ejército infernal llevará a la humanidad a la destrucción y él es el único ser viviente capaz de impedirlo.»

Este párrafo puede ser una idea que a cualquiera puede ocurrírsele luego de ver alguna película o leer algún libro y aunque puede parecer muy buena todavía le falta trabajo. La mayoría de los ‘de las ideas’ no se detienen aquí, comienzan a diseñar mas cosas, sobre todo personajes y situaciones en los que se presenten. Si tiene liderazgo puede que algunos de los artistas hagan dibujos de como se vería el ninja y puede que hasta hagan en papel o un editor gráfico algunos cuadros de animación. Y los programadores tal vez logren mover algunos de los dibujos en pantalla si es que les toca uno bueno. Pero hasta donde yo he visto los proyectos de videojuegos de los aficionados no pasan de ahí. El escritor se frustra de no ver que su historia se vuelva jugable. Los artistas se hartan de dibujar todo el dia y al final ver que lo que sale en pantalla no se parece nada a lo que hicieron en papel y el programador con suerte puede mover una imagen y que reaccione al oprimir uno o dos botones y mandar la aplicación a un crash al oprimir los 2 botones al mismo tiempo. La inmensa mayoría ni siquiera llegan a ver una sola animación de 2 frames en pantalla y terminan con «mucha historia, poco arte y cero código», abandonan su proyecto cuando llega la época de los exámenes y no trabajan en él en vacaciones, tan solo para olvidarlo al inicio del siguiente semestre. Pero este no será nuestro caso y ahora veremos que como programadores esta descripción es todo lo que necesitamos para empezar.

En programación a la descripción con palabras que describe lo que el código va a hacer se le llama Enunciado de Alcance. Esa descripción del juego es un enunciado de alcance y estos pueden extenderse en 2 direcciones diferentes: Hacia lo ancho y hacia lo profundo. Extender el enunciado de alcance hacia lo profundo es detallar algo que ya se describió y hacerlo hacia lo ancho es agregar nuevas cosas. Es importante no abusar y caer en la tentación de agregar demasiadas cosas. Un juego puede tener una historia muy elaborada pero las cuestiones programables en realidad no son tantas. De hecho en etapas avanzadas el código comienza a reducirse y lo que antes hacíamos con mil lineas luego puede hacerse con menos de 100. Y además de extender el enunciado de alcance hacia adentro o hacia afuera podemos hacer otra cosa: Obtener información a partir de las palabras. No se si este proceso tiene nombre pero a partir de este es como podemos obtener información básica para la construcción del programa a partir de una descripción del mismo.

A veces hace falta mucha abstracción para poder convertir una historia elaborada en un documento que pueda reducirse a un enunciado de alcance. Y el proceso para obtener información a partir de las palabras es largo. Les recomiendo que si son programadores no se alejen demasiado del escritor para poder discutir con él si algo pueden programarlo o no y cambiarlo si es que no tienen idea de como hacer algo. Esos escritores pueden perderse en sus propias ideas y no hacer nunca nada que pueda programarse en un tiempo razonable. Pero para eso estamos los programadores que por medio de una buena labor de inteligencia y fria recolección de datos tomaremos esos textos y los convertiremos en código. Pero eso lo veremos en las siguientes entradas.

CMPGPV: Sala de Situación

–El lugar donde llega toda la información y se dictan las órdenes–

Antes de comenzar a manejar un proyecto grande de programación es necesario contar con un mínimo de infraestructura física que en nuestro caso como somos unos pobres diablos será una sencilla libreta y un lapiz con borrador. A lo largo de la serie discutiremos como mejorarla con ayuda de computadoras pero por ahora con papel y lapiz basta. Esta libreta será nuestro centro de mando desde el que vamos a controlar todo lo que suceda en esta operación. Pero antes de ver como usarla déjenme contarles una historia.

Los nombres de lugares y paises han sido omitidos porque no me gusta meterme con la política pero cuentan las crónicas que un cierto dirigente que libraba una guerra decidió construir un cuarto en los sótanos de sus oficinas donde podía estar al tanto de todo lo que sucedía en el frente y dar órdenes a sus fuerzas ahi mismo. Al principio y debido a la época solo se trataba de un cuarto con téléfonos, telégrafo, gente que manejaba esas comunicaciones y desde luego mandos militares de alto rango que lo ayudaban a tomar decisiones. La importancia de una instalación como esta fue confirmada por otro lider algunas décadas después cuando vio como una fuerza bien equipada y entrenada a la que había mandado a recuperar un territorio fue arrasada no por falta de poder sino por no tener suficiente comunicación. Ese abandono era tal que algunos especularon que los había dejado morir para evitar represalias internacionales. En fin, cualquiera que esté al frente de un proyecto grande debe de contar con un punto en el que le llegue toda la información y desde el cual poder dar órdenes. Dicha instalación tiene muchos nombres: Sala de guerra, centro de mando o el que da título a esta nota que es Sala de Situación.

Hoy en dia las salas de situación cuentan con toda clase de adelantos y los líderes pueden presenciar en vivo lo que sus efectivos están haciendo en cualquier parte del mundo. Y nuestra modesta Sala de Situación nos servirá para lo mismo. Ya conforme avancemos les diré como hacerle algunas mejoras. Ahora la pregunta es ¿Y que hacemos con esa libreta? Lo primero que haremos será escribir en hojas diseñadas para tal propósito cualquier cosa referente al proyecto en sentencias cortas de no mas de 3 renglones. En esas sentencias pongan cualquier cosa que tenga que ver con el proyecto como por ejemplo lo que hace, en que lugar del disco lo guardaron o que herramientas están utilizando. Además de las situaciones importantes que ocurran durante el desarrollo del proyecto en la Sala de situación se almacenan otras cosas dependiendo de en cual de las 5 etapas estemos. Intentaré definir en términos neutrales la forma de almacenar la información para no cargarlos con tanto detalle:

Espionaje.- Se guardan párrafos de texto cada vez mas grandes. Aunque es raro que alguno de estos párrafos abarque mas de media hoja. Listas de palabras y frases de las que podremos extraer información. Al final se obtienen pequeñas estructuras y conjuntos de procedimientos sencillos. Para resumir en esta parte trabajamos con textos y unos pocos dibujos sencillos.

Estrategia.- Esta etapa es muy gráfica, requiere tomar la información de la etapa del espionaje y construir una especie de mapa que describe todo el proyecto. Para seguir nuestro simil con la guerra hay posiciones fijas que representan módulos y procedimientos y carreteras o lineas de suministros por donde se mueven los datos. Este mapa es muy importante y será consultado a lo largo de todo el proyecto

Asalto.- La programación real. Aquí es donde mas se usa la sección de situación dejando rastros de cosas como nombres de archivos, dificultades que aparecieron y posibles cambios para etapas mas avanzadas. En esta parte es mucho mas lo que se lee que lo que se escribe.

Dominio.- En dominio también se lee mas de lo que se escribe pero aquí además comienza a modificarse el mapa creado en la fase de la estrategia. Hay que tener borrador o una manera limpia y organizada de llevar los cambios.

Expansión.- Aquí es donde el mapa completo se reconstruye. La reconstrucción puede ser tan grande que partes completas del mapa queden invalidadas o sean suplidas por otras. Como siempre se necesita un control de todo lo que sucede a cada momento para retomar la tarea donde nos quedamos.

Ultimas advertencias

Pues bien, antes de comenzar con la primera etapa tengo que dejar claras dos cosas. La primera es que esta serie va enfocada a la parte de PROGRAMACION. Existen otros métodos de manejo de trabajo que son buenos para hacer cosas que no interactuan tanto entre si ni pueden generar tantos errores como lo hace el código. Métodos que hasta donde he experimentado no sirven para programar. La segunda es que esto si trata de ser una respuesta a la eterna pregunta de «¿Como puedo mantener y terminar un proyecto de programación de videojuegos?» que uno lee en la mayoría de los foros y cuya respuesta casi invariablemente se resume en el típico «échale ganas» o cosas sobre las deadlines y los milestones que lo único que marcan son fechas límites pero no como completar el trabajo antes de que esas fechas lleguen. Y una cosa mas, los proyectos de programación y no solo los de programación de juegos son muy largos. Pueden tomar meses o incluso años y de ese tiempo menos del veinte porciento se la pasa uno escribiendo código. El primer 40 porciento se la pasa uno planeando lo que va a hacer y el último 40 tratando de averiguar el porqué el código no funcionó. Créanme, aunque parezca que todo esto es perder el tiempo hacerlo les ayudará a sentirse menos perdidos a la hora de programar. Ahora prepárense porque ya vamos a empezar con la etapa del espionaje.

CMPGPV: Como Manejar Proyectos Grandes de Programación de Videojuegos

introducción: Capitán de mar y guerra

Proyectos, proyectos y proyectos. A lo largo de mi tiempo queriendo hacer videojuegos y un tanto mas como programador me he topado muchas veces con la misma historia. Proyectos de videojuegos que no llegan a ninguna parte. Grandes ideas que se quedan solo en eso y que nunca llegan a ser jugables. Y no crean que esto solo se ve en aficionados que no han programado nunca en su vida. También lo he visto en grupos de programadores muy avanzados. Yo mismo tengo varios proyectos muertos y enterrados por ahí. Lo que nos lleva a la pregunta: ¿Dejar un proyecto de programación de videojuegos tiene algo que ver con la habilidad del programador? La respuesta es no. Pero antes veamos una historia para ver de quién es la culpa.

Remontémonos a la época de los grandes navegantes, ambiciosos piratas y batallas navales. En esos tiempos los barcos de guerra no tenian uno sino dos capitanes: Uno era el mismo que tenía cualquier otro barco y que sabía como navegar y orientarse en el mar mientras el otro era el que sabía como combatir y estaba a cargo de la batalla. En esos tiempos sobrevivir no era cuestión solamente de saber pelear pues uno de estos poderosos barcos era capaz de hundir a toda una flota enemiga sin una sola baja y sin embargo regresar al puerto con menos de la mitad de la tripulación por culpa de enfermedades, accidentes o cualquier otro error que cometiera el capitán de mar.

Pues bien, he conocido muchos casos (el mio incluido) de programadores experimentados que dejan sus proyectos a medias o con tantos errores que sus programas son virtualmente inútiles. Es común escuchar a programadores que no reconocen su propio código luego de haberlo dejado de lado por tan solo una semana o el caso mas común de sistemas tan mal diseñados que el autor tiene que regresar una y otra vez a cualquier hora del dia a solucionar un problema. En esta serie verán que esto no tiene tanto que ver con si un programador es bueno o no.

Regresando a los guerreros antiguos nada garantiza que ganaremos la guerra solo porque podamos ganar todas las batallas. En la guerra hay muchas mas cosas que pueden matarnos además de las armas: Poderosos barcos de guerra se perdieron en el mar, ciudades amuralladas vieron morir a sus defensores por falta de alimentos, soldados murieron de frio al intentar invadir Rusia en tiempos de Napoleón y muchos otros en climas cálidos fueron víctimas de enfermedades tropicales y cayeron mucho antes de enfrentarse al enemigo. Por no mencionar la gran cantidad de efectivos que regresaron de la Primera Guerra sin piernas no por culpa de las balas y las bombas sino por tomar a la ligera el lodo y humedad acumulados en el interior de sus botas. Pero los tiempos han cambiado y hoy en dia si revisamos el equipo que portan los actuales soldados veremos que menos de la cuarta parte de lo que cargan son armas. La mayor parte de lo que llevan son cosas como provisiones, medicinas y herramienta que les permitieran cosas tan elementales como dormir o ir al baño en plena naturaleza. Algunos están tan bien equipados que pueden sobrevivir sin problemas por dos semanas antes de ser rescatados. Por no mencionar que cuentan con sistemas de comunicación y una red de computadoras y personal que les ayuda y brinda información para sobrevivir en sus misiones.

En esta serie discutiremos esos aspectos de sobrevivencia adaptados a programación en este caso de videojuegos que es el tema donde mas he visto y vivido este tipo de situaciones. Si alguno de ustedes que estudió y leyó un poco mas que las presentaciones de Power Point en sus clases de ingeniería en computación tal vez algunas de las cosas que voy a mencionar en esta serie se les hagan conocidas. Pues hay muchos libros que hablan sobre como administrar proyectos grandes de programación pero tales lecturas son tan somníferas y tediosas que nadie de los que vengan aquí seguido va a querer leer. Así que les pido que si tienen algún comentario al respecto tomen esto en cuenta. Estos escritos no tienen ni pretenden tener nada de eso que llaman rigor académico.

Una Guerra de Cinco Fases:
Espionaje, Estrategia, Asalto, Dominio y Expansión

Tan solo la parte de programación de un videojuego requiere mucho trabajo. No basta con escribir un código que funcione bien la primera vez. De hecho un proyecto de programación serio es igual que una operación militar que consta de cinco fases: Espionaje, Estrategia, Asalto, Dominio y Expansión. Veamos en breve cada una

Espionaje: En esta fase se investiga toda la información de lo que queremos programar. Ya sea nosotros o alguien que nos encargue hacer el proyecto. Esta información se recibe en forma de texto escrito y hay procedimientos mas o menos mecánicos que permiten extraer información que nos lleve a identificar cosas como estructuras de datos, módulos, funciones, variables y todo aquello con lo que vamos a trabajar. Es el equivalente a obtener un informe detallado del enemigo, el terreno y los objetivos.

Estrategia: Una vez con la información sobre qué es lo que vamos a hacer lo que sigue es definir como hacerlo. Para ello existe una construcción gráfica que define el sistema completo. Piensen en esta construcción como el mapa del territorio enemigo. Este mapa contiene información de todo tipo siendo las mas importantes la manera como circulan los datos dentro del programa y el código que se encarga de trabajar con estos mientras se mueven. Esta etapa puede parecer larga y aburrida pero si se hace bien acelerará por mucho la programación, disminuirá el tiempo de reparación de errores y sobre todo permitirá poner al corriente a cualquiera que intente unirse al proyecto.

Asalto: Esta es la primera parte donde entra la programación. Si el mapa definido en la fase de estrategia es bueno el programador puede hacer cosas que se antojarian imposibles sin él como por ejemplo trabajar en diferentes puntos del sistema o pausar y retomar el trabajo en cualquier momento. También es posible repartir el trabajo entre muchos programadores disminuyendo el riesgo de que sus códigos se estorben entre si o aislar los módulos para aminorar la posibilidad de que un error en uno de ellos afecte los demás. Esta es la parte mas emocionante pero también donde puede haber mas caos. Es importante que el progamador recurra con frecuencia a toda la información generada en las 2 etapas anteriores cada que se sienta perdido. Otro punto de esta etapa es que ya se tiene un producto que aunque no está terminado es mínimamente usable

Dominio: No basta con tener un sistema que funcione para nosotros si no podemos garantizar un mínimo de confianza. La fase de dominio consiste en buscar todas las amenazas y debilidades de nuestro nuevo sistema y corregirlas. Si en la guerra que es programar un proyecto grande la fase de asalto fue apoderarse de un territorio enemigo la fase de dominio consiste en localizar y eliminar a la resistencia así como mejorar las defensas en los sitios vulnerables por donde nos puedan atacar. De nuevo el mapa estratégico y los informes de inteligencia nos pueden dar información que nos ayudará a dar caza a estas amenazas.

Expansión: Pero ningún sistema es perfecto o al menos no tan perfecto como para permanecer sin cambios por siempre. Los cambios para detectar y neutralizar amenazas son pocos en comparación con los cambios que hay que hacer para que el sistema se adecue a nuevas necesidades. Tarde o temprano llegará el momento en que queramos adaptar nuestro juego a nuevas plataformas, agregar nuevas características o simplemente tomar alguna de sus partes para poder usarla con confianza en proyectos futuros. Hay una manera organizada de hacer cambios en los proyectos de programación que reduzcan la aparición de nuevos errores al mínimo. Un proyecto de programación bien diseñado puede intercambiar cualquiera de sus partes sin poner en peligro el resto del sistema.

En fin, en esta serie veremos como manejar proyectos grandes de programación sin correr los peligros que hacen que estos queden inconclusos. En la siguiente entrada veremos lo mínimo que necesitamos para mantener estas bestias controladas. Sistemas que pueden ir desde una libreta y un lapiz hasta un cuarto lleno con personal de apoyo. Por cierto, para escribir esta serie estoy usando una versión adaptada del mismo sistema que les estoy describiendo aquí así que lo mas seguro es que esta serie si llegue a su final o en el peor de los casos no salga a la luz. Tal vez me tome meses termirarla pero esta vez termirará. Sin mas los dejo y prepárense porque participar en un proyecto grande de programación es entrar en una auténtica guerra.

¿Debe la Universidad apoyar al desarrollo de videojuegos? 2

–Parte 2: La Vereda y el Rompecabezas–

Esta es la segunda parte de la serie sobre universidad y desarrollo de videojuegos. En la primera entrada les comenté que aunque en la universidad hay recursos y gente talentosa cuyas habilidades son aplicables a los juegos eso no significa que debe de ponerse a hacerlos ni mucho menos dejar preparados a sus egresados para que cualquiera que quiera iniciar una empresa de la nada los ponga a hacer uno. En esta parte voy a hablarles no solo sobre como encontrar esos recursos escondidos para hacer videojuegos dentro de la universidad sino incluso darles un par de tips para que no la pasen tan mal en sus años de estudiante. Sobre todo si ustedes se consideran auténticos gamers y geeks.

Primero hay que dejar clara una cosa. Cursar una carrera universitaria es muy parecido a caminar por una vereda en el bosque. La vereda o camino tiene inicio y fin y caminar por ella requiere esfuerzo. También hay que llegar a ciertos puntos antes de cierto tiempo. Un buen estudiante se mantiene en esa vereda y dedica todo su tiempo y esfuerzo en llegar al final sin salirse de ella. Al final del camino si es que logra llegar consigue terminar sus estudios y se va a hacer su vida sin que nadie pueda reclamarle nada. Pues bien, estos son los típicos y respetables graduados de los que hablé brevemente la entrada anterior. Respetables profesionistas dedicados a sus estudios que no tienen idea de lo que es hacer videojuegos. Ahora veamos el otro tipo de estudiante que al graduarse puede ser de mas utilidad que este.

Y aquí es donde empieza lo interesante: Los conocimientos valiosos. En la universidad hay un sinfin de recursos valiosos para cualquier joven aspirante a game developer pero no es obligatorio encontrarlos para graduarse. Casi como lo que los gamers considerarían misiones secundarias. Estos objetivos secundarios son muchos y muy pequeños. Y para lograr algo apreciable es necesario encontrarlos y juntarlos cual si fueran piezas de un rompecabezas (Puzzle). Unas parecen insignificantes y otras dan la impresión de no encajar en ningún lado hasta que encontramos otras que les dan sentido. Si están en una universidad considerada normal y quieren aprender a hacer juegos deben de ser capaces de encontrar estas piezas de rompecabezas y armarlo antes de que su carrera universitaria termine. La pregunta es ¿Donde están escondidas esas piezas del rompecabezas?

Las piezas del rompecabezas están en todas partes. Pueden ser libros abandonados en la biblioteca. Maestros que tienen conocimientos que no necesariamente verás en clase y otros alumnos geeks que también se interesarían por ayudarte. La universidad es un bosque entero, cada facultad una sección diferente con su propia fauna y las carreras son esas veredas que hay que cruzar caminando para llegar al final. Y las piezas del rompecabezas que necesitas armar están en todas partes. Algunas incluso pueden estar tan cerca de ti que ni siquiera te des cuenta cuando caminas sobre ellas. Otras están apenas a la orilla del camino, otras perdidas en caminos que no son el tuyo y otras mas en sitios inaccesibles donde los caminos no llegan. Pero ir por ellas es peligroso. Si abandonas la vereda por mucho tiempo descuidarás tus estudios y correrás el riesgo de reprobar materias y posiblemente abandonar la universidad. Debes de ser lo suficentemente habil para obtener esos conocimientos que se supone no te pertenecen y seguir con tu plan de estudios oficial.

Las piezas del rompecabezas cuya obtención menos interfiere con tus estudios son aquellas que pertenecen a tu propia carrera. Por ejemplo muchos estudiantes de carreras de Ingenieré en Computación se quejan de que los primeros semestres ven demasiadas matemáticas. Yo por ejmplo en primer semestre llevé Geometría analítica, cálculo diferencial, álgebra, física newtoniana y solo una materia muy básica de conceptos de computación donde ni siquiera utilizamos un compilador. En apariencia nada de eso servía para hacer videojuegos. Pero no era así. La geometría analítica sirve para determinar contactos en el espacio y programar superficies en 3D. El cálculo diferencial se aplica en animación al igual que la física newtoniana, los sencillos despejes algebráicos y las inducciones permitían reducir la cantidad de operaciones y comparaciones dentro del código del juego y la materia que al parecer mas me serviría apenas si me sirvió para saber la diferencia entre un compilador y un intérprete. Lo interesante es que toda la utilidad práctica de esas materias la descubrí mucho tiempo después de cursarlas. Aunque en otros casos investigaciones propias me llevaron a leer libros de materias de semestres mas avanzados desde antes. Como cuando llevé matrices y le mostré al maestro que el procedimiento para calcular bases ortonormales que repasábamos ese dia en clase era el mismo que el que se usaba en programación gráfica para cámaras y transformaciones de vista. Y para confirmarlo mostré ambos libros para que viera que el problema era el mismo. La pregunta es: ¿Cuantos de mis otros compañeros de clase imaginaron que lo que estaban viendo ese dia servía para programar videojuegos? Y mas interesante. ¿Alguno de ellos salió de la carrera, entró a La Industria y aplicó esos mismos conocimientos para hacer algún juego? ¿Tendría al menos idea de que había una relación entre videojuegos y matemáticas?

Aventurándose fuera de la vereda

Contaré ahora una breve anécdota: Estaba en la biblioteca junto con algunos de mis secuaces investigando el algoritmo de rasterizado y texturizado de triángulos. En eso se nos acercó un compañero de clase y asustado nos preguntó si estábamos estudiando para un examen. Cuando le dijimos que esto lo estábamos haciendo por cuenta propia nos miró con desprecio y se fue caminando despacio y hacia atrás. Esa fue una pieza de rompecabezas que no estaba dentro del camino pero el encontrarnos en ambiente universitario nos puso cerca de donde estaba. Los libros pertenecian a la universidad aunque no fueran de nuestra materia. Otro ejemplo que recuerdo era sobre la biblioteca de la facultad de ingeniería, aunque yo estaba en matemáticas en la biblioteca de la facultad vecina tenían varios libros olvidados pero que me resultaron muy valiosos. Como los escritos por Foley, Hearn, Tremblay, un hindú que hablaba de compiladores, un griego que le sabía al C y al ASM y otros mas que en su momento me ayudaron en mis aventuras pero que al parecer yo era el único que leia. No tenía la obligación de leerlos y falté a mas de una clase con tal de sacarles todo su contenido. Hacer esto me provocaba una emoción muy extraña. Por un momento me emocionaba enormemente aprender cosas, pero a la vez eran cosas que a nadie mas parecía interesarles. Con el tiempo no se si aprendí a disimular mi entusiasmo o simplemente me fui amargando al ver que a nadie mas que a mi parecían importarle tanto esas cosas.

No puedo terminar esta entrada sin decirles al menos como identificar esas piezas del rompecabezas cuando estén cerca de ellas. La mayor parte del tiempo no sabrán identificarlas aunque estén frente a ellas. Algunas se encuentran en libros abandonados en la biblioteca. Otras en conversaciones casuales que escuchen al pasar. A veces hay eventos o simples pláticas de grupos donde pueden obtener información. Hay maestros que dominan temas que pueden serles útiles y que ellos mismos no saben que a ustedes les pueden ayudar. Lo mas importante es que estas piezas son muy concretas y objetivas. A veces son simples pistas como por ejemplo que necesitan tal o cual hardware o conocimiento para hacer algo. Otras son físicas como libros, manuales o hardware no muy comercial. Otras son información pura como instrucciones ejecutables, código fuente o la sintaxis de algún lenguaje de programación. Lo importante es que una pieza de ese enorme rompecabezas es lo suficientemente pequeña para poder ser comprendida en uno o dos dias. Si no entienden como hacer una cosa o encuentran que otra que hallaron parece inutil seguramente es porque les falta una pieza del rompecabezas que una a ambas. Es muy común en programación en encontrarse con códigos que entienden perfectamente pero que son incapaces de compilar o tener entornos de desarrollo que no tienen idea de como funcionan. Solo cuando encuentran que uno pega con el otro es cuando descubren la relación entre ambos y logran unir 2 o mas piezas del rompecabezas.

¿Y qué pasa si ya se graduaron, no han entrado aún a la universidad o en casos extremos salieran o no entraran nunca? Aunque no tengan una vereda que recorrer las piezas del rompecabezas siguen ocultas en los mismos lugares. Pueden comprar libros o leerlos en bibliotecas públicas, buscar información en internet o aprender de otros que tengan el conocimiento que quieren. La búsqueda del rompecabezas nunca termina y mientras mas conocimientos adquieren mas partes de este misterio prodrán resolver. Ese es el verdadero valor de estar en una universidad o cualquier otro ambiente intelectual. Poder obtener piezas del rompecabezas para hacer no solo juegos sino cualquier otra cosa que ustedes quieran hacer en sus respectivas aventuras. Y ahora los dejo porque tengo una buena cantidad de piezas de rompecabezas que tengo que encontrar y unir para resolver mis propios misterios.

¿Debe la Universidad apoyar al desarrollo de videojuegos? 1

–Parte 1: ¿Donde Están los Game Develpers?–

Esta vez voy a escribir una nota bastante infame, tendenciosa y dura cuya única defensa es que se trata algo que yo personalmente viví. Por lo que nadie va a poder venirme con el argumento de que no se de lo que estoy hablando. Echa esta advertencia me dispongo a dar respuesta a una interrogante que los involucrados en el desarrollo de videojuegos en México y latinoamérica se han hecho una y otra vez. La pregunta es: ¿Qué puede hacer la academia para impulsar el desarrollo de videojuegos en el pais? Mi respuesta es sencilla y tajante y la explicaré a lo largo de esta serie y es la siguiente:

La universidad debe de hacerse a un lado y no intervenir de modo directo en el desarrollo de videojuegos

Ahora que tanto los miembros mas jóvenes de la academia y los padrinos mas adinerados de la industria están con cara de WTF les hablaré un poco sobre mi. Yo también fui un adolescente geek que entró a una carrera universitaria relacionada con computadoras con la esperanza de aprender todo lo necesario para hacer videojuegos, o cuando menos la parte de la programación. Primero estudié en una universidad de la que tuve que huir por las razones que ya he mencionado muchas veces aquí y luego comencé y terminé la misma carrera desde cero en otra donde nadie me conocía. Y aunque no puedo decir que nada de lo que viví en ninguna de esas dos escuelas me fuera de utilidad les aseguro que cualquiera de esas cosas puede obtenerse sin necesidad de matricularse en ninguna escuela. Y aunque sigo negando que cursar una carrera universitaria de una ventaja *real* a alguien que quiere programar juegos años después de lo ocurrido comprendo el porqué. Y ese porqué es de lo que voy a hablarles a lo largo de esta serie.

Primero, para los lectores que no son mexicanos o no han leido mi serie de entradas donde hablo sobre como los mexicanos ven los estudios superiores tienen que saber que en este pais los habitantes entran a la universidad por un sinfin de motivos entre los cuales no se encuentra aprender. Con la honrosa excepción de unos muy contados intelectuales con vocación científica que quieren dedicarse a dar clases y escribir publicaciones de ciencia por el resto de su vida la inmensa mayoría de los que se inscriben en una universidad lo hacen por motivos meramente sociales y económicos que van desde los que creen que el título universitario es una especie de permiso del gobierno para ejecer cualquier tipo de actividad económica (y no solo las muy contadas que si regula) hasta los que creen que terminar una carrera convierte al graduado en un tipo especial de ser humano capaz de resolver todos los problemas con su sola presencia. Pasando por aquellas familias pobres que intentan conseguir becas para sus hijos en universidades costosas para que se relacionen con los hijos de los poderosos. Y si bien en otras industrias donde ganarse la vida solo es cosa de hacer esfuerzos físicos y saber invertir dinero; en el desarrollo de videojuegos es del todo diferente aunque todos sin importar su procedencia se topan con los mismos obstáculos a la hora de sentarse frente a las computadoras.

El tema sobre como las computadoras ven a los humanos ya lo traté en otra entrada. En resumen a la computadora no le importa donde estudiaste o cuanto dinero tengas. Si no sabes programar no tendrán piedad contigo. Combinando estos dos aspectos obtenemos como resultado grupos que creen que para hacer un juego solo necesitan dinero del gobierno y contratar a unos pocos estudiantes recién egresados y que estos van a hacerles un videojuego de principio a fin en el tiempo acordado y sin dificultades. Solo para darse cuenta de que a medida que se acerca la fecha límite que el juego no sale. Y lo peor es cuando ese plazo termina y ya no tienen para seguir pagando salarios y en el mejor de los casos pierden todo su dinero en algo que no llevó a nada y en el peor tener que responder con sus propios bienes a quién les prestó el dinero o con quienes cerraron el trato para terminar el juego. Conforme ese fin llega se les escucha quejarse de que la gente que contrataron no está lo suficientemente preparada para hacer videojuegos y van y le reclaman a la Universidad. Quién si es Universidad con mayúscula los recibirá poniéndoles esta cara:

Tras las quiebras y diversos fracasos. Los líderes locales de La Industria culpan a las universidades de no preparar lo suficientemente bien a sus egresados e incluso intentan negociar con estas instituciones modificar a su conveniencia los planes de estudio y sacar adelante proyectos en conjunto para poder beneficiarse de su prestigio. La pregunta es ¿A la Universidad le debe de importar el desarrollo de videojuegos?

Yo también estuve ahí. Primero me enojaba que mis maestros de ingeniería en computación no sabian programar y lo único que les importaba era estar al tanto de que ERP se ponía de moda en las empresas locales en esa semana. Me burlaba constantemente de esos maestros y de los alumnos que presumian de ayudarles a administrar bases de datos en esas mismas empresas mientras que maestros de otras áreas permanecían en su mundo sin meterse en problemas con nada ni nadie. Es mas. Me atrevo a decir que un estudiante puede entrar a una carrera como ingeniería en computación y graduarse con honores y aún así no saber absolutamente nada de programación de videojuegos al entrar a una empresa. Pero esto no sucede porque la universidad no sepa enseñar. Ese estudiante puede ser un excelente maestro de alumnos de primeros semestres e incluso podría estudiar alguna especialización mas orientada a la ciencia pero aún cuando consiga un Ph.D (conozco un par de ejemplos) seguiría siendo por completo inutil a la hora de sentarse a programar un videojuego.

¿Pero es acaso que en ese enorme y venerable templo del conocimiento que es la universidad no hay nada ni nadie capaz de ayudar al desarrollo de videojuegos? La respuesta es al mismo tiempo Si y No. Por un lado no hay una sola carrera que sea aplicable a hacer juegos (como en realidad ninguna carrera es 100% aplicable a un único ramo de ninguna industria) pero al mismo tiempo hay muchas fuentes de información valiosa ocultas en el campus y que hay que descubrir. Como leyeron en el párrafo anterior. Pueden cursar una carrera completa y salir siendo unos inútiles para hacer juegos pero si se salen un poco de ese camino trazado que es su carrera podrán encontrar conocimientos verdaderamente valiosos para hacer juegos así como gente de los mas diversa deseosa de ayudarlos en su aventura. Pero al mismo tiempo si se apartan demasiado de ese camino corren el riesgo de perderse en el camino y descuidar sus estudios.

Así que por un lado tenemos a los empresarios o padrinos que no tienen la garantía de que sus empleados van a poder hacer juegos solo por haber terminado la universidad y por el otro tenemos a los estudiantes que no saben si van a poder aprender todo lo que necesitan antes de terminar la carrera. Así que en esta serie que va a ser muy corta solo se hablará de estos dos lados de lo que para algunos parece ser un problema pero que como veremos no lo es. Solo es la forma correcta como debe de operar una verdadera universidad cuyo trabajo es difundir y hacer progresar la ciencia y no servir de oficina de recursos humanos o peor aún, como certificador de la honestidad y pureza espiritual de las personas como algunos pseudoempresarios que no saben nada de computadoras se empeñan en verla.

En la siguiente entrada veremos como la vida del estudiante que quiere dedicarse a hacer videojuegos se enfrenta a dificultades a las que no se enfrentan los estudiantes considerados normales. Les recomiendo que los lean sobre todo si todavía no entran a la universidad o si salieron y piensan regresar dentro de poco tiempo.

Como Equipar tu Centro de Operaciones parte 1

–Configuración Básica: La Trinchera–

Iba a contar una de mis viejas anécdotas pero mejor se las ahorro. Esta entrada va a ser extensa y detallada y puede que necesite mas de una entrada para cubrir el tema. En fin, de lo que les voy a hablar ahora es sobre como construir un centro de operaciones funcional para programadores independientes y demás aspirantes a científicos locos que no tengan recursos para montar grandes instalaciones.

Lo primero que hay que dejar en claro son las condiciones de trabajo. Como me imagino que ustedes son vagos cuyo único espacio disponible es el dormitorio de la casa de sus familiares (no me importa si es de sus padres o sus parejas en turno) o en el mejor de los casos un cuarto alquilado en algún lugar del que no quieran dar muchos detalles. En cuanto a servicios básicos por lo menos tendrá energía electrica y un baño lo suficientemente cercano para poder llegar caminando. Contar con acceso a internet es util pero no del todo indispensable. Y en cuanto a clima basta con tener acceso por lo menos a una ventana y en temperaturas extremas al menos un pequeño abanico (mínimo 10″ de diámetro) para enfriar las computadoras y sacar el aire respirado.

En cuanto a las dimensiones el local debe de medir por lo menos 2 metros por lado o lo suficiente para que las personas que van a trabajar ahí puedan acostarse en el suelo y estirar brazos y piernas sin sentirse incómodos. Como deduzco que la mayoría de ustedes son Forever Alone y si no lo son no se sentirán incómodos con la regla anterior pasemos al siguiente punto.

La altura.- El lugar de trabajo debe de tener un techo lo suficientemente alto para que no puedan alcanzarlo con las manos estando de pie. La altura ideal es lo bastante alto como para alcanzarlo con una miniescalera plegable de dos escalones. Ese espacio alto es muy valioso y casi siempre se desaprovecha. Ahora pasemos a las paredes.

Las paredes.- Deben de contar con contactos eléctricos polarizados y aterrizados (de 3 patas como les dicen en México) para que puedan conectar cualquier aparato eléctrico moderno. Las tomas de corriente deben de ser las suficientes y estar lo bastante cerca unas de otras como para no tener que usar extensiones que atraviesen el suelo y estorben. Las paredes deben de ser lo bastante fuertes para poder perforarse y sostener algunas estructuras pequeñas y por supuesto deben de contar con al menos una puerta para tener acceso y una ventana que permita el paso del aire y la luz natural.

Estas son las condiciones mínimas para permitirle trabajar al menos a una persona. Si cuentan con un lugar mas grande pueden aprovecharlo todo o usar solo una parte pero es importante que ese espacio lo usen solo como su centro de operaciones y nada mas. Ahora pasemos con el mobiliario básico.

Antes de entrar al mobiliario básico es importante dejar bien clara una cosa: En su centro de operaciones deben de ser capaces de trabajar de pie, sentados y acostados y en situaciones muy desesperadas también debe de ser posible dormir por una o dos noches. El estar de pie les permitirá moverse por las instalaciones y usarlas de manera eficiente y casi no ocuparán espacio. Cuando tengan que estar quietos por espacios entre 30 minutos y 3 horas pueden usar una silla con respaldo como cuando ven un video o usan algún tipo de interfaz manual pequeña como un pad de juegos o una tablet. Y si van a hacer alguna actividad que tome mas de 3 horas seguidas como por ejemplo leer, descansar o incluso dormir lo mejor es acostarse. Por lo que necesitarán 3 tipos de sillas y una mesa pequeña. Para hacer esto un poco mas manejable voy a motrar varios niveles en los que puede ser equipado un centro de operaciones (que voy a abreviar como HQ de Head Quarter para ahorrar espacio). Cada nivel incluye todo el equipo de los niveles mas bajos.

HQ nivel básico: Trinchera

Para los que no juegan suficientes FPS de guerra, una trinchera era un pozo mas o menos grande donde los soldados de la Primera Guerra Mundial podían protegerse de las balas y defenderse de cualquiera que intentara acercárse por tierra. El centro de operaciones modelo trinchera es el mas básico para poder trabajar y cuenta con el equipo mínimo suficiente para leer, investigar y hacer proyectos pequeños. Tiene todo que un estudiante de nivel universidad que no requiera herramientas exóticas puede necesitar durante su carrera. El único inconveniente de la trinchera es que es necesario contar con una computadora tipo laptop o tablet. Si cuentan con un equipo tipo Desktop van a necesitar por lo menos el modelo Bunker. Lo mejor de la trinchera es que al igual que las trincheras de verdad que pueden ser excavadas con rapidez y estar listas para la batalla en cualquier lugar y momento este modelo puede armarse y desarmarse en cualquier lugar que cuente con los requisitos básicos como el rincón de una recámara, un cuarto abandonado o una oficina improvisada. Ahora vamos con el equipo.

Equipo de la Trinchera

Piso de espuma.- Existen mosaicos de un material elástico parecido al plástico que son lo bastante suaves para sentarse o acostarse y a la vez lo bastante firmes y resistentes para caminar o pararse sobre ellos. Cubren un área muy buena y son mas baratos que una silla. Son buenos para hacer trabajos acostado o sentado y pueden plegarse para limpiar el suelo. Pueden conseguirlos en tiendas de artículos para casas, tiendas de deportes o si son padres de familia en tiendas de artículos para niños.

Garrafón de Agua.- Existe un proverbio español que no recuerdo palabra por palabra pero que dice que si no dispones de lo necesario para recuperar y desalojar los l\iquidos de tu cuerpo no puedes trabajar ni descansar. Un garrafón de agua a la mano es vital para mantener un mínimo de salud.

Pizarrón pequeño.- Esta es una de las herramientas mas básicas de un desarrollador después de las computadoras. Programar no es solo estar sentado oprimiendo teclas. Hay que pararse para revisar algoritmos, planear estructuras de datos, hacer grafos o ver como se vería un personaje que se nos acaba de ocurrir. Un pizarrón de 60 por 90 centímetros que puede ser de gis (tiza) de cal o para uso de plumones con borrado en seco es suficiente. Pueden encontrar buenos pizarrones en tiendas de artículos escolares especializados y de oficina. Si no encuentran un pizarrón pueden construir uno usando placas de policarbonato, acrílico o vidrio. Los marcadores para borrado en seco trabajan bien en este tipo de materiales. Si solo encuentran estas placas en color transparente pinten el lado opuesto (el que queda hacia la pared) de blanco y usen el lado libre de pintura para escribir. Si van a instalar el pizarrón en la pared pónganlo a una altura en la que lo puedan usar estando de pie. Así será mas facil trabajar.

Banco de dibujante.- En un centro de operaciones es necesario estar de pie la mayor parte del tiempo para no perder movilidad. Un banco alto y acojinado como los usados en dibujo les permitirá estar en una posición tal que conservarán la capacidad de movimiento de estar de pie pero descansarán casi tan bien como al estar sentados. Pueden conseguir buenos bancos en tiendas de suministros para dibujantes o incluso en equipos para restaurantes y bares. Solo asegúrense de que al usarlos sus brazos les quedan a la misma altura que si estuvieran de pie y que el cojín les permita estar sentados sin causarles daños a la salud.

Mesa para laptop.- Estas mesas son sorpendentemente útiles incluso si no cuentan con una computadora tipo laptop. Si la tienen pueden usarla como indican las instrucciones y si no de todos modos sirven para acomodar todo tipo de equipo como teclados grandes, tabletas gráficas, joysticks, gamepads y si son lo bastante marranos hasta pueden comer en ellas. Su altura e inclinación ajustables las hacen perfectas para trabajar de pie o sentado (incluso en el piso) y las ruedas les permiten moverlas o guardarlas cuando no las estan usando sin necesidad de quitarles el equipo. Pueden conseguir este tipo de mesas en lugares donde vendan mobiliario de oficina. Incluso existe una mesa muy parecida usada en los hospitales. Aunque es un poco mas grande es demasiado cara. Pero si les ofrecen una a buen precio no duden en aceptarla.

Tambo de 20 litros.- Los tambos usados para distribuir pintura y productos químicos para construcción son también muy útiles en la oficina de un desarrollador sin recursos. Ocupan poco espacio, son muy resistentes, pueden sentarse en ellos cual si fuesen bancos o pararse para alcanzar cosas altas y su interior está lo bastante bien protegido como para guardar respaldos en discos ópticos o cables de computadoras durante años. Otro uso que pueden tener es el de soportar el garrafón de agua para que tenga una mejor altura y no dejarlo directo en el piso. Estos tambos junto con sus tapas los pueden conseguir en las ferreterías y las tiendas de artículos de construcción o si son vagos como yo de seguro encontrarán uno en cualquier depósito de basura o construcción descuidada. Si lo compran asegúrense que no se rompa cuando se paren sobre él. Sobre todo tengan cuidado con las tapas porque algunos de los botes que venden como «multiusos» no son tan fuertes como los usados para envasar pintura.

Regulador de voltaje.- Si tienen un mínimo de aprecio por cualquier aparato electrónico deben siempre de conectarlo a un regulador de voltaje de buena calidad. En México y muy probablemente en el resto de latinoamérica la corriente eléctrica tiene variaciones de mas menos 10% en condiciones normales. Esto es lo bastante fuerte como para quemar el sistema eléctrico de un abanico fabricado en Estados Unidos y no les digo lo que puede hacerle a una computadora. No se crean ese mito que los adaptadores AC de las laptops protegen contra variaciones de voltaje porque es mentira. Yo llevo 5 años con la misma laptop y 12 años con el mismo abanico y ambos siguen funcionando tan bien como cuando los compré. Algunos consejos para elegir un buen regulador son buscar uno que tenga una capacidad mínima de 1000 volts-ampere (no confundir con Watts), que cuente con supresión de picos (surge supressor) y que tenga por lo menos 6 contactos polarizados y aterrizados lo bastante separados entre si para conectar muchos dispositivos con su respectivo adaptador AC. Y no se confundan, por alguna razón hay regiones en latinoamérica en las que los vendedores son incapaces de distinguir entre un verdadero sistema de supresión de picos y un insignificante multicontacto que no cuente con la mas mínima protección electrónica aparte del aislante del cable de corriente. Los reguladores pueden parecer caros pero al menos pueden estar seguros de que sus equipos van a trabajar con un m\inimo de fiabilidad y que esta ser\a seguramente el equipo electr\onico que mas tiempo le tomar\a quedar obsoleto. Algunos de mis reguladores tienen mas de 15 a\nos y siguen en funciones.

La Caja del Caos.- Este es el último de los accesorios para equipar el centro de operaciones modelo Trinchera. La Caja del Caos puede ser una simple caja de cartón grande aunque lo mejor es que sea una de esas cajas transparentes de plástico y con tapa que usan las amas de casa para guardar ropa y sábanas. La regla para usar esta caja es simple. Cualquier cosa que no estén usando en ese momento va directo a la Caja del Caos. Así como cualquier cosa fuera de lugar o que no tenga una buena razón para estar donde está. Por ejemplo cables, memorias extraibles, papeles, accesorios y casi cualquier cosa que puedan sujetar con una sola mano. En caso de cosas frágiles como adaptadores de corriente o gamepads análogos guárdenlos en cajas mas pequeñas antes de lanzarlos a la Caja del Caos. Esto les permitirá mantener su centro de operaciones limpio y ordenado a la vez que sabrán donde buscar cualquier cosa que se les pierda. Otra ventaja que tiene este sistema es que da una idea de que tan bien administramos la instalación. Si la caja se desborda o no puede cerrarse es señal de que tienen que darle mantenimiento y organizar mejor sus cosas.

Consideraciones Finales

Voy a dejar los modelos de centro de operaciones Bunker y Fortaleza para otras notas porque voy a necesitar demasiado espacio para describirlos. Pero antes de que prejuzguen. Estos 3 modelos existen porque responden a necesidades diferentes. La Trinchera es suficiente para trabajar un dia entero e incluso pasar una noche. Tiene todo lo necesario para investigar, escribir programas pequeños y hacer diseños en tabletas gráficas de gama media y si pueden captar una señal WiFi desde donde están comunicarse con quienes quieran. Pero la ventaja que este modelo tiene sobre los otros es su bajo costo y rapidez de instalación. De hecho yo actualmente estoy limpiando mi centro de operaciones y tuve que replegarme en un rincón a modo de Trinchera y es desde ahí que escribo estas lineas. Otro consejo es que si van a comer en una trinchera tengan siempre a la mano una bolsa desechable para tirar los residuos y una bandeja para mover los platos y vasos sucios y asignen una hora para sacar todas esas cosas y si pueden lávenlas. Los trastos sucios pueden dejar inoperante un centro de operaciones así como la ropa sucia y los cables tirados en el suelo. En las siguientes entradas vamos a ver como armar el bunker y la fortaleza y recuerden que todos tienen un uso y propósito. Ninguno de ello es elección mala.

¿Qué es un Buffer de Datos?

–Cuando no tienes tiempo de esperar al mensajero–

Un buffer es una memoria en la que se almacenan datos de manera temporal para ser procesados. Se utiliza cuando los datos de entrada llegan a una mayor velocidad de la que podemos procesarlos o cuando llegan de manera tan irregular y esporádica que no resulta conveniente dedicar tiempo y recursos a esperarlos. Algunos ejemplos de buffers son los sistemas de entrada del teclado que almacenan las teclas presionadas, los buffers de video en los que se prepara el siguiente cuadro de animación para presentarlo en pantalla y otros tantos mas que como usuarios no creo que sean muy conscientes de lo que son o que hacen. Otra definición de buffer es la de una región de memoria que se usa como área de intercambio asíncrono entre procesos.

Como se han de imaginar, los buffers no nacieron junto con las computadoras sino que son una abstracción del mundo humano para explicar un concepto. De hecho una traducción un tanto oscura de la palabra Buffer es «Colchón» y se relaciona con los antiguos sistemas de reparto y entregas. Desde la época de los vaqueros y los inicios de la aviación los encargados de los sistemas de reparto y entregas descubrieron que podían ahorrarse mucho tiempo si en lugar de hacer que los mensajeros se detuvieran para entregar la mercancía colocaban uno de esos grandes colchones donde podían dejar caer los paquetes sin detenerse. De ese modo no era necesario dejar a alguien en la puerta esperando al mensajero y los empleados podían ir con toda calma y a una hora predeterminada a revisar estos buffers para ver si había llegado algún paquete. Un sistema muy parecido se utilizó en algunas fábricas y bodegas de muchos pisos en los que dejaban caer los productos por una especie de pozo vertical en cuyo fondo había un cojín y una pequeña puerta por la que se podían entregar los productos. En la actualidad las máquinas expendedoras automáticas usan buffers en los que dejan caer tanto el cambio en monedas como la mercancía de modo que el cliente no tenga que poner la mano y esperar a que estos caigan. Otro ejemplo mas sencillo es el viejo buzón de correos en el que el cartero puede dejar documentos y los habitantes pueden ir a revisarlos al regresar a su casa.

Los buffers son muy importantes y nos pueden ayudar a resolver una enorme cantidad de problemas que me llevaría toda la nota explicarles. Existen muchos tipos diferentes de buffers, hay algunos que funcionan como stacks y que sirven para recorrer estructuras de datos como grafos y árboles, otras trabajan como colas de procesamiento y nos dejan leer datos antes de que se pierdan, otros buffers mezclan datos de muchas fuentes y los combinan e incluso los buffers se relacionan con la recursión. Para hacer un buffer lo mínimo que necesitamos son 4 cosas. La primera obviamente es un espacio en memoria que vamos a usar como buffer. La segunda es un puntero o variable que almacene la dirección de memoria donde se encuenta, la tercera es un valor que indique la longitud máxima del buffer y la última es un índice o conjunto de índices que nos indiquen en qué localidad del buffer escribir los datos de entrada y leer los datos de salida. La combinación de la longitud máxima y los índices nos dirán si el buffer está lleno o vacio. Y aunque la administración de esta información suena muy complicada ya verán que existen muchas técnicas para manejarlos de manera eficiente por lo menos en ensamblador.

Problemas de los buffers:
Underflow y Overflow

Para los que no han leido las entradas mas elementales, el overflow es cuando hay demasiados datos en el buffer y los nuevos datos que llegan al no poder ser almacenados se pierden. El Underflow es lo contrario, cuando queremos obtener datos y el buffer está vacío. El Underflow es mas peligroso de lo que suena en ciertas aplicaciones como por ejemplo la grabación de datos en medios físicos como los discos. Si ocurre un buffer underflow la pieza puede quedar arruinada o en el caso de audio y video en tiempo real la comunicación puede presentar cortes. Es por eso que cada que se va a tener acceso al buffer ya sea para leer o escribir datos en él es necesario verificar que no van a ocurrir ninguna de estas dos condiciones. Pues si no se hace esta prueba no solo puede haber pérdidas de datos entrantes o cortes en el flujo de información sino que en casos de buffers muy mal diseñados puede haber problemas de sobreescritura que acaben por afectar otros datos importantes del programa y en casos muy dramáticos causar un fallo de protección de memoria o una caida completa del sistema. Les aconsejo que si consideran que el buffer puede ser peligroso lo coloquen en una región de la memoria alejado de los datos mas críticos.

Por suerte existe una técnica que nos puede evitar al mismo tiempo el problema del overflow, underflow y la sobreescritura. Esta técnica involucra máscaras de bit. El primer consejo es hacer que los buffers siempre tengan una longitud igual a una potencia de 2. Pueden ser 2,4,8,16,32,64,… Para el ejemplo vamos a tomar un buffer de 8 elementos. A partir de su dirección inicial, las siguientes 8 localidades se pueden numerar como 0,1,2,3,4,5,6 y 7 y los índices tanto de lectura como de escritura nunca deben de ser mayores que 7 ni menores que cero. Lo que cualquier programador que no sabe de ASM haría (y los que manejan leguajitos de ‘objetos y métodos’ ni siquiera harían esto) sería comprobar que ambos índices estuvieran dentro de ese rango antes de acceder al buffer y mandar un mensaje de error si esto no se cumple. Pues bien, como nosotros programamos en ensamblador nos basta con comprobar el estado de los bits que estén por encima de los 3 menos significativos. O lo que es lo mismo hacer una máscara AND con 0FCh (para índices de 8 bits). Si el resultado de esta operación es diferente de cero significa que los apuntadores están fuera del rango de cero a 8. Recuerden que los valores negativos tienen el bit mas significativo activado. De este modo si queremos detectar esta condición y encender una bandera que indique que hay un error basta hacer un AND seguido de un SETNZ. Si quisiéramos forzar a que los índices siempre se mantengan dentro del rango de 0 a 7 podemos hacerles un AND con un 3. Esto es especialmente importante para los buffers en forma de cola o los interesantísimos buffers circulares.

Voy a dejar el tema de los buffers circulares y de los buffers que funcionan como stacks y queues para otro dia porque son temas muy complicados para solo mencionarlos. De momento solo mencionaré que los buffers de Stack tienen un mismo índice que se usa tanto para leer como para escribir datos y que se incrementa o decrementa dependiendo de la operación que se haga. En los buffers de queue en los que los primeros datos en salir son los que mas tiempo llevan dentro del sistema el asunto es manejar dos índices uno para cada operación. Cuando ambos índices son iguales significa que el buffer está vacio y cuando la distancia entre ellos es igual a la longitud máxima del buffer este ya está lleno.

Para hacer buffers queue es necesario entender lo que es un buffer circular. Un buffer circular puede aceptar una cantidad infinita de datos pero solo puede recordar tantos datos como lo indique su longitud máxima. Los datos mas viejos se pierden por sobreescritura. Para hacer un buffer circular primero se define una extensión de memoria cuya longitud sea una potencia de dos y luego el puntero de entrada se mantiene dentro de ese rango por la fuerza por medio de máscaras AND. De ese modo no importa cuantas veces lo incrementemos ni durante cuanto tiempo el índice permanecerá dando vueltas en esa extensión de memoria sin salirse. Este tipo de buffers son muy importantes en la programación de videojuegos y en la animación de objetos articulados. Un Queue en realidad es un buffer circular que tiene un segundo puntero que va ‘persiguiendo’ al puntero de entrada de datos. Y es importante que un buffer queue sea en esencia un buffer circular porque he visto a muchos estudiantes que crean buffers capaces de caminar a todo lo largo de la memoria del sistema y aplastar por sobreescritura el resto de las variables cual si se tratara de las orugas de un tanque. Si el buffer queue se hace de manera circular se va a mantener en su lugar sin peligro de sobreescribir otras estructuras. Y esto es porque en los buffers queue los índices siempre se incrementan.

Por hoy no me voy a poner a trollear. Solo voy a comentar que voy a estar al pendiente de un juego que me dijeron que iba a salir publicado en este último cuarto del 2012. Espero que quienes lo están haciendo puedan terminarlo y recuperen su inversión, porque si siguen como hasta ahorra puede que a esta empresa le llegué su «Ultimo dia en La Industria». Trollface.

¡No me gustan los engines ni las aceleradoras gráficas!

–O al menos no me gusta el uso que se les da–

En realidad no es que no me gusten los engines ni el hardware de aceleración grafica en si. Lo que desprecio es como pseudodesarrolladores creen que solo porque tienen acceso a estas tecnologias no necesitan saber programar. Pero antes de entrar a la trolleada en serio vamos a ver primero que es cada una de estas cosas.

Lo primero que hay que dejar en claro es que las computadoras (y las consolas de videojuegos técnicamente son computadoras) pueden construirse para poder hacer cualquier cosa medianamente bien que es lo que se llama propósito general o ser optimizadas para hacer lo mejor posible unas pocas tareas que es el caso de las de propósito específico. Las consolas de juegos y las tarjetas gráficas para computadoras cuentan como hardware de propósito específico. Y en el caso de la aceleración gráfica por hardware esta es tan vieja como los mas antiguos sistemas de Atari de finales de los setenta. El NES contaba con un circuito PPU (Picture Processing Unit) que le permitía hacer costosas operaciones de manejo de sprites independientemente de su modesto CPU 6502 de 8 bits. El primer Playstation contaba con un modesto coprocesador con capacidad Fixed Point y un decodificador de video independientes de su procesador principal y cualquier computadora actual con sistema de video independiente de la tarjeta principal tiene su propia capacidad para procesar datos de video y hacer cálculos vectoriales que ayudan mucho en los gráficos 3D. Este hardware de propósito específico permite bajar costos de fabricación de los equipos y reducir los tiempos de desarrollo y sin ellos las consolas de videojuegos hubieran sido tan costosas como las computadoras y no habría sido buen negocio venderlas.

Explicar lo que es un engine es bastante mas dificil. Lo que al principio eran unas pocas rutinas de código reutilizable se han convertido en enormes software de desarrollo comparable con los sistemas operativos. Cuando me preguntan lo que es un engine suelo decirles que es lo que queda de un videojuego cuando le quitas todo el arte, el diseño y dejas solo el código aburrido. Pero los modernos engines capaces de procesar scripts hechos en algún lenguaje interpretable han hecho que la frontera entre el código que conforma el engine y el código que es procesado por el engine se pierda. Para explicarme voy a contar mi teoría sobre el origen de los engines.

Programar es dificil, pesado y confuso. Una vez que un código funciona bien es mejor no solo conservarlo sino volverlo a usar tanto como podamos. Los programadores no teclean todo desde cero cada vez que van a comenzar un nuevo juego sino que llaman rutinas que crearon meses o incluso años atrás que están bien seguros de que les funcionan. Y cuando quieren implementar algo nuevo nunca incorporan el nuevo código a un juego sin antes asegurarse de que la mejora trabaja bien con todas sus antiguas rutinas.

Como dije hace mucho en la entrada «Códigos e Invocadores», ese conjunto de rutinas de código que funcionan son el ejército del programador. Y como buen comandante de este ejército debe de saber darles órdenes en plena batalla. Y por esto se inventó el Script. Un script es un trozo de código interpretable que es procesado por esas rutinas de software. Y se dice que nació cuando un programador se fastidió de tener que hacerle cambios a sus programas todo el tiempo. Creó un sistema que en lugar de tener que ser reprogramado cada vez era capaz de seguir instrucciones sencillas dictadas en unas pocas lineas. Esta forma de programar se adaptó rapidamente al mundo del desarrollo de juegos de modo que un mismo conjunto de rutinas en combinación con un sistema para interpretar scripts pudo usarse en muchos títulos diferentes sin necesidad de recompilar nada. Bastaba con crear arte usable y teclear algunos scripts y ya teníamos un juego nuevo.

Con el tiempo, las empresas que lograron construir sus propios engines pudieron hacer juegos muy buenos y le dedicaron mas tiempo a crear historias y personajes elaborados y menos en leer libros de programación y matemáticas. Pero no había problemas porque el programador que había creado el engine trabajaba junto con ellos y podían ir a consultarlo cada que tenian alguna duda. Y como era de esperarse cuando otros les preguntaron sobre como hacian juegos tan buenos no faltaron millonarios que ofrecieron dinero a cambio de los derechos de uso de esos engines. Y así nacieron los sistemas de desarrollo que conocemos hoy.

La pregunta obligada antes de soltar al troll es ¿Porqué tanto desprecio a estas dos tecnologias sin cuya existencia los videojuegos no hubieran podido progresar? La respuesta es sencilla: ¡Hay desarrolladores ineptos que creen que estas tecnologias se crearon para que ellos no tuvieran que programar!

No es la flecha sino el indio…

Los que me conocen desde hace tiempo saben que he estado programando desde los tiempos en que se dio la transición de los 16 a los 32 bits en PC y que muchos de mis maestros (y no me refiero a los de la escuela) fueron programadores de sistemas de 8 bits. En esos tiempos si uno quería programar un juego no había otra que hacer la lógica principal con C/C++ y programar las rutinas gráficas mas avanzadas directo en ensamblador. En el caso de las consolas no había de otra que programar en ensamblador porque las memorias de los antiguos cartuchos eran demasiado caras. En ese tiempo ser programador de videojuegos era pertenecer a una casta superior que se hallaba muy por encima de cualquier otro trabajador de las computadoras. Pues si uno quería hacer juegos, sobre todo juegos 3D debía dominar no solo la programación a nivel muy avanzado sino también saber matemáticas mas avanzadas que las que se ven en cualquiera de las ingenierias a nivel universitario. Y por supuesto la única manera de que un juego 3D se viera bien en un 486 que corría con DOS era metiendo todo el código del juego en un EXE de apenas 100 o 200 kilobytes.

Pero un día llegaron las aceleradoras 3D. Artículos de lujo que muy pocos podían pagar y los programadores tuvieron que hacer juegos que si bien pudieran aprovechar este nuevo hardware si lo detectaban aún pudieran seguir corriendo en equipos que no lo tuvieran. Y eso fue hasta que salieron juegos infames que pedian este tipo de tarjetas como requerimiento mínimo para funcionar. Como era de esperarse hubo juegos que no vendieron lo esperado gracias a esto como fue el triste caso de Descent 3.

Y el asunto no terminó ahi, sino que como este hardware en sus inicios era cerrado no había manera de hacer rutinas propias para él y la única salida era recurrir a bibliotecas (por las que había que pagar derechos) para poder usar este tipo de hardware. Al mismo tiempo comenzaron a surgir bibliotecas cerradas de funciones que te permitian llamar a estos sistemas sin mas necesidad que meter un #include al inicio del código. La gente comenzó a creer que hacer juegos 3D era cosa de tener una computadora con un hardware determinado y no creian cuando se les decía que 3D en realidad eran algoritmos y matemáticas. Como prueba incontables empresas de videojuegos compraron costosas computadoras Silicon Graphics que nunca supieron como programar porque creian que tan solo por comprarlas iban a poder hacer juegos que se vieran como el Donkey Kong Country de Rare. ¡Hubieran podido hacer un juego con ese mismo nivel de gráficos conectando sus humildes PC en un cluster y sentando frente a estas a un programador que supiera un mínimo de Ensamblador x86 y Algebra Lineal!

Pasaron algunos años para que el hardware de aceleración gráfica se estandarizara lo suficiente para no tener que crear rutinas para cada tipo de tarjeta en el mercado pero todavía queda mucha gente que cree que las gráficas 3D las hace el hardware sin intervención del programador. Puede que tener una PC poderosa ayude a renderear video mas rápido o correr software de desarrollo mas avanzado pero si no sabes un mínimo de programación la computadora mas poderosa te resultará inutil.

Ahora vamos con los engines. Lo primero que hay que tomar en cuenta a la hora de intentar acortar los tiempos de desarrollo licenciando un engine es que es mucho mas dificil para un programador entender el código de escrito por otro programador que construir el suyo desde cero. Lo segundo es que hay diferentes tipos de licencias para estas cosas, unas van desde dar solo permiso para crear juegos usando herramientas visuales y un poco de scripting pero otras incluyen acceso al source code y derecho a usar partes de él en otros proyectos bajo estrictas limitaciones.

En si los engines son buenos si se saben usar. La trampa de los engines consiste en que muchísima de la gente que los licencia cree que no necesitan saber programar para usarlos cuando es todo lo contrario. Para que me entiendan usar un engine sin saber nada de programación gráfica es como comprar un barco y no saber navegar. Primero pueden sentirse muy poderosos por tener una pieza de equipo costosa y muy avanzada, pero pasado un tiempo de usarlo se van a perder en un mar de problemas que no van a saber como resolver y al final se irán a pique irremediablemente. No voy a mencionar gente que ha perdido dinero por pagar por estas cosas sin saberlas usar porque no es dificil encontrar estos casos en internet. Lo que si les voy a decir es que he visto una cantidad impresionante de quinceañeros que no saben siquiera lo que es un vector y que creen que van a poder hacer avanzadísimos juegos 3D sin tener que saber nada de programación. Esto es un espejismo.

Una cosa que sabe cualquiera que haya leido un libro de mantenimiento de sistemas es lo dificil que resulta entender un código escrito por otras personas, si a eso le sumamos que para entenderlo hay que saber conceptos matemáticos que no se ven en cualquier ingeniería y si a eso a la vez le sumamos que con el pretexto de la portabilidad estos engines pueden tener una misma rutina implementada de maneras muy diferentes y si todavía a eso le sumamos que le vamos a tener que «desensamblar» algunas partes tan solo para poder optimizarlo el resultado es que vamos a necesitar un modesto equipo formado por un experto en mantenimiento de sistemas, un maestro de matemáticas universitarias, un administrador de desarrollo de software y alguien que sepa hacer buena ingeniería inversa tan solo para USAR un engine a un nivel minimamente redituable. Pero lo que he visto en mi experiencia cercana es que quienes licencian un engine no solo no les interesa saber nada de programación sino que ni siquiera les interesa aprender sobre su funcionamiento. O como escuché a uno de estos decir en un foro que prefería pagar por un engine ya hecho en lugar de programarlo el mismo porque «eso le daba soporte y garantía». ¿Tan poca confianza tienen en sus propios códigos?.

Otro error bastante nefasto que he visto cometer a muchos que juegan con dinero es que creen que porque otra empresa afamada al otro lado del planeta usó un engine X ellos van a poder hacer juegos igual de buenos si también lo licencian. Y el resultado es que no encuentan personal que pueda usarlos de manera confiable. El problema es que estas tecnologias por lo regular son software propietario al que muy pocos tienen acceso y cuando es libre o tiene una licencia menos restrictiva nada garantiza que quienes declaren manejarlo lo manejarán bien. Como ya dije he visto a muchos aficionados que no saben las cosas mas elementales de matemáticas creer que dominan un engine tan solo porque pudieron instalar la versión de prueba por 30 dias y lograron correr y medio modificar los ejemplos incluidos en el tutorial básico. Por cierto, quienes caen en esta categoría de seguro reconocen al ilustre personaje de la segunda imagen de esta entrada. De hecho si yo llego a licenciar un engine propio (el que lo voy a crear no está sujeto a discusión) incluiré en el costo de la licencia el salario de un especialista que asesore de manera presencial. Solo así podré garantizar al cliente que va a obtener aquello por lo que pagó y no tenga que traerse gente de esas regiones de nombres impronunciables donde se les hacen chiquitos del frio y que quién sabe si puedan o no con el trabajo, como uno cuyo perfil de linkedin me acabo de encontrar y al que no me aguanto las ganas de hacerlo víctima de mis mas infames tácticas de trolling.

Ya para terminar solo me queda darles dos consejos: El primero es que las aceleradoras gráficas son hardware y como hardware puede ser programado directamente en ensamblador o su lenguaje máquina equivalente. Así combinarán la velocidad del ASM con la mejora del hardware y que mejor que si aplican el algoritmo mas eficiente que encuentren. En cuanto a los engines no se olviden que no basta con ser capaz de correr los ejemplos y modificar los assets. Necesitan saber optimizar y para eso no basta con leer los manuales sino saber las matemáticas básicas tras las gráficas 3D y aspectos muy particulares de la plataforma en la que está corriendo. Y si se consideran a si mismos programadores mas les vale seguir estos dos consejos y dominar esas tecnologias antes de que esas tecnologias los dominen a ustedes.

¿Quién debe entrenar a los desarrolladores de videojuegos?

–La Escuela que puede existir o puede no existir–

Existe una leyenda urbana en la ciudad de Monterrey México sobre un misterioso maestro de artes marciales que cada cierta cantidad de años publicaba anuncios muy discretos en los diarios en los que invitaba a practicantes de cualquer disciplina de combate así como a cualquier interesado en la autodefensa a entrenar con el. Quienes lo conocieron comentaban que se trataba de un anciano muy sabio que impartía sus clases en su propia casa. Nunca se supo exactamente que estilo de combate era el suyo pero ponía mucho énfasis en siempre estar preparado para pelear y sobre todo ser discreto y silencioso como una sombra a la vez que humilde para no meterse en problemas.

Dos anécdotas sobre este sabio llegaron a mis oidos. La primera fue sobre alguien que le preguntó como debía de ir vestido para los entrenamientos. El sabio le dijo que debia de llevar la misma ropa con la que diario salía a la calle, pues los delincuentes no iban a esperar a que se pusiera su uniforme de entrenamiento para atacarlo. La segunda era la que le da el subtítulo a esta entrada. Se dice que el maestro había colocado un pequeño letrero en la entrada de su casa para orientar a los que buscaban la escuela. Cuando se despedía de sus últimos alumnos les dio una lección final. Se dirigió al letrero y señalandolo les dijo:

–«No se olviden que esta escuela puede existir…»–
Y luego descolgó el letrero del frente de su casa, lo ocultó de la vista y sentenció sereno:
–«…o puede no existir.»

No se cual fue el destino de este personaje pero estoy seguro de que él o alguno de sus discípulos sigue entrenando e impartiendo sus técnicas de combate en el anonimato casi absoluto, pues otros que dijeron haber asistido afirmaban que en el mismo lugar había otros alumnos que con solo verlos uno estaba seguro de que habian dedicado toda su vida a pelear. En fin, esta historia la cuento porque preparar a otras personas para que nos ayuden es una necesidad primaria en el mundo de los negocios de tecnología y al mismo tiempo es donde he visto que se cometen los peores abusos contra aquellos que quieren iniciarse en la programación.

Todos los que nos hemos sentido incapaces de satisfacer nuestras ambiciones hemos fantaseado alguna vez con encontrar a uno de estos maestros ocultos que nos enseñara a vencer nuestras limitaciones, no importa si se trata de un instructor de artes marciales que nos entrenara para pelear, un experto en finanzas con sombrero de copa que nos mostrara como hacer buenos negocios o en nuestro caso un programador con implantes cibertéticos que nos revelara el secreto para que las computadoras hagan nuestra voluntad. Y el primer problema que nos encontramos en esto de programar es el siguiente:

¿Quién es el responsable de entrenar a un desarrollador?

Las cosas mas humillantes y horribles relacionadas con el mundo de las computadoras están relacionadas con entrenamiento, capacitación y certificación de personal. Jóvenes cursan carreras completas donde no ven nada de programación. Universidades dejan de lado la enseñanza de las ciencias para proveer a empresas locales de administradores de bases de datos. Empleados comprometen el ingreso futuro de años a cambio de autofinanciarse una capacitación sin la cual no se les permite entrar a trabajar en UNA determinada empresa, empresas pierden dinero capacitando empleados que los abandonan y los autodidactas se encuentran con que a nadie le interesa lo que saben hacer porque nadie «los respalda». Lo primero que tenemos que dejar en claro para ver de quién es la responsabilidad de entrenar a un desarrollador es quien es el que mas se beneficia con este aprendizaje.

¿Y quién se beneficia de los conocimientos de un desarrollador? Ya se que me van a decir que el principal beneficiado de los conocimientos del desarrollador es él mismo. Pero seamos objetivos.Por muchos conocimientos que un desarrollador individual tenga estos no le van a dar de comer solo por tenerlos. En cambio cualquiera que le invierta un salario sabe que va recuperar su inversión y puede calcular un margen de ganancia. Por otro lado no se puede ver a un desarrollador como una simple maquinaria a la que le invertimos dinero en mejoras pues simplemente los empleados aunque sean muy leales no son propiedad de la empresa como los activos.

Al final cada quien tiene sus ideas. Unos dicen que la universidad es la responsable de educarlos, pero como he dicho en series anteriores la Universidad está ahí para hacer ciencia y difundir la cultura y no para ser una oficina de recursos humanos. Otros dicen que las capacitaciones deben ser dadas por organismos certificadores en tecnología pero eso además de caro limita a los técnicos a usar cierta tecnología perecedera y no los deja lo bastante preparados para trabajar en una empresa determinada. Un desarrollador podría capacitarse a si mismo con una fuerte inversión de dinero, tiempo y voluntad pero nada garantiza a quien lo contrate la calidad de esa autopreparación. Por lo que al menos en el desarrollo de juegos solo queda un único responsable:

Quienes son responsables de capacitar a los desarrolladores de juegos son las propias empresas. ¿Alguna vez se han preguntado porqué los japoneses pudieron crear una verdadera industria de videojuegos en una era donde estos todavía no eran tan buen negocio como ahora? En los ochenta no existian todas las cosas que hay ahora para apoyar a «la industria». Lo que voy a decir puede hacer enojar a algunos otakus e incluso incomodar a algunos japoneses que entiendan mi español neutral pero una de las razones fue porque la que las empresas japonesas de videojuegos no confiaban demasiado en la preparación académica de sus ingenieros.

En esta parte me iba a poner a hablar de la relación entre universidad y empresa en Japón pero eso requeriría demasiado espacio. De momento solo necesitan saber que las empresas de ese pais no esperaron a que las universidades les resolvieran sus problemas y en el caso de SEGA y Nintendo estos fundaron instalaciones propias donde capacitaban a sus trabajadores de manera constante. Por si fuera poco en paises como México las leyes laborales especifican muy claro que la capacitación debe de correr por cuenta de la empresa que contrata al empleado. Y aunque los japoneses tienen fama de inteligentes no creo que lo sean tanto como para aprender en una capacitación de algunas horas a la semana lo que un occidental no aprende en cuatro años de carrera de desarrollo de juegos y un par de maestrias especializadas en el tema.

¡Negarte a entrenar a alguien por miedo a que otros se beneficien de ese conocimiento no es honorable!

La necesidad de contar con instalaciones de entrenamiento no es privativa de las grandes empresas. También es necesaria en grupos independientes sin importar su tamaño o recursos financieros. Y en el caso de los grupos relacionados con las computadoras tienen como ventaja el manejo de información. Por cierto, he escuchado que la principal razón por la que muchos grupos no quieren entrenar a sus nuevos miembros no es la falta de dinero o el tiempo que podrían invertir en hacer cosas productivas. ¡El peor miedo que tienen algunos es que sus entrenados se vayan a otra empresa con los conocimentos aprendidos! Esto no solo egoista sino completamente absurdo. Y tan solo pensar en ese tipo de gente me ha hecho ir por mi frasco de antiácidos masticables. No digamos que estas capacitaciones no tienen el mas mínimo valor currircular ante ninguna autoridad del gobierno o que la información relacionada con tecnología caduca muy rápido. Sino que además la capacitación puede llegar a ser tan personalizada que aunque intenten aplicar esas técnicas en otra empresa estas no les servirán de nada. En resumen, es la empresa la que tiene la obligación de capacitar a su personal y lo único que puede exigir a cambio es un mínimo de preparación que garantice que va a ser capaz de aprender si es posible con la menor inversión de recursos..

Esto nos lleva a la historia del principio. Y a la famosa frase de «Esta escuela puede existir o puede no existir» Yo estoy seguro de que a quienes aprendieron a pelear con maestros ocultos como estos nunca les interesó obtener un documento que probara que habian entrenado con él y aunque les hubiera dado algún tipo de reconocimiento de seguro solo unos cuantos iniciados comprenderian su significado. Pues el si habian o no aprendido a pelear era ello que solo sabian ellos mismos y lo confirmarian cuando se vieran en una situación de vida o muerte. Lo que quiero decir es que en el caso de las capacitaciones no es bueno ir por ahí cosechando certificados, papeles o documentos sellados, esos son buenos para hacer trámites gubernamentales o mantener a los padres tranquilos porque cuando pongas a prueba tus habilidades nada de eso te va a ayudar. En el momento que alguien te pide un papel o te condiciona el salario por causa de este sabrás que estás ante una persona que no tiene honor y tú tampoco lo tendrás si aceptas sus condiciones y trato abusivos.

Ya para irme los dejo con otra frase de otro de estos sabios errantes que pudo o no pudo ser el del inicio de esta historia y que deja bien en claro el verdadero valor de los reconocimientos sociales:

Se dice que en una cierta escuela de artes marciales había un maestro muy fuerte y habil que llevaba al límite las capacidades de sus alumnos y los hacía practicar el combate todos los dias. Al final de una clase uno de sus discípulos se le acercó y lo cuestionó sobre el porqué si entrenaban tanto combate nunca los había preparado para ir a pelear al campeonato mundial donde podían ganar fama y muchos premios. Con seriedad y hasta con algo de desprecio el maestro se puso firme y le dijo lo siguiente:
–«Sabes, una noche vas a ir por la calle con tu familia y un grupo de pandilleros drogadictos y armados los van a atacar. ¡Esa noche vas a luchar por tu vida y la de tus hijos y esa va a ser para ti la pelea para ganar el Campeonato Mundial!

Como Contratar Desarrolladores Talentosos

–El caso de Square – Enix en Latinoamérica–

Existe una pequeña fábula que si son gamers de seguro les resultará familiar. Narra la historia de un terrible y poderoso monstruo al que nadie había logrado vencer. Varios líderes enviaron a sus ejércitos tan solo para ver como estos eran aniquilados. Hasta que un día apareció un guerrero de origen desconocido que desafió al gran monstruo y tras un combate interminable logró vencerlo. Cuando el héroe estaba por asestarle el golpe mortal para acabar con su existencia la bestia le suplicó lo siguiente:
–Por favor. Te pido que me ayudes. Mi mundo está siendo atacado por una fuerza maligna que quiere destruirnos a todos.
Extrañado por tal petición el guerrero bajó sus armas y le preguntó:–«Y si necesitabas que te ayudaran. ¿Porqué atacaste y mataste a todas las personas que se te acercaron?». Cuestionamiento al que el monstruo contestó con gran respeto:

–Te pido este favor porque tu fuiste el único capaz de derrotarme. ¡Y porque para vencer a esa fuerza solo puede ayudarme alguien que sea mas fuerte que yo!

La historia no termina ahí, mas adelante el héroe ayuda al monstruo a recuperarse y hace equipo con él para para juntos enfrentarse a esa fuerza maligna que amenaza su mundo. Y lo de la referencia a los videojuegos viene porque en muchos de ellos hay personajes, sobre todo jefes que cuando son vencidos por el jugador, este tiene la opción de agregarlos a su grupo de aventureros. Hay muchos ejemplo pero uno de los primeros que recuerdo es el de Alucard de Castlevania III Dracula’s Curse, quien tras enfrentarse y ser derrotado por Trevor Belmont le pide a este que por favor le ayude a detener a Drácula, quien por si fuera poco además es su propio padre.

Esta historia me causó en ese entonces una mezcla de respeto y admiración. Pues el aceptar que alguien es mas fuerte que nosotros, sobre todo luego de que nos ha vencido de manera indiscutible no es para nada facil. Lo mas común sería enojarnos con quien nos venció y esperar el mejor momento para la venganza. Pero ahora muchos años después reflexiono y me doy cuenta de que la única manera objetiva de buscar a alguien en cuya fuerza superior nos podamos apoyar es esa. O como cuando colocamos una escalera en la pared y la sacudimos fuerte para asegurarnos de que no nos va a dejar caer cuando la escalemos.

En fin, esta historia del monstruo que encuentra a su poderoso aliado de esta manera tan controversial viene al caso porque acabo de ver un caso en la que una empresa usó esta técnica aunque de manera muy discreta. Cuando esta empresa consideró abrir oficinas en latinoamérica se encontró con que tenía que instalarse en un lugar donde pudiera encontrar buenas condiciones y sobre todo personal capacitado. Así como también identificar a los mejores talentos locales de esa región para incorporarlos a su planta laboral lo mas rápido posible. Esta empresa siguió la misma técnica que la del monstruo de la fábula. Pues en lugar de anunciarse en los medios y publicar ofertas de empleo lo que hizo fue organizar un concurso cuyos únicos requisitos fueron ser habitante de latinoamérica y crear un producto que cumpliera con ciertos requisitos técnicos muy específicos. El premio en si apenas era de unos pocos miles de dólares pero la verdadera recompensa para los participantes era la de poder acercarse a una empresa tan importante y mostrar sus habilidades de la manera mas objetiva posible. Y para la empresa que organizó este evento las recompensas fueron mayores: Pues por mucho menos dinero del que le hubiera costado contratar despachos de recursos humanos especializados en todos esos paises pudo obtener toda la información que quería y por parte de los participantes (incluso aquellos cuyos proyectos no llegaron a participar) estos vivieron lo que es ese tipo de trabajo. Hasta el momento de escribir esto no supe como acabó esta historia pero estoy seguro de que tanto el ganador de ese concurso como todos los talentos que quedaron dentro del conocimiento de esta empresa si no son los mejores, al menos serán los mejores que van a poder encontrar en esta región en el corto plazo. Y solo espero que otras empresas del ramo apliquen esta misma técnica tan objetiva e imparcial para identificar y contratar empleados talentosos.

Para los que saben de videojuegos ya han de saber que me refiero a Square-Enix, quienes organizaron un concurso de videojuegos para plataformas móviles a nivel latinoamérica. Y por lo que se dice, desde los tiempos en los que Square y Enix eran empresas independientes ya tenían la sana costumbre de hacer retos públicos para atraer a los desarrolladores de aquel entonces. Esta estrategia sin lugar a dudas es la mejor que conozco que ha seguido alguien del ramo y espero que cualquier empresa que tenga el suficiente prestigio para que los desarrolladores la tomen en serio imite esta técnica y consiga contactar a los mejores desarrolladores que encuentre.

Por cierto, esta nota no estaría completa sin las trolleadas de rigor. Pues para los que ya me conocen han de saber que desapruebo por completo las técnicas que las empresas latinoamericanas de videojuegos (especialmente las mexicanas) siguen para contratar personal. Piden cosas que nada tienen que ver con hacer juegos y luego se quejan de que no encuentran personal capacitado. Por ejemplo dicen que es importante estar titulado. Yo por ejemplo cursé la carrera de ingeniería en computación (con minúscula) y tengo contacto con maestros de mas de una universidad y puedo asegurarles que lo único que les enseñan en esas carreras es a derivar polinomios y estar informados sobre lo maravillosos que son los ERP y demás sistemas de administración por computadora. Piden gente muy joven pasándose por alto que las grandes leyendas del desarrollo de videojuegos que todavía viven rondan o superan los 40 años y no le sigo nada mas porque cualquier cosa que les pueda decir no los va a hacer sentir tan mal como el hecho de que sus proyectos multimillonarios no pudieron escapar de la quiebra ni siquiera con los apoyos millonarios que en su tiempo les brindó el gobierno.

Lo importante es la jornada y no el destino

Estoy de acuerdo que para contratar a alguien talentoso hay que poner a prueba todas sus habilidades. Pero esto debe de hacerse de manera objetiva de modo que al aspirante rechazado no le quede la menor duda de que el trabajo estaba fuera de sus capacidades. Como a los guerreros que fueron comidos por la bestia no les quedó la menor duda de que no fueron lo bastante fuertes para derrotarla. El problema es que por culpa de muchos antiguos estafadores los gobiernos prohibieron los «períodos de prueba» a los que podría someterse a los candidatos. La solución es hacer que los candidatos pasen por todas esas pruebas mucho antes siquiera de poner un pie en la oficina de contratación de personal. Otro ejemplo de esto nos lo dan las bandas criminales de cierto pais que de momento no recuerdo cual era y que ahora les voy a contar:

Se dice que que en cierto lugar lejano. En una plaza pública muy grande cada año se organiza un siniestro evento. Jóvenes rudos y sin oportunidades en la vida se reunen en ese sitio para molerse a golpes unos a otros. Desde horas antes la policía está con su equipo listo para someterlos y llevarlos detenidos. Pero aún así se da la pelea.¿Pero porqué sucede esto?.

¡Porque ese evento es usado por la mafia local para reclutar a sus matones! No muy lejos del sitio los líderes de las bandas criminales observan la lucha y se fijan especialmente en aquellos participantes que son capaces de dejar fuera de acción a la mayor cantidad de rivales al mismo tiempo que escapan de los policias. Al final del día los pocos que logran escapar de una pieza y no son arrestados son contactados por las bandas para invitarlos a unirse a sus filas.

En el caso de Square-Enix el concurso sirvió para probar las habilidades de los participantes sin involucrarse con ellos personalmente. Y no solo probaron que tan buenos eran como programadores o diseñadores de juegos. También probaron quienes eran capaces de sacar un proyecto adelante a pesar de la falta de tiempo y recursos, de información técnica y en algunos casos de como trabajar en equipo. Y todo esto sin siquiera verlos a la cara. A mi personalmente me hubiera gustado participar pero en el camino tuve que vérmelas con otros monstruos que me mantuvieron alejado de las computadoras y para cuando llegué este monstruo al que quería retar ya no estaba. De momento no se si porque alguien logró vencerlo o simplemente se aburrió de ganar siempre. Sea como sea, mis respetos tanto a los que se quedaron en el camino con proyectos inconclusos como a los que entregaron proyectos que no ganaron. Que al igual que los ganadores ahora ya saben de lo que realmente se trata hacer juegos y que no es nada mas de cumplir con requisitos sociales abusurdos y contar con certificaciones y licencias que a las computadoras no les interesan para nada. Ahora lo mejor es que aproveche esta valiosa lección y perfeccione mis habilidades para mas adelante econtrarme con otro monstruo igual o mas temible y poder medir fuerzas con él.

Informe asm86[007]

–Miedo a emprender, supervivencia y mas esqueletos–

Había pensado que la nota de «Los Esqueletos Siempre Sonrien» tuviera una segunda parte. Pero como todo lo que había escrito no eran mas que insultos y frustraciones varias decidí que no valía la pena darle su propio espacio. Así qu decidí fundirla con otros dos temas mas interesantes: El aprender por uno mismo y la capacidad de sobrivivir en condiciones difíciles.

Todo el escándalo de la nota de los esqueletos comenzó porque hace un tiempo leí un escrito sobre como hay gente cree que hacer juegos es cosa facil y se asusta cuando se da cuenta de que no lo es. Y no exagero cuando digo que se trata de cobardes que corren por su vida. He visto a muchos que un dia se comportan con arrogancia solo porque alguien que sabe todavía menos que ellos les pagó un salario y al otro lloran por un empleo de lo que sea que les permita darle de comer a sus hijos. Es triste ver como los antiguos héroes del desarrollo de videojuegos como John Carmack de Doom o los fundadores de 3D Realms decían que lo único que necesitabas para hacer juegos además de una PC era información, muchísima dedicación y un refrigerador lleno de comida congelada y ahora resulta que los jóvenes de hoy no quieren dar ni siquiera eso. La mayoría de los que hoy quieren dedicarse a hacer juegos no están dispuestos a abandonar los ingresos que les reportan sus empleos normales y en el peor de los casos quieren que alguien les pague durante los meses que tarden en hacer un solo juego. Pues para que lo sepan, ningún inversionista que se respete estaría dispuesto a invertir su dinero en un proyecto con tan pocas garantías de éxito como lo es pagarle a un grupo de aficionados sin experiencia real para que desarrollen un juego completo en su primer intento. Se de uno o dos pero los que conozco la mayoría están ahora en quiebra y el resto corrió con su dinero apenas a tiempo.

Recuerdo a un desarrollador aficionado que solicitaba una cantidad de dinero bastante considerable para hacer un juego el solo. Cuando le preguntaron para qué quería esa pequeña fortuna respondió que la necesitaba para dejar su trabajo durante un año y el 100 porciento de ese tiempo a hacer el juego. Hasta ahora esa es la respuesta mas honesta que le he escuchado a uno de estos desarrolladores independientes. Pues programar es muy barato en el sentido de que no hace falta materia prima, maquinaria demasiado sofisticada (solo una PC) ni grandes cantidades de mano de obra. De hecho lo que verdaderamente hace la diferencia entre una desarrolladora pequeña y una con cientos de empleados es que esta última recurre a la fuerza bruta de sus artistas gráficos para crear toda clase de contenido para incluir en el juego. Tendencia que si no cambia mas de uno de los grandes va a tener que vender barato algunas acciones. Pero eso es tema de otra entrada. Ahora vamos a discutir el problema de los wanna be’s que lloran porque nadie les da dinero para sus juegos.

Un problema del primer mundo…

Muchos paises se rien de cosas que solo son consideradas problemas en el primer mundo pero que en el resto de los paises pobres no están sujetas a discusión. Por ejemplo protestar por las «abusivas» condiciones laborales que las multinacionales imponen a los trabajadores de paises pobres cuando antes de su llegada sus habitantes no tenían ninguna oportunidad de empleo o hacer protestas porque se maltrata a animales silvestres cuando estos no dudarían en matar y devorar a cualquier humano que sorprendieran desprevenido. Para los paises mas pobres o simplemente gente no tan acaudalada de esos mismos paises civilizados este tipo de problemas son cosa de risa. Uno los mas recientes y que mas úlceras me ha sacado desde que escuché aquello que a algunos les pagaban por retocar botones de interfaces es el siguiente:

No me he dedicado de tiempo completo a hacer juegos porque me da miedo abandonar mi trabajo seguro y bien pagado y no poder cumplir con mis responsabilidades económicas.

Si a ustedes esto les parece perfectamente razonable los felicito. Probablemente no tuvieron problemas para conseguir un empleo seguro y bien pagado. Probablemente son graduados de una universidad de prestigio y si ya tienen cierta edad de seguro están felizmente casados con una pareja profesionista, tienen una casa propia y se aseguran de que sus hijos vayan en su SUV todos los dias limpios y desayunados al colegio confesional mas prestigioso de su localidad. Se entiende que tienen compromisos que cumplir como créditos, pagos varios y otras responsabilidades que me da flojera describir en detalle. Y de seguro entre sus mayores preocupaciones está el saber la fecha límite para cubrir el pago mínimo de sus tarjetas de crédito. Los entiendo, personas responsables y trabajadoras como ustedes nunca abandonarian la estabilidad familiar y financiera que tienen para irse con un montón de geeks desarrapados a un cuarto apartado donde todo el día hacen cosas raras con sus PC (ni siquiera Mac) por las que no reciben ningún cheque semanal. A estos adultos responsables tengo algo que decirles: ¡Hay desarrolladores pobres que se rien de sus poblemas!

Corriendo el riesgo de que muchos de mis nuevos amigos me dejen de hablar o no le den like a las fotos de mi gato gordo en Facebook voy a decir algo que los puede ofender: ¡Casi todos los aspirantes a game developer que he conocido fuera de mi círculo mas cercano son gente privilegiada! Y eso no es malo pero considero que son gente demasiado inocente que puede ser víctima de toda clase de estafadores, ladrones y criminales de cuello blanco apenas pongan un pie fuera del mundo perfecto en el que viven. Cuando los veo suelo decirles de que el mundo que ellos conocen es como esas fortalezas amuralladas de algunas películas de zombies. Y que apenas pongan un pie fuera de esas barreras deben de estar preparados para enfrentárlos. Fuera de eso son gente de lo mas encantadora y que estoy orgulloso de haber tratado. Ahora bien, fuera de la protección de la muralla junto con los zombies me he encontrado no solo aliados sino gente que también quiere participar en esto. Aunque muy poca. De hecho me atrevería a decir que quienes viven en situaciones no tan privilegiadas ven esto de programar juegos como algo imposible o ajeno por completo a su realidad. Pero hace poco presencié un caso interesante.

…es una ilusión que abrazará el vagabundo

Como sabrán los que les interesa hacer juegos en el 2012 la empresa Square-Enix organizó un concurso de desarrollo de videojuegos a nivel latinoamérica para obtener información sobre la calidad y distribución de los desarrolladores locales. En ese tiempo un desarrollador principiante se me acercó y me pidió ayuda para entrar al concurso. Por desgracia para todos tuve algunas pérdidas familiares que me impidieron dedicarme al concurso como yo quería pero este personaje era por completo diferente a los mencionados en los párrafos anteriores. No lo conocí personalmente pero por su forma de expresarse deduzco que era un estudiante que rondaba los 20 años o tal vez menos, que por motivos económicos no había podido entrar a la universidad pública y que tal vez hasta había desempeñado trabajos eventuales para pagar sus necesidades mas básicas. De todos los mensajes que intercambiamos en ese tiempo el que mas me sorprendió decía algo así como: –«¡Gurú por favor enséñame a programar! ¡Necesito poder hacer juegos para pagarme la universidad!»–

Esta declaración me llegó no solo por haberme llamado gurú sino porque me dejó en claro que realmente creía en si mismo a un grado que ningún desarrollador de juegos autodenominado «profesional» que he conocido en persona lo hacía. Lo de gurú me hace reir apenado, pues no es la primera vez que alguien me imagina como alguien exitoso y bien posicionado en la sociedad. De hecho soy mas como una versión muy minimizada y geek de Ryu de Street Fighter. Un vagabundo sin empleo ni residencia ni familia fija que recorre el mundo (bueno hasta ahora solo el internet) buscando perfeccionar sus habilidades y haciendo trabajos eventuales que nada tienen que ver con las computadoras para sobrevivir. Aunque no soy tan bueno para la programación como el buen Ryu lo es para las artes marciales me gusta verme a mi mismo como un aventurero errante que busca acción en sitios donde otros solo ven amenazas y negocios riesgosos. Aunque cuando vaya en la calle con mi computadora oculta otros solo vean eso que la gente bonita designa como «un loser».

En fin, este informe es también para comunicar que a partir de ahora las notas se van a volver un poco mas duras en el sentido de que voy a tratar a los principiantes con mayor severidad. Voy a tratar temas mas avanzados de la forma mas clara y amistosa posible pero al mismo tiempo aquellos que vengan nada mas para hacer copy-paste y entergar una tarea se encontrarán con que este blog será mucho mas ofensivo que nunca. Estoy cansado de que gente considere inferieriores (o peor aún superiores) a otras personas por cosas superficiales que no tengan nada que ver con sus verdaderos conocimientos y habilidades. En este sitio quien quiera respeto va a tener que pelear conmigo y con cualquiera de los lectores habituales y que no se preocupe si pierde porque aún si eso pasa será mas respetado que cualquiera que venga a exigir respeto sin habérselo ganado a golpes. Pues parafraseando a cierto fabricante de armas de Europa Oriental, los dioses crearon a los seres humanos diferentes pero luego las computadoras los hicieron a todos iguales. Y recuerden. Cuando alguien logra triunfar luego de muchisimos sacrificios, la mayoría se desanimará porque lo considera muy dificil; pero unos pocos se sentirán esperanzados al descubrir que triunfar es posible. Ahora mejor me pongo a programar porque buena falta que me hace conseguir unos cuantos triunfos.

¡Los Esqueletos Siempre Sonrien! (Parte 1)

–Demasiado optimismo puede matar a un programador–

Imaginen que caen en las garras de un monstruo que los destruye de manera lenta y sumamente dolorosa a lo largo de meses o años pero que les hace creer que todo va a estar bien. Que si tienen el valor para atacarlo les hace creer que si lo siguen golpeando con esa arma tan debil van a poder algún dia vencerlo y que si tratan de salir corriendo va por ustedes y les nubla la razón para que no lo hagan. Un monstruo que no pretende asustarlos ni mucho menos hacerlos huir. Solo algo que recuerda al sufrimiento de cuerpo y mente sugiere que algo está muy mal. Al final, sus cuerpos mueren mientras sus mentes permanecen atrapadas en un hermoso sueño del que no despertarán a menos que alguien los regrese a la realidad de un golpe y les muestre la horrible y verdadera cara del monstruo del que están siendo víctimas. Y esta nota es como ese golpe que anula ese diabólico hechizo. De inicio no les va a gustar pero ya me lo agradecerán después.

No sabría como llamar a este enemigo abstracto, aunque ya en la mitología de la India existían espíritus malignos capaces de anular la capacidad de percepción del ser humano esto tiene mas que ver con aquello que algunos llaman esperanza. De hecho en el mito de Pandora se decía que grandes horrores habían salido de su caja y que tan solo quedó dentro la esperanza cuando por fin lograron cerrarla. Este monstruo abstracto al que trato de imaginarme como un Esqueleto Sonriente se aprovecha de la idea de que la gente considera que la esperanza es algo bueno y les tapa los ojos de la razón a sus víctimas mientras devora sus almas. Y cada que te escucha quejarte se te acerca al oido y te llena de optimismo con frases como «échale ganas», «tu puedes» o «sigue intentándolo». Ahora veamos un poco mas sobre este esqueleto sonriente.

El Esqueleto Sonriente es el gemelo maligno de la Esperanza. Sus principales víctimas son los apostadores a quienes les hace perder grandes cantidades de dinero haciéndoles creer que en la siguiente tirada de dados van a ganar pero también suele susurarles a los enfermos que sus síntomas en realidad no son tan graves como para ir al médico o engaña a algunos enamorados diciéndoles que la persona que los ha rechazado toda la vida en realidad si los quiere. Y como este escrito es sobre programación, me voy a concentrar en como el Esqueleto Sonriente ha destruido las carreras de muchos programadores. En especial las de muchos desarrolladores de videojuegos.

Demasiado optimismo puede matar a un programador. De momento voy a mencionar el caso del creador de un juego conocido como Kingdoms of Amalur quien terminó en la ruina por su excesivo optimismo. En cierto momento tuvo un capital millonario, un gran equipo de desarrolladores a los que les daba todo tipo de prestaciones exóticas y todo lo necesario para terminar y llevar su juego al mercado. El tenía grandes esperanzas de que este juego fuera un gran éxito. Y si bien pudo terminar y sacar a la venta un juego que sin ser el mejor si que era mucho mas que bueno sus costos se elevaron tanto que ni vendiendo varios millones de copias pudo escapar de la quiebra.

El caso Amalur se repite mucho en todos los niveles. Desde empresas con presupuestos millonarios como la que acabamos de ver hasta modestos desarrolladores independientes que quieren hacer juegos en la computadora de su recámara. De hecho, me atrevería a decir que los programadores tienen que vérselas con el Esqueleto Sonriente desde que se les ocurre su primera idea para un juego hasta que reciben el pago final por sus servicios. Es mas, no me extrañaría descubrir un día que el CEO de alguna empresa de videojuegos sea el mismísimo Esqueleto Sonriente. Y si no me creen solo piensen por un momento lo siguiente: Muchos geeks relacionados con la programación tienen como máxima aspiración convertirse en desarrolladores de videojuegos profesionales y vivir de hacer juegos. Tienen la idea de que se trata de un trabajo muy divertido solo porque se la pasaron muy bien en sus épocas de gamers. No tienen idea de lo que en realidad es hacer juegos.

Lo mas siniestro es que en realidad nadie se beneficia del fenómeno del Esqueleto Sonriente. A primera vista podría parecer que un productor puede sacar ventaja al sobreexplotar a los desarrolladores para obtener mas horas de trabajo por un mismo salario pero a la larga termina con costos demasiado elevados y acaba con serios problemas de liquidez. Y al igual que el apostador compulsivo, todos pierden su dinero, su tiempo y en casos extremos hasta sus vidas o por lo menos buena parte de ellas tratando de sacar a flote proyectos imposibles de terminar. En el caso de proyectos personales el problema no va mas allá de dejar las cosas en el olvido (díganmelo a mi) pero cuando hay dinero de por medio, siempre hay alguien que tiene que pagar.

Conoce los límites de tu poder

Antes de discutir como hacerle frente al Esqueleto Sonriente veamos a uno de estos en acción: Digamos que ustedes van a un evento de geeks como por ejemplo una convención de comics. Ven que uno de los conferencistas en un «profesional» de la industria de los videojuegos. Durante la conferencia este les dice no solo lo maravilloso que es hacer videojuegos y las enormes fortunas que se mueven todos los dias. Tras varios minutos de hablar mucho y no decir nada finalmente llega a la sección donde comenta como pueden los pobres principiantes iniciarse a hacer videojuegos. Aquí es donde entran las bien conocidas herramientas de aficionado que pueden encontrar si buscan en google como hacer videojuegos sin saber programar y en el mejor de los casos da los nombres de algunas herramientas de diseño de licencia libre. Por cierto, siempre me he preguntado porqué en estas pláticas nunca dan detalles sobre herramientas libres que tienen aplicación mas seria en desarrollo de videojuegos como los compiladores GCC por ejemplo.

Ahora vamos a saltarnos lo ocurrido entre que salen de una de estas conferencias llenos de ganas de hacer videojuegos y vámonos hasta el momento en el que ya comenzaron a hacer uno pero no pueden terminarlo. Comienzan a notar que casi no duermen, que han descuidado sus estudios o trabajos honestos o si fueron lo bastante estúpidos y jugaron con dinero de verdad a que no van a poder cumplir con las fechas de entrega. Pero todo está bien porque están haciendo el trabajo de sus sueños y la envidia del troll de internet que dice que sabe de Ensamblador se los recuerda cada que se meten a leer su blog. En eso yo me apiado de su miseria y les doy un golpe para despertarlos del hechizo del Esqueleto Sonriente y lo que ven no les gusta nada:

He escuchado mucho de algunos el término «Reality Check», y a la mayoría de los que les he escuchado este término tuvieron que cambiar de empleo en menos de un año. Esto es parecido a eso que llaman Reality Check pero con la diferencia de que a cada quién le toca una realidad diferente dependiendo de sus muy particulares circunstancias. La primera cosa que uno debe de hacer tras escapar del hechizo del Esqueleto Sonriente es estar muy pero muy consciente del límite de sus propias capacidades. Y esto no es para que se sientan poca cosa sino para que no intenten hacer algo que nunca van a poder terminar. Si por ejemplo yo les dijera que soy capaz de hacer en una semana un programa para una plataforma que desconozco por completo seguro fallaré. Pero si el excesivo optimismo del Esqueleto Sonriente aparece diré que si puedo hacerlo y fallaré intentándolo. Esto no es nada sencillo. Pero la única manera objetiva de medir nuestras capacidades es probándonos a nosotros mismos. Antes de lanzarse a dibujar ustedes solos todos los cuadros de animación de los 20 personajes de su nuevo juego de peleas o a programar las inteligencias artificiales únicas que le han de dar una personalidad propia a cada uno de esos 20 peleadores mídanse ustedes primero. Vean cuanto tardan en dibujar un solo cuadro de animación digno de mostrarse en el juego o si pueden hacer que por lo menos el peleador controlado por el CPU es capaz de caminar hasta donde está el jugador. Mas que ser realistas o moderados con lo que se proponen, lo que les pido es que sean objetivos. Pues es muy sencillo confiarse y lanzarse a hacer cosas que están por completo fuera de nuestras capacidades.

No me voy a ir sin antes darles el golpe que les devolverá la visión de la realidad. Y tras dárselo la primera cosa que ven es que están tirados en el suelo, sin dinero, sin comida, sin energía y lo que es peor sin un juego terminado. Primero me reclaman del porqué destruí su lindo sueño y yo procedo a detener sus golpes y girarles la cabeza para que queden cara a cara con el temible Esqueleto Sonriente.

En la siguiente entrada vamos a ver que hacer cuando uno recién acaba de salir del hechizo del Esqueleto Sonriente. Las etapas por las que uno pasa son enojo, desengaño, miedo, desesperanza y finalmente resignación, aunque la resignación puede no ser el último paso si siguen los consejos que voy a darles. De momento lo que les recomiendo es que si ustedes son programadores aficionados y creen que están viviendo «su sueño» primero borren esas sonrisas idiotas de sus caras, pues tanto optimismo no va a hacer que un mal código funcione, pues no olviden que aunque ya estén muertos los esqueletos siempre sonrien.

¡No Puedes Escapar de la Programación!

–Cuando haces videojuegos todo tiene que ver con programar–

Como saben quienes han leido estos escritos desde hace tiempo, un tema del que escribo mucho es sobre programación de videojuegos, de hecho me interesé en el ensamblador porque en aquellos años era el lenguaje en el que se programaban los mejores juegos. Esta forma de pensar me llevó un día a la idea de abrir otro blog relacionado con el tema que mas se toca aquí (incluso mas que el ASM) y me refiero al desarrollo de videojuegos. Pero cuando escribía las posibles entradas me di cuenta de una cosa: ¡De que todo se relacionaba con la programación!.

Esta sentencia no es del todo mia. Es parte de una entrevista que escuché hace mucho por radio analógica. En un programa sobre computadoras entrevistaban a uno de los egresados de una de las en ese entonces muy contadas escuelas de videojuegos y el invitado dijo que no importaba a que área del desarrollo de videojuegos uno se dedicara, siempre se relacionaba con la programación de una forma u otra. Y esto lo confirmé cuando intentaba escribir una entrada de como se crean los sprites y vi que la mayor parte del texto hablaba sobre estructuras de datos, alineación de memoria y transferencias eficientes de secuencias numéricas. Es decir que nada que ver con lo que la gente que yo conozco que se dedica a dibujar para videojuegos hace. Ahora veamos las principales áreas del desarrollo de videojuegos que aunque lo intenten no pueden huir de la programación:

Los Artistas Gráficos no pueden escapar

Suponiendo que ustedes sean artistas gráficos porque en verdad les gusta dibujar y no porque programar les daba miedo de seguro tienen un estudio propio con una mesa de dibujo, lámpara flexible, una colección de tintas y lápices siempre disponible y si tienen dinero puede que hasta una tableta gráfica. Las paredes de su lugar de trabajo sostienen aquellas obras que los hacen sentir orgullosos y que les levantan la autoestima cuando el último cliente al que le hicieron los dibujos de esa campaña publicitaria no les pagó lo que querían. En fin, el asunto es que cuando intentan meter su arte en un videojuego este no se ve tan bien como lo hacía en los dibujos de las paredes. Ni siquiera se ve tan bien como se veía en la pantalla de la computadora en la que diseñaron. En lugar de eso los personajes parecen planos y sin detalle. No se aprecian los gestos faciales ni las expresiones en los juegos para móviles, los trazos se ven toscos e irregulares y las fotos digitalizadas de los personajes parecen recortes de revista. El artista se siente mal, pero nada de esto sucede porque sea un mal dibujante, sino porque no sabe como funciona el sistema gráfico de una computadora.

Algunos de estos errores comunes son por ejemplo no calcular bien la resolución en la que va a aparecer la imagen. Si tan solo dibujan en papel y usan un scanner a la hora de ajustar el tamaño los detalles grandes se van a deformar y los pequeños a perder por completo. También está el problema de la profundidad de color. Un Scanner puede capturar hasta 48 bits de profundidad de color pero las pantallas de muchos sistemas de videojuegos con dificultad alcanzan los 32 bits y aunque los alcanzaran el ojo humano puede no percibir bien las tonalidades. Algunos intentan paliar este cambio retocando las imágenes digitalizadas antes de integrarlas al juego. Debo advertirles que esto nunca funciona. Si una imagen digitalizada y pegada directamente a un juego tiene el aspecto de un recorte de revista una imagen digitalizada y retocada en un editor gráfico va a parecer un recorte de revista al que le dibujaron encima. Otro problema al convertir un dibujo a sprite sin saber programar es el de que queda «delineado». Las figuras quedan con un contorno que hace que no se vean debidamente integradas con el resto de la escena. Esto es por no saber manejar la profundidad de color. De todos estos problemas hablaré en el futuro porque necesitan una nota para ellos solos. Ahora veamos como los modeladores 3D que no saben programar se dan de narices al tratar de hacer modelos para videojuegos.

Los Modeladores 3D no pueden escapar

Esta historia la vi en persona. Cierto modelador 3D se quejaba de que los modelos que hacía para videojuegos eran demasiado simples y angulosos y que cuando hacía que se vieran bien estos alentaban demasiado el juego o incluso no corrian. Esto sucede porque los primeros editores 3D para computadoras personales como el 3D Studio no hacían realmente modelos de objetos sino de escenas completas y a la hora de importar uno de esos archivos a un juego había demasiada información que en realidad no se usaba. Otro detalle que los modeladores 3D que nunca han hecho modelos para videojuegos es que los modelos se procesan en Tiempo Real. Hay reglas sobre como deben diseñarse esos objetos para que se vean bien en un videojuego de acción rápida y que no sobrecarguen las rutinas de rendering. Por ejemplo muchos de estos se dibujan incompletos de modo que al moverse rápido el cerebro humano los une. Si son observadores o tienen un Playstation de primera generación que funcione podrán ver como muchos personajes en realidad no tienen articulaciones sólidas. Otra manera de aligerar el rendering es usar las texturas de manera que parezca que el objeto tenga relieve irregular u obedezca a cambios de iluminación. El conocido como Normal-Mapping es en realidad una optimización para simular superficies irregulares en un objeto formado por caras planas.

Los modeladores 3D cuyo trabajo no se relaciona con los videojuegos no necesitan saber esto porque rara vez les piden hacer modelos que van a ser presentados por un sistema de visualización en tiempo real. Casi siempre lo que les piden son animaciones e imágenes fijas o en el caso de los que trabajan para cuestiones de ingeniería modelos muy detallados que no necesariamente se ven realistas. Al hacer modelado para videojuegos no se debe de hacer tanto detalle porque hace el modelo demasiado dificil de procesar. Pero tampoco basta con disminuir la cantidad de polígonos para convertir un modelo detallado en uno que pueda incluirse en un videojuego. Esto da al modelo una apariencia falsa y plástica. El proceso para convertir un modelo detallado en uno apto para un sistema en tiempo real comienza desde antes de diseñar el modelo detallado y toma en cuenta detalles tan poco artísticos como la precisión numérica usada para representar los vértices o que al multiplicar las dimensiones y profundidad de color de las texturas el resultado sea una potencia de dos alineable en memoria. En mi experiencia he visto gente que hace modelos de millones de caras con efectos de luz dificilísimos de procesar cuando podrían obtener resultados mas vistosos y eficientes con unos cuantos miles de caras, iluminación interpolada y unos cuantos juegos de texturas.

Por cierto, en mucho tiempo de convivir con desarrolladores de videojuegos, tengo por lo menos 10 años en los que no he visto que abran un archivo de imagen ni mucho menos uno de un modelo 3D a nivel binario. Casi siempre el sistema en el que están trabajando los carga de manera automática o los mas avanzados llaman a una función de una API (o a la clase de un paquete como dicen ahora) que lo carga en la memoria con tan solo pasarle el nombre del archivo. Les recomiendo que si quieren saber en lo que se están metiendo intenten un día por lo menos abrir uno de estos archivos en modo texto y desplegar los valores mas importantes. Conocer a nivel de bit los formatos gráficos de archivo no solo les ayudará a decidir cual es el formato que mas les conviene sino que podrán optimizar mejor los recursos y hacer gráficos mas rápidos, de mejor calidad y sin errores extraños relacionados con fugas de memoria.

Los Game Producers no pueden escapar

Esta última parte la pongo nada mas para reirme. Pues me resulta gracioso como los que menos parecen relacionarse con la programación en una empresa de videojuegos son los que mas daño pueden causarle a la empresa por sus pobres conocimientos sobre computación. Vamos primero con los game producers. Un game producer, o al menos los que yo he conocido personalmente son jóvenes egresados de prestigiosas carreras de negocios y tienen experiencia en comercio internacional. Para ellos es sencillo conseguir fondos para arrancar proyectos y conocen gente que les ayudará a publicitar y vender sus productos. Su problema es que decisiones que parecen perfectamente razonables para un negocio cualquiera pueden ser verdaderos suicidios a la hora de hacer videojuegos. Pues una cosa que casi todos los game producers aprenden a la mala es que esto de los juegos es lo que en cultura corporativa se conoce como «Bet Your Company» que es cuando inviertes meses o hasta años en producir algo que no sabes siquiera si se va a vender. Un Producer puede hacer cálculos del costo de desarrollar un videojuego a lo largo de un año y luego ver que la adquisición de una licencia de un engine puede recortar ese tiempo y el costo a la mitad. Cuando ve que el desarrollo no avanza según lo planeado contrata a mas ingenieros para sacar el trabajo y hasta prevee como cubrir las inminentes pérdidas. Y al final si es listo hace un trabajito para un cliente corporativo, queda tablas con las deudad y liquida la empresa. Esto le pasó porque aunque su razonamiento era perfecto para producción industrial o negocios tradicionales al no saber de programación cometió errores que lo llevaron a la bancarrota. Y es que para sacar a flote un negocio de software es necesario conocer una serie de fenómenos que solo ocurren en este tipo de negocios como que mientras mas ingenieros se unen al trabajo en etapas avanzadas mas tiempo tarda el sistema en terminarse o que lograr que un programador pueda modificar un código de otra persona cuesta mas dinero y toma mas tiempo que si el mismo lo hiciera desde cero. Incluso hay grandes tomos sobre administración del desarrollo de software y las carreras de ingeniería en computación mas serias comienzan a orientarse mas a eso que realmente a programar. Un productor o especialista en negocios que no sepa de programación puede cometer este tipo de errores y otros que le harán perder mucho dinero y sobre todo no cumplir a tiempo con los deadlines.

Los Beta Testers no pueden escapar

Finalmente llegamos a lo mas bajo de la empresa de videojuegos. Conocido en otra época como Beta Tester, un QA es un pobre diablo al que le obligan a jugar los mismos juegos malos una y otra vez durante horas para detectar errores. Si tanto los jefes encargados del departamento de control de calidad como los QA’s no saben nada de programación van a mantener las partidas durante dias y noches enteras y al final se les van a colar errores. Y eso ocurre porque probar un videojuego no es simplemente jugarlo sino que el que lo prueba debe de ser capaz de destruirlo.

Suponiendo que antes de pasarle al probador humano los programadores ya efectuaron toda una batería de pruebas automatizadas para llevar al videojuego a su límite y que el encargado de probarlo sabe de programación seguro hará pruebas que ningún jugador considerado normal haría. Por ejemplo, un programador sabe que los números se guardan en espacios de memoria de longitud limitada y no pueden crecer indefinidamente. Una prueba sería acumular todas las monedas o items que pueda para ver cuantas puede cargar el personaje, llevar el contador de puntuación a su máximo a ver si se detiene o reinicia o intentará atraer a la mayor cantidad de monstruos en una sola pantalla. Estas pruebas casi siempre conducen a un viejo error conocido como Overflow y pueden hacer que el juego se trabe u ocurran cosas extrañas. Otro tipo de prueba es la siguiente: Si conoce el concepto de banderas y toma de decisiones puede intentar cosas como tomar una vida al mismo tiempo que recibe el golpe final o intentar guardar el juego justo en el momento que va a aparecer la pantalla de game over. Incluso si conoce el concepto de máquina de estado finito y aceptores puede deducir y probar combinaciones de acciones que potencialmente podrían llevar al juego a un fallo. En fin, un QA que sepa de programación puede descubrir errores que un jugador normal no podría localizar ni aunque jugara durante años.

Ya para irme, les recuerdo que si se interesan por hacer videojuegos no pueden escapar de la programación. No importa si son artistas, productores o simple control de calidad. Les digo esto porque he visto grupos de desarrollo que no tienen programadores o estos son muy pocos en comparación con los especialistas en otras áreas. O que simplemente los menosprecian y marginan. Si sus trabajadores no tienen un mínimo de conocimiento de programación por lo menos procúrenles un asesor que si sepa y los oriente en su trabajo. Aunque viéndolo bien, si los artistas, productores o QAs no les interesa un mínimo la programación. ¿Para qué quieren dedicarse a hacer videojuegos?

Anime, Videojuegos y Cálculo Diferencial

Tips para estudiantes de la carrera de Programación de Videojuegos

Hoy en día comienzan a aparecer universidades con carreras tan interesantes como Animación y Desarrollo de Videojuegos. Cuando yo era pequeño y no sabía nada de programación la existencia de una escuela donde uno apendiera a hacer juegos sonaba tan fantástica (en el sentido de fantasía imposible) como la de la escuela para magos de Harry Potter. Pasado un tiempo corrió el rumor de que empresas multinacionales como Nintendo tenían unos pocos centros de entrenamiento en los que capacitaban a sus ingenieros y en cierto momento a finales del siglo pasado se destapó el rumor de que esta misma empresa tenía uno de estos centros ubicado al norte del continete americano. Tal instalación era conocida como Digipen y se rumoreaba toda clase de cosas respecto a lo que pasaba ahi dentro. Para todo niño y adolescente gamer era un sueño entrar a un lugar como ese. Pero como si no fuera suficiente la enorme distancia, la muy reducida matrícula (entonces solo admitian 2 estudiantes por año) y la dificultad de las materias. Sus jefes habían puesto una sentencia que sonaba mas como una maldición para alejar a los profanos e impuros: «Si quieres aprender a hacer videojuegos con nosotros debes de ser muy bueno con las matemáticas».

Les cuento esta historia para que los jóvenes de hoy sean conscientes de la enorme fortuna que tienen. Pues ya en México y otros paises de habla hispana existen carreras donde pueden aprender a hacer videojuegos. Tal vez no sean tan buenas como Digipen pero al menos cuentan como carreras profesionales y se encuentran registradas ante el gobierno. Existen carreras para todos los gustos y presupuestos que me llevaría mucho tiempo mencionar en detalle. De momento puedo mencionarles la Licenciatura en Animación y Arte Digital del ITESM que se da en una escuela de mucho prestigio y se enfoca al lado artístico y la Licenciatura en Multimedia y Animación Digital impartida en la UANL que se concentra mas por el lado de la ingeniería y tecnologiá. Pues bien, me han llegado rumores, sobre todo de esta última pero no dudaría que ha pasado también en otras escuelas de que hay un gran desencanto en los alumnos que entran a estas carreras.

Y aquí es donde entra la que podría llamarse como «La Maldición de Digipen» pues como ya habrán adivinado la principal queja sobre estas carreras es que tienen demasiadas matemáticas. No voy a regañar a los gamers y otakus ingenuos como muchos otros lo han hecho en internet sino que les voy a explicar en términos sencillos el porqué las matemáticas se relacionan tanto no solo con los videojuegos sino inculso con la animación tanto tradicional como por computadora.

Imagino que en este mismo momento varios de mis lectores se han de haber atragantado con un Pocky. Voy a darles un instante para que le den un trago a su Ramuné, terminen su partida en linea de Ragnarok y se les pase el susto. Estoy seguro que estos lectores no pueden creer que exista una relación entre las chicas mágicas en uniforme escolar, los emocionantes videojuegos de aventuras en linea y las aburridas y odiadas matemáticas. Pero existe. En esta entrada me voy a concentrar en el cálculo diferencial porque es el que mas se relaciona con la animación. Les recomiendo que sigan leyendo porque no los voy a aburrir e incluso sospecho que esto podría hasta llegar a gustarles.

Primero veamos lo que es la animación. Para que el ojo tenga la ilusión de que el cine y la animación tienen movimiento se presenta una secuencia rápida de imágenes donde cada una es ligeramente diferente de la anterior. Si lo hacemos bien, el ojo interpretará que esa secuencia de imágenes fijas tiene movimiento continuo. Los animadores antiguos hacían esas secuencias de imágenes con lapiz y papel que luego pasaban a una película cinematográfica. Con el tiempo mejoraron su técnica reciclando partes de dibujos, fondos y composiciones primero con materiales físicos y luego con computadoras. Pero sin importar cuanto ha avanzado la animación. La idea de presentar una secuencia rápida de imágenes con ligeros cambios de una a otra y que el ojo humano ve que se mueve sigue siendo la misma. Lo que debe de quedar por ahora claro es que para que la animación funcione los cuadros de animación deben de correr a suficiente velocidad y el cambio de uno a otro no debe de ser tan grande como para notarse. La animación es un cambio de posición con respecto al tiempo.

Ahora veamos como esto se relaciona con los videojuegos. Los juegos presentan también una secuencia de imágenes fijas que el ojo registra como una animación. La diferencia es que el videojuego es interactivo. La estructura de código mas importante en un videojuego y que hace posible esa interactividad se llama «Gameloop». Se trata de un ciclo infinito en el que primero se leen los controles, se ejecuta el programa que controla el juego y al final se genera un cuadro de animación que se muestra en pantalla. En los juegos de acción rápida esto sucede unas 60 veces por segundo. Como esto es muy rápido el efecto es una secuencia rápida de imágenes fijas. Pero a diferencia de la animación que conocemos aquí esos cuadros de animación simplemente se pierden luego de que los vemos. A este proceso en el que se genera un cuadro de animación en una fracción de segundo y que no se guarda en ninguna parte es lo que se conoce como «Animación en Tiempo Real» y es necesaria para que un videojuego presente una animación con la que los jugadores puedan interactuar.

Si nos metemos mas a fondo en el Gameloop vemos que la lógica del juego debe de pensar en esa única fracción de segundo en que existe entre el anterior cuadro de animación y el siguiente. Para que el movimiento sea real y los controles se sientan bien hay que saber que tanto debemos de cambiar la escena. Si lo hacemos bien la animación se verá realista y los personajes jugables responderán a las órdenes del jugador. Ahora veamos un ejemplo muy simplificado de animación normal e interactiva.

Digamos que tenemos una linea recta por la que debe de volar una nave espacial. La nave comienza en el paso cero y cada cuadro de animación avanza uno de esos pasos. Si reproducimos la secuencia de imágenes vamos a crear una animación de la nave que avanza hacia adelante. Si quisiéramos que la animación fuera interactiva, digamos que queremos que la nave avance solo cuando oprimimos un botón haríamos lo siguiente:

Primero colocamos la nave en el punto cero y luego entramos al gameloop. Al inicio del gameloop vamos a ver si el botón está siendo presionado por el jugador. De ser así incrementamos en uno la posición de la nave. Si el botón no está siendo presionado no se aumenta la posición. Al final del gameloop generamos la imagen con la nave en su nueva posición. Podemos hacer que la condición para salir de ese gameloop infinito sea que la nave llegue al paso 100 o que se oprima el botón para terminar el juego. De ese modo tenemos una animación interactiva en la que hacemos que la nave avance cuando presionamos el botón.

Si presentamos la animación a una velocidad de 60 cuadros por segundo la nave hará su viaje en poco mas de segundo y medio en un vuelo ininterrumpido. Desde el punto de vista del programador la nave cambia de posición un poco en cada ciclo del gameloop. Ahora veamos una pequeña sorpresita.

La Animación son pequeños incrementos de movimiento respecto a pequeños incrementos de tiempo…
¡Y eso se llama Diferenciación!

La sorpresa que les tengo es que lo que acaban de leer en estos últimos párrafos es puro cálculo diferencial aplicado. Y mientras me imaginan poniendo una Trollface por haberlos hecho leer algo de matemáticas yo les voy a explicar con palabras sencillas como el ejemplo de animación es lo que lo que se llega a ver en el primer semestre de cualquier ingeniería.

La animación es movimiento. El movimiento se puede representar matemáticamente como la distancia en función del tiempo. En el ejemplo de la nave el movimiento es lineal a velocidad constante y sin aceleración. Se trata de una función lineal de primer grado. Ahora veamos donde entra el cálculo diferencial.

No voy a meter signos raros intercalados con las palabras «sea», «tal que» y «entonces» porque ya los he trolleado demasiado para una sola entrada. Solo les voy a decir que el cálculo diferencial estudia el cambio de las funciones a medida que avanzan en pasos cada vez mas pequeños. Volviendo a la animación. A medida que el cambio en la secuencia de imagen y el tiempo que hay entre un cuadro de animación y el siguiente se reducen la animación se va haciendo mas y mas real hasta llegar a un punto teórico donde los incrementos se acercan al cero y suceden tan rápido que la animación comienza a ser igual al movimiento que existe en nuestro mundo físico.

El movimiento que definimos de la nave es a velocidad constante (un paso por cada unidad de tiempo) y no tiene aceleración (no aumenta su velocidad ni la disminuye). Al avanzar un paso por cada cuadro de animación la nave tiene una velocidad de un paso por cada unidad de tiempo. Y aquí viene otra sorpresita. Ustedes acaban de aplicar la derivada a una función de movimiento sin aceleración. Cuando diferenciamos una función de movimiento sin aceleración el resultado es una constante. En el caso de la animación de la nave esa constante es uno. Si quisieran cambiar la velocidad o definir movimientos mas elaborados, el proceso es el mismo.

De momento solo voy a mencionar todo lo que pueden hacer con esta técnica en el mundo de la animación y los videojuegos. Las funciones de segundo grado se usan para movimientos con aceleración constante como los que involucran a la gravedad en los juegos de plataformas, y las de tercer grado pueden simular la aceleración variable de un motor que varía su potencia. Hay muchas cosas mas de animación que pueden resolver tan solo sabiendo aplicar el cálculo diferencial. En un futuro mas o menos lejano les explicaré mas sobre el tema.

¿Todavía no te interesan las matemáticas?

Personalmente creo que esa aversión por las matemáticas que muestran los aspirantes a programadores de videojuegos viene en parte por los maestros que aunque dominan el tema no saben ni les importa nada del mundo gamer. Por otro lado, si los estudiantes supieran que para lograr un determinado efecto especial necesitan aprender cierta rama de las matemáticas probablemente no le tendrían tanto desprecio. Por ejemplo, a mis amigos y a mi nos tomó mas de un semestre darnos cuenta que para hacer una cámara movil necesitábamos entender el cambio de base en un sistema de matrices ortogonales. Si de inicio hubiéramos visto ese mismo tema en la clase de Algebra Lineal lo mas seguro es que nos hubiéramos quedado dormidos en clase. Pero si en la búsqueda por lograr una cámara movil en un juego 3D nos hubieramos topado con el cambio de base de matrices ortogonales la cosa habría sido mucho mas emocionante.

Tengo que admitir que la situación actual de estos estudiantes me resulta por completo desconocida. Pues cuando llevé las materias de matemáticas en la carrera ya había visto esos temas en libros de computación (especialmente la materia de Matemáticas Discretas) o por lo menos había escuchado que algunos de esos temas se relacionaban con la programación de videojuegos. Ya para terminar esta nota que ha quedado tan larga, mi consejo es que si quien lee esto tiene un cargo importante en alguna universidad (y si conocen al Rosas pásenle el enlace a esta página) organice las clases de modo que las matemáticas no sean tan obvias. Si comienzan la clase con «Vamos a hacer un Angry Birds pero necesitamos averiguar como programar el lanzamiento de los pájaros con la resortera» será mucho mas ameno y divertido que si empiezan con un «Y esto es un polinomio de segundo grado y deben de aprenderlo bien porque les va a servir cuando hagan juegos». Al final de ambas clases los alumnos sabrán como se relacionan los polinomios de segundo grado con el tiro parabólico y el movimiento con aceleración constante pero los primeros habrán puesto mas ateción y lo mas importante: Habrán aprendido a resolver un problema de programación de videojuegos usando las mismas matemáticas que usaría un programador verdadero. Si los alumnos van con la idea de que hay un conocimiento oculto que les permitirá hacer sus juegos y los maestros los reciben con la conciencia de que sus alumnos quieren aprender cosas que les van a servir para hacer videojuegos y animación ambos se verán beneficiados y con ello será posible levantar en latinoamérica verdaderas escuelas de animación y desarrollo de videojuegos. Pues recuerden que hasta hace poco el decir que ingresarían en una escuela de programación de videojuegos sonaba tan increible como anunciar que pretendían aprender a manejar el Sable de Luz con el Maestro Yoda o ir a entrenar al Santuario para obtener la Armadura de Pegaso. Hoy en día ya existen verdaderas carreras universitarias que aunque no sean las mejores, al menos ya existen. Ustedes tienen una oportunidad que muchos otros nerds de hasta hace poco nunca tuvieron, y lo mas importante. Muchos ingenieros arruinaron su vida profesional o se amargaron en la carrera para lograr que las universidades tomaran en serio esta clase de temas. Y si un dia se sienten decepcionados por estas escuelas, recuerden que pueden recurrir a mi aunque sea para tener a alguien que los escuche quejarse.