¿No tienes tiempo? La solución puedes encontrarla justo al despertar

–No confundas la falta de tiempo con la falta de atención–

Cierto sabio me dijo un dia que cada que alguien me dijera las palabras «no tengo tiempo» las cambiara por «no me importa». De ese modo si alguien me dice que no tiene tiempo para descansar, ver a sus familiares o simplemente aprender algo sobre programación lo reinterpretara como que no le importa su salud, su buena relación con los demás y le da igual que las computadoras cambien porque como quiera le pagan. ¿Pero qué pasa cuando uno mismo quiere que el tiempo le rinda y no lo consigue? En esos casos el problema es otro: La distracción.

Toda mitologia tiene personajes capaces de distraer a los aventureros para que no cumplan con sus misiones o bien para aprovecharse de los viajeros incautos: Seres que con su canto atraian a los marineros, pequeños cambiaformas que le tomaban el pelo a quien se adentraba en el bosque o por supuesto el dios Maia de los antiguos hindues que podia manipular la percepción de la realidad de los humanos. Sin contar multitud de entes menores que hicieron que caminantes se perdieran para nunca ser encontrados con vida. Pues bien, en nuestros dias estamos rodeados por muchas cosas diseñadas para robarnos la atención tanto dentro del internet como en el mundo real. En cualquier momento podemos caer en una distracción que nos saque de lo que queremos o tenemos que hacer y para cuando nos damos cuenta pasaron muchas horas y no nos dimos cuenta ni de cómo.

¿Cuantas veces no les ha pasado que despiertan a buena hora pero para cuando logran salir de casa ya van tarde? O que llegan a casa a descansar y para cuando al fin logran pegar el ojo ya se hizo de dia? ¿Cómo podemos escapar de estas trampas hipnóticas que están en todos lados?
La respuesta es tan sencilla como sorprendente. O al menos es la solución que me funcionó a mi:

SNOOZE: Ese botón que parece tan inutil

Toda la vida o al menos desde que nadie me despierta por la fuerza he usado un despertador aún en dias libres. Y todos los despertadores digitales que he tenido cuentan con un botón que hasta hace poco me parecia una reverenda idiotez: El botón Snooze. Su función es silenciar la alarma por 5 minutos. Pensaba que para dormir esos «cinco minutitos más». ¿Pero para qué usarlo? Si quisiera dormir más iria a la cama 5 minutos antes. Lo que luego comprendí es que el botón snooze no es para dormir: ¡Es para mantenerse despierto!

De hecho la palabra snooze puede traducirse como estar adormilado o como cuando uno puede caer dormido en cualquier momento. La función de snooze nos obliga a mirar el reloj y a presionar un botón cada 5 minutos. Y ese espacio de 5 minutos nos parecerá de 5 segundos si caemos dormidos sin darnos cuenta o algo nos distrae.

En experimentos que he hecho he mantenido activo el snooze en un smartphone todo el tiempo entre que despierto y salgo a la calle. Hacer esto ha hecho que salga más temprano y también sirve a la hora de pasar tiempo en internet. Las redes sociales con sus clickbaits y publicaciones con miniaturas engañosas por no mencionar cosas vergonzosas que amigos del face que nunca nos hablan hacen públicas pueden hacer que el tiempo se nos escape sin que lo sepamos. Snooze nos regresa a la realidad al obligarnos a ver el reloj o por lo menos nos fastidiará hasta que lo apaguemos.

Otro momento algo menos intuitivo para usar el snooze es a la hora de leer. Parecería que una alarma que nos interrumpe cada 5 minutos y nos obliga a soltar el libro nos desconcentraria pero es todo lo contrario. Muchas veces al leer dejamos de prestar atención al texto y nos ponemos a pensar en otra cosas mientras nuestros ojos van y vienen por la hoja. otras veces directamente nos quedamos dormidos con el libro como almohada. Como cualquiera que haya leido un libro sin tener idea del esfuerzo mental que esto supone conoce.

En general no he encontrado casi ninguna actividad en la que este uso del snooze no traiga beneficios. Tal vez las únicas sean aquellas donde desviar la mirada y las manos por un segundo sea peligroso. Como el conducir un vehículo. O cuando necesitamos dormir, pero eso no tengo que aclararlo. Otro momento en el que tal vez sea mejor no usarlo es cuando debemos permanecer en silencio. Pero si el dispositivo tiene modo de vibración ese no es un problema. En casos así es mejor programar una alarma para que suene al terminar esa actividad peligrosa y luego continuar con el snooze.

Cuando uno hace esto logra un interesante efecto: La sincronización. Pues llega el momento en el que somos capaces de adelantarnos al sonido de la alarma y hasta lo anticipamos. Y esta actividad en si puede volverse hasta emocionante. Sobre todo porque nos hace más eficientes en un tiempo en el que la atención es una moneda que a cada oportunidad nos roban.

¿Y cómo descubrí esto? Digamos que he estado programando algo que en la categoría de app de productividad. Algo que me ayude a programar cuando estoy frente a la PC y que haga mi existencia más eficiente cuando esté lejos de esta. Por ahora no supera a una agenda de papel pero cuando lo termine será como… bueno. Mejor lo termino primero. Siempre comienzo cosas y en el mejor de los casos estas terminan siendo algo diferente a lo planeado, si hay suerte algo mucho mejor. Si no la hay caen en el olvido. Pero como dije en la entrada anterior el olvido se acabó. Pues a este proyecto ya le asigné su espacio en el Cementerio de los Sueños. Y ya lleva ahí más de dos meses.

Regreso al Cementerio de los Sueños

–Mi plan para terminar las cosas que dejé inconclusas–

Hace poco me preguntaron por un par de notas escritas hace ya años. Una era sobre como los proyectos de programación que son olvidados se pierden para siempre y la otra es sobre un viejo problema que en su tiempo me hizo perder muchos buenos proyectos: Mi antigua incapacidad de mantener un proyecto a lo largo de meses o años. Es muy pronto para anunciar que ya resolví ese problema del todo. Pero ahora a casi dos años puse en marcha un mecanismo para resolverlo. ¡Si!¡Lleva dos años funcionando! Y se trata de lo que sale en la foto: El Cementerio de los Sueños.

Al principio consideré llamarlo Muro de los Lamentos pero como hablar de temas relacionados con (((ciertas personas))) aunque sea en broma es bastante peligroso decidí cambiarle el nombre. La primera designación era porque se trataba de un muro donde pondría papeles sobre cosas que quería hacer y que me lamentaria de ellas hasta terminarlas. Pero también me basé para construirlo en tradiciones de otros lugares. Como la de las figuras que se les pinta un ojo al iniciar una tarea y el otro al terminarla, la de un árbol en la que los creyentes colgaban notas con sus intenciones a los dioses. Y otras ideas que saqué de otras costumbres antiguas recicladas por la cultura popular.

¿Y cómo funciona el Cementerio de los Sueños? Simple. Cada que quiero hacer algo que se que me va a tomar meses o años me invento un nombre para ese algo que quiero hacer, invento una imagen que lo represente y marco la fecha de inicio. Paso a un pequeño trozo de papel esos datos y lo pego en un sobre de cartón que luego clavo con tachuelas en una superficie donde se puedan clavar cosas. La figura que representa el sueño o lamento se dibuja incompleta y no es hasta que la tarea se cumple que la figura se completa y el sobre se sella. Ya sellado pasa a la Cripta de los Lamentos Silenciados. ¿Y qué hay dentro de los sobres? Pues dentro hay otros papeles que representan pequeños objetivos en que la tarea principal se divide. Los que saben de negocios llaman a estas cosas «milestones». Cada uno de estos sublamentos como prefiero llamarlos tienen el mismo formato del lamento original: El objetivo menor, una imagen genérica incompleta, una fecha de inicio y un espacio para la fecha de finalización. Y como no siempre se tiene un plan definido con pasos establecidos desde el principio, estos pequeños subobjetivos se van agregando cada que es necesario. Obvio es posible que algunos se ignoren por completo por no ser indispensables para el objetivo final. Algo así como las misiones secundarias.

La idea original de este antes macabro y hoy poético invento es que cada cosa importante que quisiera hacer no cayera en el olvido. Sino que se convirtiera en una especie de fantasma que me observa al despertar, al tratar de descansar y antes de ir a dormir. ¿Y se ha logrado algo? Hasta ahora dos cosas que llevaba años sin terminar se han hecho gracias al Cementerio de los Sueños. La primera fue arreglar un problema con el servicio de internet que me estaba haciendo pagar de más. El otro fue la ampliación del propio cementerio. Pues al principio usé un pizarrón de corcho. Nunca encontré un pizarrón lo bastante grande para clavar en él todas las cosas que tal vez nunca terminaré. Al final descubrí que las placas de tablarroca sobrantes de la última remodelación del centro de operaciones resultaron mejores y más baratas que el pizarrón de corcho. Tal vez en el futuro cubra toda una pared con tablarroca para llenarla de cientas o miles de sueños/lamentos que tal vez nunca termine ni silencie.

¿Y qué sueños no cumplidos habitan en el Cementerio de los Sueños? No puedo mencionarlos todos porque no tengo espacio y porque algunos me averguenzo de no haberlos cumplido todavía. Pero puedo decir que todos se relacionan con la programación en mayor o menor medida. Así que no esperen encontrar sueños normies del tipo «Encontrar a alguien que gane más que yo para que me mantenga antes de que mi ADN se pudra» o alguna otra cosa que haga infelices a aquellos que tienen las necesidades más básicas resueltas.

Si bien todo tiene que ver con la programación hay proyectos que todavia no son funcionales pero que muchos creen que llevan años corriendo. Y eso es algo que no me enorgullece. Por otro lado todas las cosas dependen en buena medida de mi. Así que tapoco hay nada que esté por completo en manos de otros o que dependa demasiado de la suerte.

Por cierto, algo que va a poblar pronto este Cementerio de los Sueños es un plan que tengo para diversificar mis actividades. Tanto indie con herramientas juegomáticas y la falta de emprendedores del videojuego con dinero que recurrian a mi cuando no les quedaba de otra comienzan a incomodar mi estilo de vida. Así que prepárense para ver lo mismo que encuentran aquí en otros formatos. Ya si no consigo el sibarita nivel de vida que tenía antes mínimo me daré a conocer en círculos en los que aún nadie sabe de mi existencia. Por un tiempo no pondré todos los huevos en una única canasta. Espero no volverme yo mismo un residente permanente de mi propio Cementerio de los Sueños.

 

Por qué no hay que usar pixeles como unidad de medida

–Si no usas medidas reales inventa la tuya–

Uno de los recuerdos que tengo de cuando apenas comenzaba a programar se remonta a los años noventa en la que vi la presentación de un cierto plataformas 3D muy famoso por esa época. Entonces apenas entendía como dibujar lineas y polígonos en pantalla y como todo principiante usaba los pixeles como unidad de medida. Hasta que vi ante mi algo que entonces creía que era imposible de programar: ¡Un cambio de resolución a mitad del gameplay! Y no cualquier cambio. Sino uno que entraba de modo instantaneo al seleccionar la opción en un menú al pausar la acción. Sin relecturas de archivos, bajadas de respuesta del control y con una baja de framerate apenas perceptible en los modos de resolución más altos. ¿Pero por qué me pareció algo tan impresionante? Ahora les contaré.

Hasta ese entonces, nunca habia visto un juego que cambiara de resolución de modo tan sencillo. Por lo menos era necesario reiniciar la partida o si lograban correr bien las imágenes se mostraban achaparradas y deformes dejando el juego injugable. Esto último lo recuerdo con el primer Quake que al ponerlo en otro modo que no fuera el viejo 320×200 dejaba a los monstruos como enanos hechos con cartones de leche. Además de que los mensajes escritos eran ilegibles.

Y esos cambios de resolución tan bien hechos iban más allá de cambiar la cantidad de pixeles en pantalla: Incluso podian variar el aspect ratio (la proporción entre el alto y ancho de la pantalla) al abrir y cerrar la toma sin deformar la imagen. Y hasta podian pasar la acción entre ventana y pantalla completa sin cortar el gameplay.

Eso mismo tardé en verlo en juegos 2D pero llegué a verlo años más tarde. Sobre todo cambios de escala y rotación (por software, no como los del SNES) sin que la imagen se «pixeleara». Si acaso se le veian contornos borrosos al hacerle zoom. Esto por el antialias del que otro dia les hablaré en profundidad. Con el tiempo, cuando fui capaz de leer los signos arcanos en los que se escriben las ecuaciones entendí una verdad evidente: ¡Si esos juegos podian hacer esas cosas con los pixeles era porque en sus cálculos gráficos no tomaban en cuenta los pixeles!

O al menos no los tomaban en cuenta hasta el momento de mostrar la imagen final en pantalla. ¿Y entonces qué usaban? Eso lo veremos más adelante, pero como saben quienes han trabajado con programas de diseño asistido por computadora o CAD, es posible usar medidas del mundo real como pulgadas o milímetros en un modelo 3D y luego presentar imágenes de ese modelo en cualquier tipo de soporte, ya sea en pantalla o impreso. Este sistema se basa en transformaciones de coordenadas y sistemas ortogonales pero sólo se usa en 3D muy serio como el CAD. Aunque no dudo que algunos juegos poco optimizados lo utilicen. De eso ya hablé en la serie sobre 3D y tal vez profundice otro dia en otra nota. Pero antes de ver como podemos hacer lo mismo veamos por qué no debemos de usar pixeles como unidad de medida. Cosa que todos hemos hecho cuando principiantes.

Los pixeles no son lineales

Los pixeles cubren la pantalla como los mosaicos cubren un piso. A nivel abstracto son cuadros sin espacios entre ellos. Aunque dependiendo de la tecnología del sistema pueden ser puntos de luz. Y al igual que los mosaicos que cubren el suelo, los pixeles son bidimensionales. Tienen ancho y altura. Y aunque su ancho o altura por separado, suponiendo que no sean pixeles rectangulares puede usarse como medida en cálculos en vertical u horizontal todo se va al traste cuando las cosas comienzan a dar vueltas.

En esta imagen vemos un triángulo de 5 pixeles de base por 5 pixeles de altura. ¿Cuanto mide la diagonal? Según las matemáticas. Para un triángulo rectángulo cuya base y altura son iguales y sea un valor X (X es 5 en este caso) la diagonal mide X multiplicado por la raiz de 2. Que en este caso 5 por la raiz de dos seria aproximadamente 7.071 o una cosa insignificante más allá de los 7… ¿Pixeles?

¡Pero según la imagen la diagonal del triángulo mide 5 pixeles! ¿Ahora entienden por qué no deben usarse pixeles como unidad de medida? Piensen lo que pasaria con un segmento de linea que rotara por uno de sus extremos como lo hacen las manecillas del reloj. Si lo que queremos es que esa linea describa un círculo al rotar como lo hacen las verdaderas manecillas del reloj, la cantidad de pixeles de la linea variaria conforme gira. Por ejemplo si la linea es de 10 pixeles no siempre va a medir 10 pixeles. Sino que variará entre 7 y 10. Si siempre midiera 10 pixeles en lugar de un círculo, la linea barreria un área en forma cuadrada. O dependiendo del algoritmo una figura convexa de bordes irregulares. En este dibujo se muestra con puntos los pixeles de la linea que quedan dentro del círculo y con cruces los que quedan fuera de él si usamos pixeles. Aunque aquí la linea es de 9 pixeles porque no encontré una tapa que abarcara 10 cuadros en la hoja.

Otra razón por la que un programador no usa pixeles como unidad de medida es por supuesto por los cambios de resolución. Si usáramos pixeles para operaciones durante el juego tendríamos que cambiar todos los valores de las operaciones que las usaran con cada cambio de resolución. Por ejemplo si las dimensiones de los objetos en el juego se dan en pixeles tendríamos que tener un conjunto de dimensiones para cada resolución de pantalla que manejáramos. ¿Y si queremos actualizar el juego con imágenes de mayor calidad? No podríamos porque de hacerlo tendríamos también que modificar el código. Lo mismo si usamos pixeles para las distancias. Un personaje tardaría más en cruzar una pantalla de mayor resolución si no modificamos los valores de velocidad cada vez. O si diseñamos al personaje en una pantalla con un aspect ratio de 4:3, al verlo en una de 9:16 se vería más gordo. El único cambio que el jugador va a aceptar cuando le suba la resolución al juego es la mejora en la calidad de imagen. No quiere que las cosas se deformen, se hagan más lentas y mucho menos que el juego falle porque los valores que controlan la lógica no se actualizaron como debian. Si, ya se que una pantalla de mayor resolución tarda más en actualizarse y requiere imágenes más detalladas. Pero ni la RAM del PC Master Race del jugador ni el presupuesto de desarrollo son suficientes para tener sprites o texturas pensadas para todos los modos gráficos que existen.

¿Y si no se usan pixeles?¿Qué se usa?

Eso depende de las capacidades del sistema y las necesidades. Si estamos trabajando con cosas serias necesitamos una computadora con capacidades de punto flotante y usar medidas del mundo real como metros, pies, micras o lo que sea que el que paga demande. Pero si ustedes fueran ese tipo de público no estarian leyendo esto así que supongo que quieren hacer juegos para sistemas que requieren mucha optimización. Así que les revelaré uno de mis secretos confiado en que pocos van a poder implementarlo de manera decente: La unidad de medida dentro de un videojuego es igual a lo más pequeño que en tu juego exista.

Si bien este concepto no es por completo mio no he visto que alguien lo llame de alguna manera. Algunos lo llaman «character» como las letras de los sistemas de texto. En una antigua revista de videojuegos le llamaron el «medio paso». Pero yo prefiero llamarle a esta unidad simplemente «u». Es una unidad lineal. Para superficies y volúmenes manejamos «u^2» (u cuadrada) y «u^3» (u cúbica). ¿Y cuanto mide una «u»? Pues eso depende de lo que trate tu juego y la cosa más pequeña que exista en su universo. En un juego de plataformas y tiros como un Mega Man una «u» es lo que mide una bala de largo, una U^2 lo que ocuparia al estar sobre el suelo y una U^3 el espacio que ocuparia en un mundo tridimensional. Lo ideal es que el objeto más pequeño abarque lo más posible la medida de «u» aunque no la abarque por completo. Cosas más grandes pueden crearse como múltiplos de «u». Por ejemplo un personaje en 2D puede estar hecho de 2 por 4 u’s cuadradas o tener parte del sprite fuera de los cuadros definidos por la unidad cuadrada «u». Ese es el ejemplo de la imagen. Si queremos hacer un juego de estrategia entonces la unidad «u» sería la longitud de un soldado, un tanque podria ocupar digamos 2 por 2 «u» y una fortaleza varios cientos de «u» por lado.

Pero la unidad «u» no nada más sirve para medir distancias de manera confiable. También se usa para optimizar las colisiones. Si dividimos el terreno en U’s cuadradas como un tablero de ajedrez y hay dos objetos que abarcan como mínimo cada uno de esos cuadros completos ocupando el mismo cuadro lo más seguro es que estén tocandose y eso es muy sencillo de detectar con código (dejo eso como ejercicio para el lector). También ayuda a programar mallas de navegación al combinarse con un grafo y permite una más rápida construcción de los niveles. Pero sobre todo podemos cambiar resoluciones y modificar el arte como queramos. Mientras se respete la unidad «u». Por eso en los juegos de tiempos del NES cosas como las balas y los items o power ups eran tan grandes. ¿O alguien creyó que un CPU de 8 bits que apenas si ejecutaba unas pocas miles de instrucciones por segundo podia correr algoritmos como el de cajas acotantes para las colisiones o de análisis de imagen para saber como estaban colocados los objetos unos respecto a otros?

Sea como sea no usen pixeles como unidad de medida. Los pixeles no van más alla de la entrada y salida de un programa. La lógica debe de ser independiente de ellos. Si están programando un editor gráfico conviertan las coordenadas de pixel de entrada en unidades «u» y luego al representar conviertan las unidades U a pixeles. No quiero que su juego tenga bugs y exploits tan tontos como esos en los que avanzas más rápido si te mueves en diagonal o personajes que se quedan atorados al pasar junto a una mesa porque la tocó sin querer con uno de sus pixeles. Luego no digan que no se los advertí.

 

El mito del emprendedor que comenzó desde cero

–Cuando el perderlo todo no significa nada–

Cierto escritor latinoamericano dijo alguna vez que todo hombre sin importar en qué epoca hubiera vivido siempre dirá que vivió en el peor de los tiempos. Da igual que tan bien viva siempre encontrará de qué quejarse. Yo mismo pasé por una época en la que usé este espacio para quejarme de que mi vida color de rosa no era del tono rosa pasteloso que me hubiera gustado. Por eso cuando paso por alguna dificultad dejo que pase un tiempo para contarla como algo divertido y emocionante. Y también porque no quiero que en el futuro algún troll me descubra algo comparable a esta captura de pantalla:

Así es. Para decepción de muchos entrepreneurs o startuperos tecnológicos. La historia del famoso emprendedor y pionero del comercio electrónico que el fundador de Amazon nos contó no estaba completa. Si bien la historia de que tuvo que usar una puerta como escritorio fue cierta no lo hizo porque fuera pobre o hubiera comenzado desde muy abajo. Tampoco fue cierto que no contaba con el apoyo de nadie porque se sabe que tenía contactos en Wall Street y su familia le dio una pequeña fortuna para comenzar su negocio. Tal vez lo único admirable de este personaje es que supo hacer crecer su negocio hasta lo que es en nuestros dias. A diferencia de sus competidores que comenzaron con más dinero y no resistieron en el mercado por más de dos años.

Enterarme de este tipo de cosas me pone de mal humor. Pues como saben decidí programar por la poca inversión que se necesitaba para entrar. Pero hasta ahora todos los emprendedores tecnológicos exitosos (pocos) o fracasados (muchos) que he conocido han cumplido siempre con un requisito para mi decepcionante: Más temprano que tarde se cruzan con alguien que les otorga una enorme, gorda y tintineante bolsa de dinero. Algunos, los más respetables, les llega por parte de alguna empresa multinacional que les compra la idea o les propone desarrollarla en conjunto con ellos. Pero la mayoría obtiene este financiamiento por medios mucho menos admirables como el Vampire Capital, crowdfunding, apoyos del gobierno o la favorita de muchos: Naciendo ya con él. O trustfund babies como les llaman en los paises civilizados.

¿Y qué hacen con ese dinero? Pues por supuesto pagarle a alguien más para que hagan el trabajo que ellos deberian de hacer con dinero que no es de ellos y quejarse en internet de que pegar post-its (A veces post-tits) en un pizarrón de corcho es superestresante y que por eso se merecen los sueldazos que se autoasignan. Otra cosa que he visto es que en torno a ellos se crea una especie de ecosistema chupasangre diseñado para sacarles ese dinero que se sacaron de la nada. Por ejemplo servicios de «incubadoras de empresas» o «los íncubos» como prefiero llamarles que por el costo de la renta de un departamento una prestigiosa institución te concede el privilegio de usar 4 metros cuadrados en un rincón inaccesible de sus instalaciones que tu mismo tienes que amueblar, equipar y por supuesto pasar por una aduana cada que quieras entrar o salir. Y por un poco más hasta puedes tener el privilegio de chatear (en texto, nada de video) con supuestos expertos en negocios que son libres de ignorarte si les hablas el dia del mes que no debes. No dudo que deben de ser expertos en negocios. Pues convencer a incautos para pagar ese tipo de servicio es todo un logro. Pero sigamos con el trolleo y el rant.

Por eso ya no quiero investigar más sobre mis ídolos de la computación. Todavíá no me recupero del susto que me llevé cuando me pasó con Alan Turing lo que a Homero Simpson con Javier. Prefiero seguir creyendo que historias como la de los banqueros brasileños y el repartidor de pizza al que le financiaron sus proyectos es falsa.

Sin embargo, este exceso de prudencia que raya en cobardía la he visto más en negocios de software o que tienen que ver con éste. Pues me ha tocado ver gente de otras áreas que pierde su casa por un mal negocio o que tiene que ahorrar por años tan sólo para poder sobrevivir unos meses mientras que su intento de negocio se vuelve rentable. Pero en software, sobre todo en software relacionado con cosas multimedia he notado que se repite un cierto perfil: Individuo entre veintipocos y treintaimuchos años, de familia adinerada pero que se considera a si misma clase media, con estudios en el extranjero y trabajo seguro en las empresas de sus padres al salir. Pero como se trata de startuperos valientes e indomables que no quieren aburrirse en sus oficinas con su respectivo Save Point en la entrada prefieren crear su propio negocio desde cero. Y como sus padres quieren que sepan lo que es ganarse su propio dinero, en lugar de darle una fortuna para que inicie le dan el contacto de algún inversionista, político o patrocinador para que obtenga esos fondos por el mismo. Porque eso si, Iesa gente presume mucho de que el trabajo esto y el trabajo aquello pero cuando hay que hacer algo que en verdad pone en riesgo el físico o la estabilidad mental ahí es donde les sale el instinto de generación de empleos y se buscan a alguien que les haga el trabajo por una minúscula fracción de los fondos tan trabajosamente obtenidos. Y dependiendo de la cuantía de esos fondos pueden subcontratar a otra empresa que les haga la programación, contratar a sus compañeros que estudiaron con beca-crédito y les urge (palabra mágica en México) encontrar trabajo para pagarla o ya si están muy desesperados buscar mano de obra barata en las escuelas públicas.

Obvio estos personajes nunca se arriesgan. Pues rara vez tienen pérdidas que ponen en riesgo su patrimonio. Pues si no pueden pagar los préstamos venden todo lo relacionado con el negocio y vuelven a comenzar otra vez. Aunque a veces algunos de los trabajadores que por lo común son echados a la calle sin pagarles por sus servicios arman algún escándalo. Pero casi siempre prefieren marcharse sin cobrar todo lo que se les debe que arriesgarse a que no los quieran volver a contratar por «conflictivos». Esto se ve mucho en trabajadores de multimedia y efectos visuales.

De esta clase de pseudoemprendedores suelo burlarme cuando me vienen con el drama de que ellos sufren mucho para sacar adelante a la industria. Aunque no se si los peores son ellos o los que les hacen el trabajo pesado creyéndose profesionales de una industria que no sabe ni le importa su existencia en lo más mínimo.

¿Apuestas tu vida?

¿Pero todos los emprendedores tecnológicos son así? Pues hasta ahora todos los que he visto que viven de lo que les dura el dinero del inversionista si que lo son. Pero existe otra especie que no son considerados emprendedores porque rara vez logran vivir de esa actividad ya que viven de otra cosa. No me atrevo a llamarles amateur o hobbistas porque algunos lo toman muy en serio y le dedican unos recursos que cualquier otro consideraría esenciales para sobrevivir. Algunos pocos logran ganar dinero con algunos proyectos. Pero esos proyectos nunca les llegan a generar lo suficiente para abandonar sus trabajos normales. En parte porque sus trabajos normales les consumen demasiados recursos. Aunque me he topado con emprendedores casi suicidas que al no tener una fuente de recursos confiable se lanzan a cualquier aventura que les prometa un mínimo retorno de inversión en tiempo y esfuerzo porque dinero no tienen.

Personalmente admiro a estos valientes que destinan lo que les queda de la subsistencia diaria para hacer lo que quieren. Sobre todo porque usa su propio dinero, tiempo y conocimientos en lugar del dinero, tiempo y conocimientos de alguien más. Por no mencionar que arriesgan su patrimonio y hasta la salud al quitarle horas y dias al descanso y a la convivencia familiar y a eso que los normies llaman «vivir». Pues al igual que en el antiguo juego de Alex Kidd cuando el jugador participaba en el juego de piedra, papel o tijera y no tenía dinero para apostar se le permitía participar si al jugar y perder aceptaba que le quitaran una vida.

Y tú… ¿Apuestas tu vida?

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.

¿En qué demonios se gastan tanto dinero los indies?

–Cuando tres millones de dólares no te alcanzan para comer–

Alta tecnología y bajo nivel de vida. Con esta frase suele describirse el género de ciencia ficción conocido como Cyberpunk y es también la frase con la que iba a iniciar una serie de entradas en las que iba a contar mi emocionante vida pero al final decidí no publicarla porque no quiero perratencionar. Así que de todo aquel texto lo único que voy a retomar es la discusión sobre los costos de programar un videojuego fuera de la industria.

Hace mucho un empresario de la computación llamado Jack Trammiel, famoso por crear las computadoras Commodore dijo una gran fase: «El programador es el verdadero alquimista porque puede crear cosas a partir de la nada». Y con esa idea en mente fue que decidí dedicarme a la programación pues lo único que necesitaba para crear cosas de la nada era conocimiento, mucha dedicación y una computadora. Y eso para mi era un precio pequeño a cambio de la grandeza. Y bien, pues que recién me entero que cierto personaje de fama internacional lleva juntados un par de millones de dólares y contando y a pesar de tener a su disposición todo lo necesario para hacer su juego ya pasaron casi tres años y todavía está muy lejos de terminarlo. ¿Y qué juego es ese? Supongo que si digo que se trata de una experiencia indie injugable con un protagonista étnico y que el desarrollador más famoso al frente del proyecto es más conocido por perratencionar en las redes sociales que por hacer juegos esa descripción se adaptaría a casi cualquier juego indie hecho en los últimos cinco años. Así que dejémoslo como uno más del montón.

Ahora mismo mientras escribo este texto tengo poco de que vi un video donde unos youtubers defienden este proyecto con este discurso:

«Si al viejo Super Metroid le quitamos de los créditos al personal administrativo y dejamos a los que participaron en el desarrollo nos quedan 26 empleados. Si el desarrollo tomó un año de burocracia y dos de trabajo nos da 3 años y si multiplicamos 26 personas por lo que sea que ganen al año que no es poco nos da una cifra superior a los 10 millones de dólares. Entonces si dividimos los dos millones de dólares que el indie juntó entre todos los desarrolladores trabajando por lo menos 3 años el resultado da unos 20,000 dólares al año y tomando en cuenta la economía de Estados Unidos si una persona gana menos de 25000 dólares al año es considerado como pobre por el gobierno y este hasta le da dinero y le perdona impuestos para que no se muera de hambre. Así que sean niños buenos y donen más dinero a su campaña de crowdfunding. Aquí abajito les dejo el link para que aporten y descárguense el demo. Si, ya sabemos que el demo está lleno de bugs pero es porque se trata de un prototipo y la calidad del producto final será mucho mejor.»

¿En serio? Creo que no me había sentido tan disgustado con el desarrollo de videojuegos desde que me enteré de la existencia del puesto de «retocadora de botones de interfaces». Así que ahora voy a desmontar esos argumentos, o mas bien pretextos, de uno por uno.

Pretexto 1: «Es que mi juego es como Super Metroid».- Para empezar es un insulto comparar el Super Metroid o cualquier otro juego de SNES con un juego indie de hoy por mucho que se vean iguales. El Super Metroid fue un juego creado a inicios de la década de los noventa y corría en una consola de videojuegos de 16 bits cuyos juegos median entre 128 kilobytes y 4 megas. Y era una de las consolas de videojuegos más avanzadas de su tiempo junto con el Sega Génesis. Además las herramientas de desarrollo con las que la entonces todopoderosa Nintendo contaba no tienen comparación con una computadora actual equipada con una tableta gráfica y un disco duro lleno de engines y software de diseño que cualquier niño rata puede descargarse de internet para sentirse «+ PRO». Por no mencionar que un juego indie que «se ve retro» como el Super Metroid no tiene para nada los mismos requerimientos técnicos que un juego de ese entonces pues requiere de hardware mucho más poderoso que el SNES para verse igual. O para que se entienda mejor: Es imposible que un juego indie actual que parece de consola antigua corra en cualquiera de esas consolas antiguas a las que trata de imitar. La comparación sería más justa si el juego fuera un juego con una estética y tecnología actuales y que compitieran en ventas como cualquier otro título comercial sin pretensiones intelectuales.

Pretexto 2: «Es que somos muchos empleados».- Si bien es cierto que proyectos grandes requieren equipos grandes también es bien sabido que en proyectos de programación (como son los videojuegos) mientras más gente se involucre en un proyecto más complejo se vuelve. En las grandes empresas en las que trabajan cientos de programadores tienen personal cuya única tarea es mantener todo el código en orden. En cuanto a otras áreas como la creación de assets gráficos la demanda del trabajo no es lineal a lo largo del proyecto. Es decir que durante un tiempo trabajan horas extra y el resto cobrarán por no hacer nada. Además como cada artista tiene su propio estilo tener demasiados de ellos hace necesario que alguien mantenga esas diferencias de estilo al mínimo.

Pretexto 3: «Es que no tenemos tiempo suficiente».- Hay una regla en programación que dice que un proyecto siempre te va a tomar más tiempo del que crees aún si ya consideraste que te va a tomar más tiempo del que crees. Y si no me creen sepan que hay ramas de la computación enfocadas únicamente a manejar los tiempos de desarrollo del software para al menos hacerlos predecibles. De hecho existen multitud de modelos de trabajo para cada necesidad pero una cosa es segura: Dar una fecha de entrega de un proyecto que no has comenzado a programar es un acto de lo más irresponsable. Un software no está terminado hasta que no se han corregido todos los bugs y eso toma mucho más tiempo que el hacerlo funcionar a un nivel presentable. Ya no nos metamos con los n00bs que creen que lo peor que les puede pasar es que el programa «no compile».

Pretexto 4:»Es que no nos alcanza con tan poquitos millones de dólares».- Este se relaciona mucho con el del tiempo. Pues si vamos tener que pagar salarios constantes por un proyecto que no sabemos cuando se va a terminar vamos a pagarlo muy caro. Por no mencionar que la gente que se dedica a hacer juegos tiene la idea de que deben de pagarle mucho dinero por su linda cara. A mi por ejemplo cada que alguien se queja de que les ofrecen poco y que por administrar bases de datos o hacer animación para comerciales les pagan más dinero les digo que mejor dejen de dedicarse a hacer juegos. Otro detalle y aquí trataré de no meterme demasiado en política es que un salario de 25000 dólares anuales es considerado un salario bajo en Estados Unidos y tal vez en otros sitios como Japón o la Unión Europea. Sin embargo en paises no demasiado primitivos (donde pueda funcionar una computadora con internet) con 25000 al año se vive bastante bien. Por ejemplo un desarrollador mexicano que no esté maleado por la H.Industria y sea responsable con las tarjetas de crédito puede mantener con ese dinero a una mujer y a dos hijos. Aunque desde luego la manera de trabajar en estos paises sería muy diferente a lo que se hace en paises con salarios más altos.

Personalmente considero que si en latinoamérica no se han desarrollado más videojuegos es en parte porque intentan copiar modelos de producción diseñados para una economía diferente a la suya. Pero de eso hablaré otro dia.

Pretexto 5:»Mi juego corre tan mal porque es un prototipo».- Este en el caso que estoy viendo es el que más me preocupa. Ya he trolleado en incontables ocasiones a indies que suben un video de gameplay donde se ve que el juego es una auténtica porquería pero se defienden argumentando que es apenas un prototipo muy básico y que si le damos 6 meses más y otro millón de dólares el juego lucirá super ultra mega #OSOM. ¿Y por que no les creo? Pues porque cuando el prototipo tiene fallas casi siempre es por culpa del código y como ya dije antes el código es impredecible. Puedo creer que el juego no esté terminado porque faltan 97 de los 100 mundos abiertos a explorar o que el indie pida más dinero a cambio de incluir contenido nuevo. Y eso lo perdono porque al tratarse de assets es posible calcular una fecha de entrega a partir de unos ciertos recursos pero si el prototipo tiene fallas de código esas fallas podrian no resolverse nunca sin importar cuanto tiempo y dinero extra les den.

¿Y qué aspectos de un videojuego dependen exclusivamente del código? Pues cosas tan básicas como un frame rate alto y constante, un control que responda bien a los comandos del jugador, que los personajes controlados por la computadora hagan lo que se supone deben de hacer y por supuesto que el juego corra en el hardware del gamer sin crashearlo ni causar funcionamiento errático. Es más. Para mi es más importante un prototipo bien programado y jugable que implemente todas las mecánicas de juego aunque los gráficos estén hechos en paint y se vea horrible que un video muy bonito de como el indie cree que se va a ver su juego cuando lo termine. Y eso lo sostengo porque el código es impredecible. En cambio el arte puede ser hecho en un tiempo establecido si se cuenta con la gente, herramientas y presupuestos adecuados. Cosa que aunque me apena admitir no pasa con los programadores. De hecho he sabido de unos cuantos juegos en los que toda la parte artística son mandados a hacer de manera externa en auténticos estudios de animación. Y aunque puede salir muy caro es lo más conveniente si ya se tiene un código confiable y el presupuesto lo permite.

Cuídense sobre todo de quienes prometen sacar juegos multiplataforma en hardware muy diferente entre si. Pues ya de por si es dificil obtener el beneplácito de los fabricantes de las consolas además estas pueden tener tantas diferencias a nivel hardware que requieran un reescalado y recolor de todo el arte o peor aún la reprogramación completa de todo el código del juego. Y no se confien tampoco de la supuesta portabilidad de los engines. Esa solo sirve si el juego no lleva a cada hardware a su nivel máximo de eficiencia. Aunque no creo que eso les preocupe a la mayoria de los indies. También hay que mirar con recelo a quienes prometen agregar funcionalidades que no tiene el prototipo. Cosas que los gamers ven como normales tales como modos multijugador masivo o personajes 3D con expresiones faciales de actores humanos (incluyendo lip-sync) pueden ser virtualmente imposibles de implementar para un indie que nunca antes las ha programado desde cero él solo. En resumen a nivel código un videojuego completo y un demo (o prototipo funcional) son exactamente iguales. Aunque puede darse el caso de que un bug no descubierto salga a la luz al introducir un asset nuevo.

Pretexto 6: «Denme más dinero y les acabo el juego el otro año.».- Esto es un error muy común. Ha habido casos en los que el indie retrasa la fecha de entrega una y otra vez y sube las metas para disimular el hecho de que no sabe cuando lo va a terminar. Personalmente preferiría que las famosas «stretch goals» (que yo prefiero llamarlas «slack goals») se limitaran a ser expansiones descargables.

Consejos para que te rinda el dinero al hacer tu juego indie

Pues ya di mis opiniones sobre argumentos indies y mi opinión sobre por qué creo que se gastan tanto dinero. Ahora daré unos consejos que tal vez le sirvan a alguien que quiera hacer juegos indie y para que sepan que hacer cuando la bolsa de dinero les caiga del cielo.

Programa primero y diseña después.- Si primero creas el código de un juego con todas las funcionalidades puedes estar casi seguro de que no habrá problemas con las fechas de entrega. Y digo casi seguro porque siempre está la posibilidad de que un bug se descubra cuando creas que el juego ya está listo.

Toma en cuenta gastos de permisos.- Muchas plataformas cobran cuotas obscenamente caras por el derecho a vender juegos en ellas. Revisa si la ganancia vale la inversión.

Programar es más barato que sobrevivir.- Conviertete en alguien que sobrevive con poco y tendrás más recursos y tiempo para hacer juegos. Pocos hablan de que gracias a esto los FPS de los noventa pudieron ser programados.

Se un fantasma.- Invéntate una identidad falsa para convivir con los normies. Nadie ajeno a los videojuegos debe saber que los haces. Otro dia hablaré en detalle sobre este punto.

Reutiliza lo que produzcas.- El código debe de ser escrito de modo que puedas reutilizarlo lo más que puedas. Un código funcional que no ha presentado fallas es muy valioso para olvidarlo. Pero esto también aplica a los assets. Puedes reutilizar partes de escenarios, personajes secundarios o hacer un sistema de creación de personajes a partir de partes intercambiables. Por ejemplo crear muchos tipos de ojos y cabello para hacer muchas caras diferentes. Incluso puedes reutilizar varios assets de un juego en otro y decir que ambos juegos ocurren en el mismo universo.

Vende productos terminados.- En la programación (y los juegos tienen mucha programación) se aplica la regla del «Ahora o Nunca». El código corre ahora y si no corre ahora es muy probable que no lo haga nunca. O dicho de otro modo un programa no funciona hasta que funciona. Nunca pongas una fecha de entrega si no tienes idea de que hacer. Si quieres que alguien te mantenga mientras haces un juego que tal vez no termines y aunque lo termines tal vez nadie pague por jugarlo estas perdido. Pero si sabes manejar tu tiempo y tu dinero puedes hacer juegos sin tener que abandonar tus obligaciones mundanas.

Ya para terminar quisiera dejar un último pensamiento: Se han contado en internet hasta el cansancio muchas de las hazañas de los programadores de los primeros FPS para PC que ni siquiera tiene caso mencionar sus nombres. Todos los admiran por haber programado cosas increibles y resistido muchas penurias. Pero muchos de ellos ni siquiera tenian una computadora propia y tenian que pedir prestada una a sus trabajos o escuelas. Uno de ellos iba a las tiendas con discos flexibles en mano a ofrecerlos a los vendedores. Ninguno tenía un salario que le permitiera vivir para hacer juegos y mucho menos un inversionista que les soltara millones. ¡Y con todo esto en contra lograron hacer juegos legendarios! ¿Con qué cara entonces viene un indie a decirme que 3 millones de dólares no le bastan para hacer un juego que no le llega a nivel visual a uno de aquellos juegos de los años noventa? Consideren esta nota como el primer trolleo que hago al gamedev internacional. Lo bueno es que este indie tal vez no tenga idea de español. Aunque no dudo que alguno de los miles de «fans» (no no precisamente son sus fans porque les gusten sus juegos) meta este texto al google translator y este espacio se llene de insultos en inglés. Sea como sea lo mejor es que me ponga a programar porque yo no tengo lo que estos indies tienen para darse la gran vida sin tener un juego terminado: Dinero.

Actualización del caso: Marzo 1, 2017

Si bien el caso que menciono en esta entrada no tiene nombre y por la descripción abarca a por lo menos cuatro juegos en desarrollo actualmente y varios mas que nadie conoce pocos son los que han logrado juntar tres millones de dólares. Y esta nota aunque la escribí unas semanas antes de subirla unas pocas horas antes de hacerlo me llegó una noticia interesante: El indie está pasando por una «Horda Mongoliana». Para lo que no conocen el término, una horda mongoliana es cuando un desarrollador ve que no va a terminar su proyecto a tiempo y contrata gente nueva para poder terminarlo dentro del tiempo y presupuesto asignados. Por fortuna para ellos esa horda mongoliana es de animadores y no de programadores. Porque si así fuera ya estuvo que su proyecto multimillonario no pasó de una versión ecchi 2D y weeaboo del Vagrant Story de PSX. ¿O sí lo es? Porque cuando revisé el «about» de su página vi que entre las diez personalidades importantes de la industria de videojuegos internacional que trabajan en ese juego… ¡No hay ni un miserable programador! ¿Habrán subcontratado a alguien para hacer el código del juego? Tal vez si, pues recuerden que programar no es algo que hacen los «chicos cool» y muchos indies famosos declaran con orgullo no tener idea de programación. ¿Podrá este indie sacar su esperadísimo juego? ¿Cumplirá el juego con todo lo prometido o terminará como el intento de resucitar a Mega Man con Mighty No.9? Pues eso en el mejor de los casos lo sabremos hasta la primavera del 2018. Claro, si alguien todavía se acuerda que ese juego iba a salir.

Como programar sin que te distraiga el internet o si no puedes estar en la PC todo el dia

–La Técnica del Escudo de Papel–

A veces las mejores soluciones a problemas de programación modernos las encontramos en los programadores del pasado. Y esta vez voy a discutir un problema que ha fastidiado a muchos de ellos desde que las computadoras comenzaron a usarse en cosas cotidianas. Sobre todo desde que se popularizó el internet: La distracción que representa para un programador una PC con internet.

Ya hace mucho mencioné que esto se llama (porque así le puse) Efecto Icaro y se trata de cuando una herramienta imprescindible para hacer un trabajo se vuelve un obstáculo para hacerlo si no tenemos disciplina. Pueden leer esta nota en este enlace

Si, ya se que es muy sencillo decir que la disciplina es suficiente para evitar distraerse con el internet pero aceptémoslo: Gente muy poderosa ha pagado mucho dinero a gente muy inteligente para que inventara formas de distraernos y mantenernos el mayor tiempo posible en sitios de internet cargados de publicidad. Y aunque usemos un bloqueador de anuncios lo único que conseguiremos es hacerle perder dinero a los anunciantes pero nuestro tiempo lo seguiremos perdiendo. Ustedes me entienden. Si programan en una PC con acceso a internet van a dejar la programación al menor descuido y para cuando recuerden que estaban programando ya habrán pasado muchas horas.

Lo que hace tan peligroso el Efecto Icaro es que si evitamos lo que nos distrar tampoco podemos hacer nuestro trabajo. Necesitamos la PC para programar. Por no decir que también documentación que se haya en internet. Entonces. ¿Cómo programamos sin distraernos?

La solución costosa es comprar dos computadoras y tenerlas en los extremos opuestos de la habitación. En una computadora hacemos todas las cosas normies como leer correos, jugar videojuegos (eso no es tan normie a menos que jueguen jueguitos casuals), conectarse a redes sociales, escuchar música o cualquier otra cosa que los que no son programadores hagan con su PC. Mientras que la otra se usa únicamente para programar y no la conectamos a internet y lo único que contenga su disco duro serán herramientas de programación y documentación offline. Pero como se que la mayoría de los lectores de este blog no tienen tanto dinero daré otra solución al problema del Efecto Icaro en la programación por menos de lo que pueden gastarse en unos pocos artículos de papelería.

Sin que suene a trolleo. Este sistema no sólo ayuda a concentrarse. Sino también sirve para aquellos que no pueden estar sentados frente a la computadora todo el dia por cualquier otro motivo. Pues verán que lo único que necesitan será un espacio despejado, tranquilidad y unos cuantos artículos que podrán conseguir en cualquier papelería. A este sistema le llamo El Escudo de Papel.

Para construir el escudo de papel necesitamos una carpeta con cierre, maletín o cualquier cosa que nos permita transportar papel y lápices a cualquier lugar sin que se pierdan o maltraten. Una libreta grande con cuadrícula, lapiz o lapicero, borrador y pluma. Otra pieza un poco más dificil de conseguir son tarjetas de cartón de 5×8 pulgadas pero cualquier material delgado y ligero en el que se pueda escribir y borrar muchas veces sin que se rompa es buen remplazo. Aunque no lo crean con estas cosas que cualquier estudiante puede conseguir sin demasiadas dificultades se pueden hacer muchísimas cosas de programación. de hecho cualquier cosa de programación aparte de compilar y ejecutar código la pueden hacer con estos materiales.

Antes de continuar quisiera contar una historia de los programadores antiguos: En tiempos remotos (no tan remotos en latinoamérica) los programadores no tenian computadoras en sus casas y para poder compilar un código y ver que hacía tenian primero que hacer mucho trabajo en papel y ya hecho viajar a instalaciones apartadas donde le tenian que pagar a alguien para que introdujera su código a una computadora y les diera una hoja con los resultados que su programa entregara. Y en épocas un poco más cercanas, lo bastante cercanas como para encontrar gente que las vivió se daban casos en las universidades en los que los estudiantes tenian que ir a la casa del único del salón que tenía una computadora porque en ese entonces no cualquiera tenía una.

¿Y qué hacian estos programadores cuando no estaban frente a la computadora? Pues muchas cosas. Cosas que por cierto muchos programadores de mi generación consideraban inútiles y se iban directo a teclear el código sin hacer ninguna de ellas. Yo mismos subestimé esas tareas hasta que tuve que hacer programas más serios. Y comentaré varias de esas tareas y como usarlas con nuestro escudo de papel. Y para ello primero les mostraré como usarlo.

La carpeta obviamente es para proteger la libreta, las tarjetas y los instrumentos de escritura. Deben de ser capaces de sentarse a trabajar en cualquier lugar e irse en el menor tiempo posible si es necesario. También debe de ser sencilla de transportar y guardar. La libreta por su parte debe de ser de un tamaño tal que quepa en la carpeta sin salirse y la hoja lo bastante grande para ver mucho código sin necesidad de pasar las páginas. Una pequeña rutina de unas 100 o 200 lineas no debería de abarcar más de 3 hojas por ambos lados. El que sea de cuadrícula permite alinear mejor las instrucciones y los datos aunque el tamaño del cuadro es como a ustedes mejor les acomode. En esta libreta escribiremos con tinta. No importa si la llenamos de tachaduras o dibujos confusos mientras lo que escribamos sea legible. En esta libreta escribiremos muchas cosas además de código. Pero lo más importante es que con el tiempo esta libreta se convertirá en la mejor documentación de los proyectos que hagamos y podremos recurrir a ellas cuando necesitemos adaptar un proyecto antiguo a nuevas condiciones.

Las tarjetas de cartón tienen otras funciones. La primera es servir como pequeños pizarrones portátiles en los que escribiremos con lapiz y borraremos cuantas veces sea necesario. La otra función de estas tarjetas es ayudar como accesos rápidos a cierta información. Por ejemplo si estamos trabajando en un código muy grande y necesitamos pasar las hojas continuamente para consultar por ejemplo nombres de funciones o variables. Podemos poner esa información en las tarjetas y si las acomodamos en una superficie amplia podemos obtener la información que queremos con tan sólo un vistazo sin tener que pasar páginas y páginas. Y en el caso de niformación que necesitemos consultar continuamente durante meses o años directamente podemos «sacrificar» una de estas tarjetas y escribir esa información tan importante con tinta.

Algo que olvidé mencionar respecto a la libreta es que 100 hojas es muy poco para un programa serio. Un programador que dedique dias enteros a un proyecto puede consumir una libreta profesional de 100 hojas en menos de una semana. Por lo que es mejor que tengan algunas en reserva y tengan listo un lugar amplio para almacenarlas cuando se llenen.

Regresando a las tarjetas, aunque estas duran bastante más que las libretas también es buena idea tener algunos paquetes en reserva mantener preparada una caja para guardar aquellas que contengan información valiosa que debe de ser preservada por los años.

Para evitar desperdicios usaremos principalmente las tarjetas y el lapiz. De modo que borremos cada que cometamos un error y ya cuando tengamos algo valioso como una función, estructura o comentario importante lo transcribimos a la libreta. Ya cuando lo hayamos vaciado a la libreta podemos borrar lo escrito en las tarjetas y usarla para otra cosa. Y una vez que tengamos algo valioso escrito en la libreta ahora si encendemos la computadora, tecleamos el código y vemos lo que hace. Igual y mientras lo hacemos podemos usar nuestro escudo de papel para registrar bugs o tomar tota de algún código que queramos revisar con mayor detenimiente.

La clave del Escudo de Papel es que nos permite pensar. Tal vez no podamos escribir en papel tan rápido como podemos teclear pero por lo menos estaremos protegidos de las distracciones de internet y podremos seguir avanzando cuando la PC esté lejos. Para explicarlo, usar papel para actividades de programación donde la PC no sea indispensable es actuar como el soldado que avanza arrastrándose por el lodo y las piedras mientras las balas pasan zumbando por encima de él. No avanza tan rápido como lo haría si se pusiera de pie y corriera pero al menos es más dificil darle. Y desde su posición observa los movimientos del enemigo y cuando sabe que tiene la oportunidad de atacar se pone en pie un momento y dispara unas cuantas ráfagas antes de ponerse a cubierto de nuevo. De hecho al contrario de lo que muestran las películas de ciencia ficción, los programadores no escriben software tecleando sin parar. El teclear código es tal vez menos del diez porciento del tiempo que dedican a programar. Pues el código se escribe una vez, se corrige 10 veces y se lee otras 100 veces o más. Por eso al escribir primero el código en la libreta no perdemos tanto tiempo como podríamos creer. Para acelerar la transcripción del código podemos fotografiar la hoja digitalmente o mejor aún utilizar un scanner. Pero acomodar la libreta junto a la pantalla de la PC también es una opción aceptable y gratuita aunque menos cómoda.

¿Y qué cosas de programación podemos hacer con papel y lapiz?

Ahora veamos algunas cosas que podemos hacer con las tarjetas de cartón, borrador y lapiz.

Escribir pequeños códigos.- Rutinas de unas pocas lineas pueden hacerse en las tarjetas antes de pasarlas a la libreta con tinta. Una técnica para cuando no sabemos que datos utilizar es conservar en la tarjeta un espacio para variables e irlas anotando conforme vemos que las vamos necesitando. En esas tarjetas podemos hacer todas las correcciones a las notas y tachaduras que queramos y ya cuando tengamos algo que parezca funcional los pasamos a la libreta.

Diseñar estructuras de datos.- En las tarjetas podemos diseñar estructuras de datos que incluyen punteros, diversos tipos de datos y datos alineados en memoria. Cuando tengamos algo que funcione lo podemos «inmortalizar» con tinta en una tarjeta para usarla después.

Usarlas como cachés.- Cuando escribimos un código que trabaja con estructuras de datos complejas o tenemos una serie de funciones cuyos argumentos no nos sabemos de memoria casi siempre perdemos mucho tiempo haciendo scroll a los códigos en pantalla o pasando las hojas de la libreta de un lado a otro. Para evitar esto escribimos esa información en las tarjetas y las mantenemos a un lado de la liberta u otra tarjeta mientras escribimos código. Así podemos avanzar más rápido.

Hacer cálculos intermedios y tomar notas.- Tanto si tenemos que hacer un cálculo manual como si nos pasa una idea por la cabeza y no queremos olvidarla podemos escribirla en las tarjetas.

Hacer pseudocódigo.- Un pseudocódigo es un programa escrito en instrucciones del habla cotidiana que cualquier persona sin conocimientos de computación puede entender pero que tiene una correspondencia de casi uno a uno con las instrucciones de un lenguaje de programación. Y en el caso del ensamblador la correspondencia es de dos o tres a uno. Por ejemplo en pseudocódigo la instrucción «poner variable A a 1 si B es diferente de 0 sería un SET o bien un CMP y un MOV. Este pseudocódigo ayuda a darnos una idea de lo que debemos programar.

Hacer diagramas de flujo de datos y control.- Casi todos los programadores mayores de cierta edad recuerdan los diagramas de flujo de control que describen acciones que un programa ejecuta pero no muchos conocen los diagramas de flujo de datos en los que se representa como los datos pasan por las funciones y qué funciones tienen acceso a estos datos. En las tarjetas podemos diseñar estos diagraams y pasarlos en limpio a la libreta cuando estén listos.

Hacer pruebas de escritorio.- Esto es algo que a los programadores de hoy les parece ridículo pero hubo un tiempo en el que para ver si un programa estaba bien diseñado desde el punto de vista lógico había que demostrar sobre el papel que funcionaba. Hoy parece cosa facil teclearlo y mostrar en pantalla los valores de las variables pero en el caso del ensamblador tal cosa no siempre es posible. Un ejemplo sencillo de una prueba de escritorio es por ejemplo la obtención de los factores primos de un número que se obtiene dividiéndolo por números primos menores que él. Por ejemplo el número 30 se descompone en 2 por 3 por 5 y en la prueba de escritorio se hace escribiendo en forma de tabla los contenidos de las variables conforme estas divisiones se lleven a cabo. Si la lógica del programa es correcta lo sabremos antes de escribir la primera linea de código.

Escribir textos extensos sin distracciones.- Ahora mismo esta entrada la escribí por entero en la libreta y ocupó unas 6 hojas por ambas caras. Esto lo hacian los escritores desde tiempos de la máquina de escribir y lo llamaban «borrador». Tal vez suene tonto y yo mismo lo considero así porque por años las notas de este blog las escribí en archivos de texto directo desde la PC. Esta es la primera nota que escribo por completo en papel y corrijo antes de teclearla y si bien el tiempo real de escritura se llevó un par de horas extra esto no es nada comparado con todo el tiempo desperdiciado al vagar por internet o aprovechando los tiempos muertos de aquellas actividades que me alejaban de la computadora.

Ya para terminar quiero dejar claro el verdadero propósito del Escudo de Papel. Pues los principiantes pueden pensar que es una pérdida de tiempo el pasar horas frente a una libreta y quieren ir directo a la computadora. Debo repetirlo por si no queda claro: Es mucho más facil pensar frente a una hoja de papel en blanco que frente a una computadora con internet y redes sociales. El papel brinda quietud y los protege de la tormenta de información chatarra del internet. Por no mencionar que pueden seguir programando en cualquier lugar con espacio y silencio suficientes. Además de que tener un código al que ya le invirtieron horas de trabajo en papel hará que su software esté listo más pronto y con menos errores. ¿Y saben por qué? Porque mientras más horas pasen con su programa en el papel menos dias pasarán tratando de hacer que funcione en la computadora.

Archivos gráficos como entrada y salida de programas

–Arte sintético y algoritmos que dibujan–

Uno de los mayores problemas que he tenido relacionados con la programación gráfica es como separar los algoritmos de las particularidades de las plataformas en que corren. Pues un algoritmo puede tener décadas de haberse inventado pero un hardware dura en funciones cuando mucho cinco años y al paso del tiempo se olvida. Y la clave para que ese algoritmo sea util es saber implementarlo en cada plataforma para aprovechar sus muy particulares e irrepetibles capacidades. Es por eso que muchos de los programadores viejos como yo que les interesan estos temas también saben de ensamblador porque en otros tiempos era necesario conocer bien el hardware para hacer gráficas mínimamente decentes. Y en mi caso particular en el que quiero explicar estos temas la cosa se complica porque sacar información de un programa que maneje gráficos en tiempo real y ponerla en un documento escrito es bastante dificil. Por eso estoy pensando que usar archivos gráficos tiene alguna ventaja en este caso.

Antes de comenzar quiero contarles una historia de cuando comencé a programar. Como algunos ya saben mi primer libro serio de programación fue un libro de algoritmos del que con mucho trabajo podía medio entender las explicaciones escritas pero que los códigos de ejemplo y las ilustraciones me parecian mensajes de los extraterrestres. Obvio pasó mucho tiempo para que el primero de esos algoritmos corriera en un programa escrito por mi. De los dibujos del libro los únicos que medio pude entender fueron los de la sección de algoritmos geométricos y en esa sección recuerdo una parte que decía más o menos así:

«Cuando decimos que un algoritmo dibuja una figura no lo decimos en sentido figurado. ¡Realmente el algoritmo la dibuja! Si estos algoritmos los cargamos en la memoria de una computadora con hardware capaz de dibujar en papel lo que obtendremos será un papel con la misma imagen que aparece en este libro»

A décadas de haber leido eso vino a mi mente la solución para manejar y explicar algoritmos gráficos de manera independiente de la plataforma en un lugar donde lo único con lo que cuento es con texto y algunas imágenes estáticas: Hay que sacar las imágenes producidas por los algoritmos a archivos de imagen digital en lugar de mandarlos a la pantalla. Esto reduciría la complejidad final del programa porque no tendría necesidad de darle capacidades interactivas de entrada y salida ni meterme con el sistema operativo más de lo absolutamente necesario para leer y escribir archivos y el resto sería programación de toda la vida.

Si, ya se que quienes aprendieron a programar después de la invención del DirectX y las primeras GPU creen que un programa de computadora que no los use lo único que puede hacer son matemáticas básicas y escribir lineas de texto.Pero no saben que la capacidad de hacer cuentas y copiar números de un lado a otro es todo lo que un programador necesita para hacer todo tipo de gráficas y animación y sacar por archivos de imagen es la mejor opción para hablar de estos temas en un blog de internet o hasta en un libro impreso. ¿Pero por qué no lo había hecho antes?

Muchos gamers saben que hay juegos que permiten tomar capturas de pantalla pero pocos saben que esto se inventó como una forma de detectar errores en el programa. Y si bien ya había hecho códigos capaces de hacer esto no tenía un «juego» que mostrara información en forma gráfica con tanto detalle y de haberlo hecho la función que lo hiciera iba a ser mucho más complicada que el propio código del juego y eso sin mencionar que hubiera necesitado ‘assets’ bastante grandes para mostrar esa información.

Manejar por archivos de imagen tendría un único problema y es que el código no sería tan rápido como una verdadera imagen en tiempo real. Aunque podría separarlo de tal forma que el mismo código que genere las imágenes sea el que corre en los juegos y mantener fuera de este la parte que construye el archivo de imagen final. Otra ventaja es que no estaría limitado a lo que el código del juego pudiera mostrar en pantalla y podría generar todo tipo de información gráfica a partir de los datos digitales de los archivos. Por ejemplo sería posible mostrar estructuras de datos como grafos o árboles con círculos y flechas o en el caso de estructuras de control de animación que usan punteros para conectar sprites podría mostrar esos sprites unidos por lineas. Y lo mejor de todo es que esos archivos gráficos podría usarlos para explicar cosas en internet. Por ejemplo podría continuar la serie sobre programación gráfica pero esta vez usando esos archivos de salida en lugar de fotografias de papel y escrituras en pizarrones. Que si bien en su tiempo funcionaron para conceptos muy básicos no fueron suficientes para explicar cosas más avanzadas que una proyección en perspectiva de un modelo básico en wireframe. Ahora podría mostrar algoritmos más avanzados como los de iluminación y textura que aunque hubiera podido implementarlos en papel el dibujar esas imágenes a mano implementando el algoritmo me hubiera tomado horas o hasta dias. Con este sistema podría obtener una imagen lista para postear en el blog en menos de un minuto y si usara GIFs animados hasta podría mostrarlos en forma animada en ese mismo minuto. Lo único que necesitaría es implementar el algoritmo en código, escribir datos en un archivo de texto y luego podría crear todas las imágenes que quisiera.

Aquí iba a poner un rant para trollear pero de hacerlo arruinaría mis planes. Lo único que puedo contarles sin fastidiar el proyecto es que este sistema que crea archivos gráfico a partir de instrucciones es parte de un software que llevo programando desde hace unos pocos meses y cuando alcance un cierto nivel pienso hacerle una Prueba de Turing en la que lo haré pasar como un artista del webcomic. Si otros artistas aficionados detectan que los dibujos son hechos por un software autónomo fracasará. Pero si creen que se trata de un humano y hasta lo trollean habrá pasado la prueba. Obvio para hacerla de emoción buscaré hacer la prueba en un lugar donde se suban webcomics de muy pero muy baja calidad y los comentarios sean especialmente agresivos. Pero eso será para cuando el sistema pueda crear por si mismo dibujos decentes. Por ahora lo único que hace y hace bastante mal es desplegar datos en forma gráfica y mostrar algunos sprites del modo como los manejarían mis intentos de código juego. Pero eso es mucho más que suficiente para continuar mis aventuras y sobre todo tener imágenes para explicar conceptos o para decorar el blog en lugar de tener que pasar horas en el paint ni robármelas de internet.

La Programación se hace en la mente

–El programador es la serpiente y el código el conejo–

Por razones que no voy a explicar terminé aislado por dos semanas en un lugar en el que no tengo acceso a internet ni posibilidad de salir muy lejos. Todas mis actividades en linea incluyendo teléfono convencional se perdieron y tuve un trato nulo con otros seres humanos. Afortunadamente todavía pude conservar la computadora funcionando a un mínimo suficiente para programar y escribir esta entrada que inicié al tercer dia de ese período de privación sensorial y que voy a subir a internet en cuanto pueda escapar de este lugar. Pero como suele pasar en los comics aquellas cosas que matarian o enloquecerian a una persona real a mi me dieron superpoderes. Pues redescubrí una habilidad que a estas alturas de la vida me va a ayudar mucho para poder programar: Un concepto al que he bautizado como «La Serpiente y el Conejo»

Para los normies que leen esto para pasar una materia y que nunca han programado nada por propia iniciativa deben saber que el comportamiento de los programadores al escribir código es muy diferente al que tienen el resto del dia. Un programador que lejos de las computadoras es alegre y conversador cuando se sienta a programar se aisla por completo y se vuelve poco amigable con la gente que lo rodea y puede incluso volverse agresivo cuando lo interrumpen de manera muy brusca. Por eso los mejores programadores trabajan solos y prefieren el trabajo en casa o en oficinas cerradas a las grandes superficies de trabajo divididas en cubículos. ¿Por qué pasa esto? Pues porque programar requiere una cantidad de concentración y dedicación que no es posible sostener cuando hay que estar alerta de lo que ocurre en el ambiente. Y este aislamiento se extiende a internet. Ningún programador serio se conecta a internet mientras programa y si lo hace es para consultar algún tipo de documentación que no puede descargar a su computadora, pero no va a tener ningúna red social, mensajero instantaneo o cualquier cosa que pueda distraerlo de su labor porque recuperar la concentración puede tomar desde varios minutos a pocas horas. Pues bien, ahora con mi pequeño e involuntario aislamiento tuve oportunidad de comprobar la efectividad de esos niveles de concentración.

A la hora de programar, la mente de un programador se comporta como una serpiente a la hora de comer. Pues a diferencia de otros animales las serpientes no cortan la comida a mordidas ni mastican los bocados sino que una vez que han dejado fuera de combate a su presa la engullen por completo sin masticarla y luego permanecen quietas dando el aspecto de un calcetín al que se le ha introducido una pelota. Y es el sistema digestivo de la serpiente el que se encarga de digerir a la presa hasta que el reptil recupera su esbelta forma de siempre y va en busca de más comida. La mente de un programador procesa el código de la misma manera que una serpiente digiere su comida.

La mayor parte del trabajo del programador ocurre dentro de su mente. La computadora lo único que hace es darle un programador un medio para escribir código y compilarlo pero hace poco o nada para ayudarle al programador a hacer que el código haga lo que él quiere. Puede mostrar documentación pero no sabe cual de las cientas de llamadas al sistema harán que el programa funcione. Pueden mostrar lo que ocurre durante la ejecución del programa con debuggers pero no saben que lo que muestran es lo que está causando el problema. Puede ejecutar un programa sin saber que lo que hace no es lo que el programador quiere que haga. En fin, la computadora sabe de programación lo mismo que una herramienta cualquiera sabe de como hacer un trabajo.

¿Pero qué pasa dentro de la mente de un programador cuando escribe código? ¿Qué es lo que un director de cine mostraría en pantalla para explicar al público lo que los programadores piensan? Lo primero y principal que pasa por la mente de un programador (al menos por la mia) es código. Código tanto en la forma en que aparece en el editor de programa como su efecto en el sistema al ser ejecutado. Datos en forma binaria que representan imágenes de cosas que sus ojos nunca han visto pero que sabe como funcionan porque tiene una imagen mental de estos. Por ejemplo tal vez nunca ha visto con sus propios ojos como se almacena un valor en un registro de CPU o localidad de memoria pero puede imaginarse estos como cajas o estanterias de una bodega en las que los números se acomodan para formar arrays, estructuras. Puede imaginarse las clases OOP como moldes para cortar galletas y los objetos instanciados a partir de esas clases como galletas recién sacadas de esos moldes. Las funciones como máquinas individuales de una fábrica entre las cuales las variables pasan de una a otra como piezas movidas entre unas y otras como bandas transportadoras mientras que las estructuras de datos como loncheras cerradas con diferentes alimentos y bebidas separadas por compartimentos en su interior. Las máscaras de bits usadas para tomar decisiones rápidas y filtrar datos puede imaginarlas como coladores que dejan pasar los líquidos mientras retienen los sólidos y las banderas de decisión como auténticas banderas que suben y bajan para indicar si tal o cual condición se cumple o no. Y todo ese mundo de abstracciones tan locas y fantásticas requieren que el programador ponga todos sus recursos mentales para mantenerlo en su cabeza y moverse a través de él para buscar errores. Y para eso necesita desconectarse de la realidad tanto como pueda.

Tal vez por esto es que muchos no pueden programar. Porque las condiciones en las que un programdor debe de estar para poder programar casi nunca están presentes y cuando lo están poca gente las soporta. Simplemente estar solo y en silencio en un lugar cerrado en el que no hay otra cosa aparte de una computadora y algo de moviliario de oficina para programar pero nada parecido al internet, radio, TV, teléfonos o cualquier otro tipo de comunicación con el exterior es algo que enloquecería a casi cualquiera. ¿Pero por que pasa esto? Pues porque el cerebro humano está diseñado para recibir un mínimo de información del entorno que lo rodea y si esta no se recibe comienza a alucinar. Esto es tan cierto como la existencia de los tanques de privación sensorial que fueron creados para que la gente pudiera descansar y concentrarse pero al ver que pasados unos minutos los usuarios tenian alucinaciones horrorosas fueron retirados de la circulación y se dice que algunos hasta fueron usados como instrumentos de tortura.

En mi experiencia puedo decir que la condición de la privación sensorial necesaria para programar es tan dificil de conseguir y a la vez tan insoportable por dos razones: Los pensamientos parásitos y la información chatarra. Pero antes de explicar lo que son les contaré una de mis historias.

«En la mente consciente siempre código…»

Hace mucho visité una tienda de deportes y mientras estaba ahí vi una propaganda del gobierno que prevenía a la juventud de las conductas criminales que decía: «En las manos libres siempre libros. Nunca drogas, nunca armas.» Ahora muchos años después caigo en cuenta que lo que las drogas y las armas son para las manos de los jóvenes desocupados la información chatarra y los pensamientos parásitos son males para la mente de un programador.

La información chatarra

En esta época del internet una persona está expuesta a una lluvia constante de información y toda esa información debe de ser procesada por el cerebro para tomar y conservar lo que considere util. El problema es que la inmensa mayoría de esa información no nos sirve para nada y la olvidamos pocas horas después de haberla recibido. Para un programador cuya mente trabaja como el sistema digestivo de una serpiente todos estos datos inútiles funcionan como una interminable lluvia de conejos que no alcanza a paralizar y digerir por completo y que por supuesto no le permite concentrarse para programar. En el ambiente hay demasiadas cosas que pueden romper la concentración de un programador este debe de deshacerse de todas ellas para poder trabajar. Por eso muchos escriben código por las noches cuando nada ni nadie los interrumpe. Aunque algunos programadores consiguen aislarse del ambiente mejor que otros. Recuerdo por ejemplo a uno que me dijo que mientras programaba ponía un disco de música y cuando volvía a prestar atención notaba que ya habian pasado varias canciones que no había sido consciente de haber oido.

¿Pero qué pasa cuando por fin conseguimos aislarnos de las mundanales distracciones y nos quedamos solos en una oficina silenciosa y sin ventanas con una computadora sin acceso a internet? Cuando no oimos otra cosa que nuestros propios pensamientos, no vemos otra cosa que lo que podemos imaginar al cerrar los ojos y no hay nada que podamos tocar, oler o degustar nos atacan unos monstruos que persiguen a todo aquel que busca el silencio: Los pensamientos parásitos.

Los Pensamientos Parásitos

Un pensamiento parásito es un pensamiento que nos hace sentir mal. Y lo peor es que es recurrente y puede repetirse una y otra vez durante todo el dia a lo largo de años. Estos pensamientos son diferentes para cada persona y conforme envejecemos y vamos teniendo malas experiencias esos pensamientos parásitos se multiplican. Y a diferencia de las preocupaciones cotidianas que nos recuerdan que tenemos problemas que podemos solucionar los pensamientos parásitos no tienen otra función que fastidiarnos porque no nay nada que podamos hacer o se trata de cosas que ya no tienen remedio. No pondré ejemplos porque cada quién tiene los suyos. Si quieren conocer cuales son sus pensamientos parásitos intenten quedarse algunas horas en silencio, en la oscuridad y sin hacer nada y verán como sus monstruos particulares se harán presentes sin que los llamen. En cuanto aparezcan y dependiendo de su forma de vida puede que sientan deseos de emborracharse, comerse un litro de helado o como mínimo encender la televisión o cualquier otro dispositivo que haga ruido y que los distraiga de sus pensamientos. Intentar comunicarse con otro ser humano también es una opción aunque con la excepción de los hábitos más destructivos lo que la gente hace para huir de los pensamientos parásitos es buscar desesperadamente información chatarra para mantener ocupada la mente. Y eso pasa porque la mente nunca se detiene.

¿Y qué debe de hacer un programador? Un programador debe de recordar que su mente es una serpiente que digiere código sin masticarlo. Durante ese silencio en el que los pensamientos parásitos atacan debe de aislarse del mundo y mantener todos los sentidos dentro de su propia mente para ver, escuchar, oler, degustar y tocar aquella realidad que su cerebro construye para representar conceptos inmateriales de programación. Mantener la mente en el código y las abstracciones y cada vez que los pensamientos parásitos y el deseo de información chatarra aparezcan tomar otra pieza de código y digerirla. Cuando se alcanza un cierto dominio de esta técnica el programador se vuelve capaz de mantener la programación dentro de su mente incluso cuando se aleja de la computadora. No importa si se encuentra en un lugar donde no quiere estar o haciendo cualquier tarea que no quiera hacer. Mientras pueda aislarse del entorno sin correr peligro inmediato puede seguir programando dentro de su cabeza durante horas y teclear lo que descubrió en esos viajes mentales en minutos cuando regrese a casa y encienda su PC. En lugar de estar dia y noche vagando por internet recibiendo información que en su mayor parte no recordará cuando despierte a la mañana siguiente.

En estos dias de aislamiento he redescubierto ese estado de autodominio mental del que me fui alejando conforme la vida me fue llenando de pensamientos parásitos que con el tiempo me hicieron temer al silencio. Y luego con la llegada del internet un imparable flujo de información chatarra saturó mi mente y disminuyó notablemente mi capacidad para concentrarme en la programación. Por eso mi consejo es recordar aquel cartel que vi en la tienda de deportes y adoptarlo como mantra cuando quiera poner la mente en modo de programador:

«En la mente consciente siempre código. Nunca información chatarra. Nunca pensamientos parásitos.»

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.

Todos los Videojuegos son Wargames parte 2

–Como Programar la Habilidad y la Suerte–

Esta es la segunda entrada de la serie que habla sobre como los wargames de mesa pudieron ser los antecesores de los actuales videojuegos y como mucha de la lógica que los hacía funcionar sigue aplicándose hasta hoy. Pero antes les contaré una leyenda sobre ambos mundos tan separados por el tiempo.

Existe desde los setentas una compañia fabricante de miniaturas usadas para juegos de mesa llamada Games Workshop. Sus colecciones más famosas entre los aficionados a los wargames son Warhammer Fantasy y Warhammer 40000 (WH40k). La primera es sobre un mundo medieval fantástico de magia y espadas y la segunda de batallas futuristas entre humanos y monstruos galácticos. A principios de los noventa un dia a sus oficinas llegaron un grupo de nerds desconocidos que se juntaban para hacer videojuegos y le propusieron a Games Workshop hacer un videojuego basado en el universo de Warhammer. Y como siempre sucede en este tipo de historias los ejecutivos de Games Workshop se carcajearon en sus caras y los rechazaron. A la salida se dice que uno de esos nerds gritó algo sobre wargames, juegos de azar y mujerzuelas. Luego el grupo de nerds siguió trabajando en su proyecto pero cambiando todas las marcas registradas de Games Workshop y un buen dia sacaron a la venta su videojuego basado extraoficialmente en Warhammer Fantasy. Y ese juego por si no lo han adivinado aún es el mundialmente famoso Warcraft.

Sobre la relación de Starcraft y Warhammer 40,000 no he encontrado nada escrito en internet pero los ejércitos de Space Marines, los Tyranids y los Eldar se parecen mucho a los Terran, Zerg y Protoss de Starcraft y ambos están ambientados en un universo futurista «donde solo hay guerra». Además de que las programación de los Terran de Starcraft es sorprendentemente parecida a las reglas de juego de WH40k.

Esto lo cuento porque quiero hacerles ver que en un wargame elaborado puede haber tantas reglas que a algunos principiantes puede resultarles muy complicado jugar. Sin embargo, cuando jugamos en computadora un videojuego donde se apliquen estas mismas reglas la computadora las puede evaluar tan rápido que ni siquiera nos enteramos de que tales reglas existen. Verán, una de las cosas que tardé mucho en aprender a programar era la defensa de un personaje controlado por la computadora. Pues si lo programaba para que se cubriera cada que el jugador lo atacara sería invencible y si le pusiera una rutina que siempre fuera igual como se hacía en los juegos antiguos el jugador se aburriría una vez que la descubriera. Otro problema parecido es el de ajustar diferentes niveles de dificultad en un juego sin cambiar el código que lo hace funcionar. Primero pensé en guardar las rutinas de movimiento de los personajes no jugables en forma de script y cargar un script diferente según fuera el nivel pero eso no solo es complicado sino a la larga predecible. Además de que no hallaba como programar ciertas conductas ‘humanas’ como la ira y el miedo que hiciera que cambiara el patrón de ataque o tener una manera de que un personaje no jugable pero del lado del jugador pudiera evolucionar junto con él. Y todas esas cosas las pude entender hasta que investigué como funcionaban los antiguos Wargames.

Veamos una situación típica de un videojuego actual. Digamos que tenemos un RPG de acción y el héroe controlado por el jugador está luchando contra un monstruo jefe. El jugador presiona una combinación de botones y el héroe da un paso rápido hacia al monstro y lo ataca con un revés de espada que hace retroceder al monstruo unos pasos. Esta escena que para el jugador apenas duró un segundo para la computadora significó hacer una larga y aburrida serie de comparaciones, validaciones y restas que voy a tratar de explicar sin tratar de aburrirlos. Pero para empezar ¿Por qué en ese momento el monstruo no esquivó el golpe?¿Si recibió el golpe por qué no se protegió? ¿Exactamente cuanto daño recibió el monstruo con ese golpe? ¿Qué va a hacer el monstruo luego de recibir ese golpe? o al to tan sencillo como ¿Por qué no atacó al héroe cuando lo vio venir con su ataque desde lejos?

Detrás de cada golpe hay muchos cálculos tediosos que a la computadora no le aburre hacer

En un juego actual cada que el héroe golpea al monstruo ocurre cualquiera de esas cosas. Pero a nosotros nos da la impresión de que esas acciones son impredecibles pues no somos capaces de detectar ningún patrón en las acciones del monstruo. Pero primero comentemos algo sobre como se evalua el resultado de una acción en los wargames. En la vida real el desenlace de una acción es una mezcla de habilidad y suerte y eso en los wargames se simula con tablas de habilidad y dados. Digamos que alguien tiene una habilidad que se mide entre 1 y 5 siendo 1 un inutil y 5 un experto. Si lanzamos un dado de seis caras obtendremos un número entre 1 y 6. Si la suma del punto de habilidad y el dado es mayor que cierto valor, por ejemplo 7 se considera que la acción tuvo éxito y si no se alcanza ese valor la acción terminó mal. En esta forma de evaluar si el dado nos da un uno significa que hemos tenido muy mala suerte y fallamos sin importar que tan buenos seamos en la actividad mientras que alguien muy inepto con habilidad de 1 puede lograr su objetivo si tiene muy pero muy buena suerte y el dado le da un 6. Las distancias como ya vimos en la entrada anterior también cuentan para ver si se puede ejecutar o no una acción y los efectos de la acción dependen de otras tablas de números que el jugador no ve. Pero sigamos con el espadazo de un segundo del ejemplo.

Al momento de que el jugador presiona la combinación de botones para atacar la computadora evalúa si el monstruo está dentro del rango de ataque del héroe. Como si lo está luego ejecuta el siguiente paso que es ver si el golpe da en el blanco o no. La computadora lanza su dado interno y le da digamos un 4. Luego consulta la tabla que describe las habilidades del héroe y ve que su habilidad de combate con la espada es de 3, por tanto 4 + 3 = 7 que es lo mínimo para aceptar que el ataque dio en el blanco. Ya sabiendo que dio en el blanco la computadora vuelve a revisar la tabla de habilidades del héroe y ve que su fuerza física es de 2 y que la espada que lleva tiene un daño base de 3 con lo que se calcula que el golpe tiene una fuerza de 5. Pero antes de que el monstro salga herido tiene una última oportunidad de defenderse y la computadora revisa la tabla de habilidades del monstruo y ve que la defensa del monstruo es un 4 y al lanzar el dado este da un 2. Por lo tanto aunque la defensa del monstro es considerable ha tenido poca suerte y no ha alcanzado a interponer sus brazos cubiertos de hueso afilado para protegerse. Finalmente para calcular el daño del golpe la máquina revisa la tabla del monstro y ve que su resistencia física es de 2 y lleva puesta una coraza que le da una defensa de 1. De este modo calculamos el daño final que es de 5 que es el ataque del héroe menos 3 que es la resistencia total del monstruo con todo su equipo lo que nos da un 2. Ese 2 lo restamos a los puntos de vida del monstruo que digamos que comenzaba en 50 y bajó a 48. Como la vida del monstruo no se ha reducido a cero tan solo se quejará un poco del golpe y la lucha seguirá hasta que uno de los dos caiga.

Si todos estos cálculos les parecieron pesados y confusos imagínense lo que es manejar otros aspectos como diferentes razas de monstruos, ataques basados en diferentes elementos o tipos de magias o rivalidades que existan entre especies. Otra cosa que puede desencantar a algunos es la poca importancia que parece tener la habilidad de los jugadores cuando el si ganan o pierden no depende de que tan rápidos son con los controles. Si bien muchos de esos valores numéricos contenidos en las tablas son importantes para los personajes controlados por la computadora muchos de ellos pueden ser ignorados cuando se aplican al jugador. Por ejemplo si hay un valor que sea agresividad que haga que los monstruos ataquen sin pensar o piensen sus estrategias de manera calmada ese valor no tiene por qué usarse para el personaje controlado por el jugador. Pues el decidirá cuando quiere atacar de manera agresiva y cuando tomar distancia de los monstruos para repensar su estrategia.

Y aquí es donde entran las computadoras. Para un jugador humano que juega wargames con dados y miniaturas calcular estos datos puede ser muy pero muy tardado y hay reglas que aunque no son realistas ayudan a agilizar la partida. Por ejemplo en algunos wargames cuando dos grupos de soldados rivales se enfrentan los cálculos se hacen como si fuera una batalla de uno contra uno combinando las tablas de datos de todas las unidades y luego se reparte el daño según reglas de distancia. Pero para una computadora no hay problema en registrar que el soldado 325 recibió un tiro por parte del 231 cuando este disparaba al aire tratando de huir de los perseguidores que lo tenian rodeado y que el que recibió el tiro tuvo tan mala suerte que no lo resistió. De una manera similar es como se obtienen los famosos Critical Hits.

En la siguiente entrada veremos como todos los videojuegos tienen elementos de wargame incluso aquellos que uno creería que nada tienen que ver con la guerra.

Todos los Videojuegos son Wargames parte 1

–¿Quiénes son los verdaderos ancestros de los videojuegos?–

Cuenta la leyenda que el escritor de ciencia ficción H.G. Wells conocido mundialmente por La Guerra de los Mundos, obra en que la que la tierra es invadida por extraterrestres tenía un curioso pasatiempo: Jugó con soldados de juguete toda su vida. Uno podría pensar que le gustaba coleccionarlos hasta que lo visitaba sin avisar y se lo encontraba tendido en el piso jugando con sus miniaturas y maquetas de pueblos completos. Era tanta su afición que incluso llegó a escribir un manual muy completo sobre como jugar. Dicho manual escrito hace alrededor de un siglo fue conocido como Little Wars y contiene las reglas para organizar encuentros entre varios jugadores para organizar batallas competitivas y decidir quién es el ganador. Pero de ese manual les hablar\e más adelante en esta misma entrada.

Al mismo tiempo, o tal vez un poco antes. En la europa previa a la Primera Guerra Mundial soldados auténticos jugaban un juego con fichas, figuras a escala y mapas de territorios reales divididos en varios cuadrados y zonas delimitadas por lineas. No recuerdo el nombre exacto de este juego pero se dice que empezó como una manera de preparar a los oficiales y enseñarles estrategias sobre como mover sus fuerzas de manera eficiente y planificar mejor sus misiones. De hecho si somos estrictos y nos vamos todavía más atrás encontraríamos que casi todos los juegos de mesa jugados con fichas representan una batalla de una forma u otra. Pero me abstendré de hablar de esos juegos por hoy.

El asunto es que esos juegos de guerra que se jugaban con modelos a escala en tableros que representaban campos de batalla y al que se le aplicaba un conjunto de reglas tiene mucho que ver con lo que son hoy los videojuegos. ¿Pero qué tienen que ver unas figuritas tiesas de hace cien años con los modernos videojuegos 3D para PC Master Race y consolas de última generación que se vuelven obsoletas al año de haber salido? Mucho en realidad. Pero para eso pasemos a lo que yo llamo la pregunta fundamental de la programación de videojuegos.

De todas las cosas que me han preguntado sobre programación la que tal vez sea la mejor me la hizo un estudiante de ingeniería en computación y era: ¿Como es posible que el lenguaje ensamblador que lo único que hace son matemáticas básicas y copiar números de un lado a otro pueda usarse para hacer videojuegos?

La respuesta obvia sería que todo lo que corre en una computadora es código que procesa ceros y unos pero como eso no le dice nada a quien no sabe de programación y muy probablemente los primeros jugadores de juegos de guerra no sabian mucho del tema. La respuesta que yo les daría a esos jugadores si estuviera sentado en su mesa de juego sería: La computadora puede correr las reglas del juego mucho más rápido de lo que ustedes pueden mover las figuras por el tablero.

Debería comentar que existe la teoría de que el término «Gamer» que hoy los aficionados a los videojuegos usan para describirse a si mismos deriva del término «Wargamer» que era como se le conocía a los que jugaban juegos de guerra con figuras a escala y reglas definidas. Por lo que no es descabellado pensar que los videojuegos actuales descienden de esos antiguos juegos de guerra jugados con miniaturas.

Pero veamos un poco como se juega uno de estos juegos. Si bien leí el manual de juego Little Wars este es demasiado extenso para describirlo en detalle así que intentaré describir lo básico. En la versión original las figuras eran de soldados a pie, caballería y cañones. El campo de juego era un espacio grande y plano que podía ser el suelo de una recámara o un pedazo de jardín. Para darle ambiente en ese espacio había figuras a escala de casas, fortalezas o cualquier otra edificación dependiendo de donde se suponía que se libraba la batalla. Antes de comenzar ambos jugadores posicionaban a su ejército de su lado del campo y se preparaban para la señal de inicio del combate.

A partir del inicio de la batalla cada jugador tenía un espacio de dos minutos cronometro en mano para mover sus unidades por el terreno. Para mover las unidades había dos varas, una larga y una corta. Los soldados a pie podian moverse de su posición tan lejos como la vara corta o menos. La caballería usaba la vara larga que era dos veces el largo de la corta para lo mismo. Los cañones no se podian mover por si solos ni dispararse a menos que cuatro soldados a pie estuvieran en la misma posición para poder operarlo. Cuando dos o más soldados de un mismo jugador estaban lo bastante cerca se consideraba que eran una unidad y la cantidad de personal que tuviera esa unidad se usaba para determinar quién ganaba en los enfrentamientos. Pues cuando dos soldados enemigos se encontraban uno frente a otro y no había nada con qué protegerse ambos morian. Lo mismo ocurría con unidades grandes si ambas tenian la misma cantidad de hombres. Si una unidad grande se enfrentaba con otra más pequeña la pequeña era aniquilada y los sobrevivientes de la unidad ganadora se calculaban restando los números de la unidad caida. Por ejemplo si una unidad de 5 se enfrentaba a una de 3 ganaba la de 5 pero únicamente dos eran los que sobrevivian.

Como esto no le daba suficiente emoción al juego también era posible que los soldados pudieran tomar posiciones seguras para defenderse ya sea dentro de una casa, una torre o detrás de algún obstáculo. De este modo si eran atacados por una unidad inferior en número podian defenderse sin sufrir bajas. Sin embargo si eran rodeados por una unidad mucho mayor en número (por lo menos dos por cada uno de ellos) tenian la opción de salir y ser aniquilados o ser tomados como prisioneros. Cuando un soldado era hecho prisionero se le quitaba el arma y tenía que ser escoltado por dos soldados del ejército que lo capturó hasta el lado de la mesa del jugador con las mismas reglas de movimiento de cualquier otra unidad. Si en el camino uno de los dos escoltas moría el prisionero podía escapar pero como estaba desarmado cualquier enemigo que lo alcanzara lo podía matar instantaneamente y sin riesgo, pero si lograba regresar con vida a la base que era el lado de la mesa de su jugador recibía otra arma y podía regresar a la lucha.

Pero en la batalla también había cañones. Un cañon por si solo no hacía nada pero si cuatro soldados de un mismo ejército llegaban a su posición podian apuntarlo, dispararlo o moverlo aunque con algunas excepciones como no poder cruzar con el cañon terrenos difíciles como los rios. El libro no explicaba la mecánica de disparo del cañon pero algunos dicen que el cañon disparaba pequeñas pelotas con un resorte y si esa pelota golpeaba a un soldado lo eliminaba además de que podía ser usado para destruir estructuras que pudieran ser usadas como refugio para los tiradores. También era posible capturar un cañon del enemigo si un jugador lograba que cuatro de sus hombres lo alcanzaran.

Ganaba el jugador que pudiera vencer o capturar a todas las unidades de los otros jugadores pero existian otras modalidades de juego como capturar una bandera de otro jugador y llevarla al terreno propio, apoderarse de un poblado o instalación o escoltar a un personaje importante por terreno hostil. Si les interesa este juego pueden encontrar el manual de Little Wars en internet pues por su antiguedad ya está libre de derechos de autor.

La computadora no ve el juego como los jugadores lo ven

¿Y qué tiene esto que ver con programar? Primero que nada elegí Little Wars porque es un wargame lo bastante sencillo para explicarlo en términos de programación. Imaginemos que estamos jugando una partida con soldados de juguete y maquetas físicas y que tenemos a un lado a una computadora para apoyarnos en el juego. La computadora ya está programada con las medidas del campo, los lugares donde están los obstáculos y la posición de cada uno de los soldados de plástico. Y aquí es donde comienza la programación. Pues las medidas del campo son tres números que indican ancho, alto y profundidad. Digamos que estos valores están en cualquier unidad física como pulgadas o centímetros según su gusto. Para ubicar a cada soldado en el campo de batalla la computadora utiliza coordenadas espaciales (x,y,z). Estos valores indican cuantos pasos hay que dar del punto origen del campo hasta la posición donde se encuentra. El origen del campo puede estar en el centro para hacerlo facil de programar o en una esquina para hacerlo más entendible a los programadores principiantes. La posición de los obstáculos, refugios o terrenos difíciles se almacena en la computadora de la misma manera.

¿Y como sabe la computadora el movimiento de las figuras? En realidad no lo sabe. Alguien que no esté jugando tiene que estar escribiendo en un teclado esos cambios. Para esto podrian dibujar una cuadrícula en la mesa de juego para obtener las coordenadas x,y,z de un vistazo en lugar de usar instrumentos de geometría como reglas y escuadras. Y en cuanto a la medición de distancias la computadora es perfectamente capaz de hacerlo. Basta recordar al buen pitágoras y su teorema usado para medir distancias. No lo voy a explicar porque quiero pensar que si saben programar ya lo conocen o pueden buscarlo y entenderlo sin problemas. La computadora tiene una rutina que dados dos puntos en coordenadas x,y,z nos dice la distancia que hay entre ellos y así puede saber qué movimientos son válidos. Para esto los datos de cada figura deben de contar también con su valor de movimiento.

Con los datos que tenemos hasta ahora la computadora puede contar los dos minutos del turno para cada jugador y en ese turno comparar a qué distancia se encuentran las unidades unas de otras o si están en alguna estructura que las proteja sin necesidad de que se lo tengamos qué decir. La propia máquina detectará si un grupo de soldados están lo bastante cerca entre si para formar una unidad de combate, si un cañon es operable por un jugador al tener cuatro hombres a menos de cierta distancia. Si dos grupos están lo bastante cerca para enfrentarse, quién ganó y quienes sobrevivieron, cosa que es una simple resta. Para decidir si un soldado está en un lugar desde donde puede protegerse basta con tomar sus coordenadas x,y,z y ver si está a menos de una pulgada de distancia de uno de esos refugios. Suponiendo que las figuras tengan una pulgada de superficie. A los datos de cada soldado además de sus coordenadas y valor de movimiento agregamos una bandera que indique si está a cubierto o desprotegido. Cero será desprotegido y Uno a cubierto. Con esta mejora ya somos capaces de definir lo que pasa cuando los ejércitos se encuentran. Si un grupo con la bandera de cubierto está a uno son rodeados por otro grupo que sea el doble de ellos en número por lo menos y esto es una multiplicación por dos (o un shift binario) y una resta. Hacemos una rutina que se active cuando los atacantes estén a menos de una pulgada de un refugio. Multiplicamos por dos el número de defensores y lo restamos al número de atacantes. Si el resultado es cero o un valor negativo significa que los defensores pudieron defenderse y si el valor es positivo todos son capturados o se le da a los defensores la opción de salir a pelear y ser vencidos.

La mecánica de los prisioneros se programa con otras dos banderas. Para los principiantes les recuerdo que una bandera es una variable que puede valer cero o uno (falso o verdadero) y que puede reducirse a un simple bit. Una de estas banderas es la de Capturado. Si vale uno el soldado está capturado y no puede moverse por si mismo y la otra es Indefenso. Si indifenso es verdadero el soldado no puede defenderse si lo alcanza el enemigo y si dos enemigos armados lo alcanzan tienen la opción de capturarlo o matarlo. La condición en la que un soldado es capturado o queda libre también la puede detectar la computadora al comparar las distancias entre el soldado indefenso y los enemigos. Si encuentra al menos dos a una pulgada o menos de distancia. Del mismo modo si detecta uno o ningún enemigo a menos de una pulgada del soldado indefenso la bandera Capturado se pone a cero y recobra el movimiento aunque no pueda pelear y pueda emprender la huida.

La mecánica del cañon es más complicada. Pues si es un cañon que dispara pelotas de verdad no quedará otra que informarle a la computadora que unidades fueron alcanzadas por el cañonazo y si alguna estructura fue destruida. Y aunque la mecánica del cañon que lanza pelotas de verdad hace la batalla menos predecible también se puede programar una mecánica igual de impredecible pero eso lo veremos en la siguiente entrada. Los datos del cañon son por supuesto sus coordenadas x,y,z que nos dicen donde está, una bandera que indica si hay personal para dispararlo y una variable que indique cual de los jugadores lo tiene bajo su control.

En resumen, la computadora cuenta los dos minutos de cada turno y durante cada uno de esos turnos compara distancias y detecta todas las condiciones ya mencionadas y también verifica si la condición de victoria o derrota acordada se cumplió y todo lo hace leyendo variables, comparando números y haciendo sumas, comparaciones y alguna raiz cuadrada con aquello de lo de pitágoras. Pero cabe aclarar que hasta ahora hemos estado jugando con soldados de juguete físicos y lo único que la pantalla de la computadora nos muestra son mensajes de texto sobre lo que sucede en la batalla tales como «Jugador A captura un cañon» o «Los defensores B ocultos en la granja han sido capturados por el ejército de A» o cualquier otra cosa que las reglas nos digan que va a pasar según los datos de lo ocurrido en el juego. Hasta ahora lo que hemos programado poco tiene que ver con un videojuego de estrategia actual pero ya tiene la lógica y para la computadora ya es jugable. ¿Y qué le faltaría? Pues por supuesto una manera de representar en pantalla la acción y una manera de recibir datos por parte del usuario de una manera más natural como sería por las órdenes que este les diera a los soldados con el mouse y el teclado pero el como hacer eso no es el tema de esta serie.

En la siguiente entrada veremos como programar mecánicas que hagan la batalla más emocionante tales como los hit points, diferentes tipos de armas y ataques, disparos que no siempre den en el blanco, personajes con diferentes fortalezas y debilidades, explosiones y tal vez hasta magia. Al final y sin hacer mucho spoiler veremos que todo lo aprendido en los viejos wargames no solo sirve para programar juegos de estrategia por turnos sino todo tipo de videojuegos tanto por turnos como en tiempo real.

El Fantasma de la Tribu y el Tercer Ratón

–¿Quién es el dueño de tu tiempo de vida?–

A pesar de que se cree civilizado, el ser humano es un animal de manada. Cada grupo humano funciona como una manada de mamíferos agresivos donde unos pocos machos acaparan a todas las hembras y los recursos y el resto de los machos tienen que pelear contra los jefes para quitarles su posición o aceptar ser hostilizados continuamente por estos en un intento de intimidarlos lo suficiente para que no intenten nada en su contra. Originalmente la civilización intentó disminuir las peleas creando un orden social sospechosamente parecido al de las aves en las que las parejas permanecian juntas para formar nidos en los cuales criar a sus descendientes. Orden que para ser mantenido demandaba sacrificios tales como que los machos dominantes tuvieran que conformarse con una sola hembra y el resto de las hembras se vieran atadas de por vida a machos débiles a los cuales despreciaban pero que les brindaban techo y comida. Este orden demostró ser superior al de las comunidades incivilizadas y primitivas y se mantuvo por algunos miles de años hasta que el desarrollo tecnológico trajo un nivel de bienestar que hizo que la organización familiar que recordaba a los nidos de aves se viera como algo anticuado y ridículo y la humanidad volvió a vivir como en las antiguas manadas de primates. No entraré en muchos detalles del efecto de esto porque eso ya es política y aquí de lo que hablo es de programación.

¿Y qué tiene que ver la programación con una manada de cavernícolas incivilizados? O más específicamente ¿Qué tiene que ver esto conmigo y con el hecho de que no he subido nada de valor a está página en los últimos dos años? Pues que todo lo que hace a esta página lo que es que es el ASM dentro de la manada en la que estoy no significa nada. Ya se que ustedes me imaginaban como una especie de ente poderoso y dominador que atemorizaba a los nativos incultos con su dominio sobre las computadoras pero en realidad soy poco más que un viajero que va de un lado a otro buscando aventuras y aprendiendo lo que puede sobre programación. O lo había sido hasta ahora. Pues por problemas de recursos no he podido vivir como antes y no me queda de otra que unirme a una tribu en la que por supuesto no me van a dejar ser el jefe ni tampoco disputarle el poder al macho dominante en turno. ¿Debería dejarme hostilizar y atemorizar alegremente mientras trabajo para darle recursos a gente que me desprecia a cambio de migajas de lo que yo mismo produzco del modo como lo hace el Tercer Ratón? ¿Habrá alguna otra alternativa?

Para los que no conocen la historia, el Tercer Ratón se trata de un fenómeno que ocurre cuando tenemos tres ratones encerrados en una caja en la que de un lado hay una palanca y del lado opuesto una puerta de la que sale un trozo de queso cada que se jala la palanca. Cuando hay un solo ratón este jala la palanca cada que tiene hambre y come. Cuando hay dos ratones a veces pelean y otras se turnan para ver quién come y quién jala la palanca. Pero cuando hay tres ratones en la caja ocurre algo feo: Y es que dos ratones se ponen de acuerdo para obligar al tercer ratón a jalar siempre la palanca y le permiten comer únicamente cuando los dos ratones que acaparan para si la puerta del queso ya han comido hasta hartarse. Al final ese tercer ratón es el que más trabaja y menos come. ¿Pero qué pasaría si ese tercer ratón no necesitara comer?

El tercer ratón acepta su destino no solo por la ferza de los que acaparan el queso sino por su propia hambre. Y en las manadas de humanos modernos ocurre lo mismo. Ese tercer ratón que trabaja mucho y come poco no siempre es un trabajador poco calificado. También puede tratarse de científicos cuyos descubrimientos hacen mucho bien a un montón de gente que no sabe ni le importa nada de ciencia. O cualquier otro trabajador que trae progreso pero que no tiene ningún tipo de poder. En una palabra: Un esclavo.

¿Pero qué pasaría si ese tercer ratón no necesitara comer?¿Si ese macho sumiso que trabaja todo el dia para que el jefe de la tribu que lo hostiliza a diaro, las hembras que los desprecian y crias que él no engendró se den la gran vida dejara de trabajar? Pero no hablaré de eso porque eso también es política. De lo que hablaré es de qué es lo que pasaría si las necesidades de este tercer ratón fueran tan pocas que no se viera en la necesidad de ser el tercer ratón.

Y aquí es donde entra el asunto de los fantasmas. Cuando un hombre no puede tomar el poder ni irse a vivir con sus propios medios lo que hace es convertirse en un fantasma. Poco a poco se le va viendo menos, su vida social dentro de la tribu se reduce al mínimo y se limita a hacer su trabajo y nada más hasta que un dia desaparece por completo. Ya sea porque se acostumbraron a su presencia silenciosa en segundo plano o porque abandonó la tribu.

¿Puede considerarse ladrón a un esclavo que dedica parte de su tiempo a si mismo?¿Quíen es el dueño de su tiempo y fuerzas?

Y es aquí donde estoy. Desde el 2014 me he visto en situaciones en las que se me ha amenazado con que debo de tomar el papel del tercer ratón sopena de morir de hambre y ser atacado de muchas formas. Y en estos dos años he investigado mucho para bajar mis necesidades tanto de dinero como de tiempo y salud y dedicar lo más posible a programar. Pues se suponía que para este momento debería de tener el suficiente nivel para trabajar por cuenta propia y no lo he conseguido aún, por eso estos dos años he investigado mucho sobre como evitar que la vida se me consuma en cosas que no quiero hacer y es ahí donde entra la gráfica de esta entrada.

Según me dijo cierto personaje enfundado en frac, con monóculo, puro y sombrero de copa la gente de la calle no puede invertir porque quiere invertir lo que le sobra después de haber cubierto sus necesidades básicas cuando lo correcto es invertir primero y cubrir tus necesidades básicas con lo que te sobre de la inversión. Si la inversión es buena esta cubrirá tus necesidades y si es mala simplemente uno va y lleva sus recursos a otro lado. Y por supuesto inversión no nada más es dinero, también lo son el tiempo y la energía.

En la gráfica la horizontal representa los esfuerzos invertidos en trabajar y la vertical el bienestar que uno es capaz de alcanzar. En los extremos malos tenemos de un lado el vagabundo que no trabaja y no hace nada y por tanto nada tiene mas que tiempo de sobra. Del otro extremo tenemos al trabajador que duerme muy poco y se rompe la espalda de sol a sol para pagar deudas y que apenas puede malvivir con lo que le queda después de pagarlas. El punto medio donde el bienestar más alto que uno puede alcanzar es aquel en el que cubrimos nuestras necesidades y todavía nos queda tiempo y salud para disfrutar la vida entendiéndose esto por como cada quién quiera hacerlo. Lo que la gráfica nos dice es que progresamos a medida que nos esforzamos pero llegado un cierto punto el esfuerzo comienza costarnos más dinero del que ganamos, nos quita tiempo para descansar y nuestra salud disminuye. Por lo que no tiene caso pasar ese punto a menos que tengamos una necesidad tan grande que estemos dispuestos a sacrificar dinero, tiempo y salud para satisfacerla.

Todo ese esfuerzo que pienso ahorrar lo destinaré a programar. O sea que quienes me leen sabrán de mi más seguido mientras que los que me conocen por cosas ajenas a la programación poco a poco me irán viendo menos hasta que llegue al punto en que un dia se olviden de mi. Pues he descubierto como vivir con muy poco y tener suficiente tiempo y vida para programar. Pues he visto compañeros que después de ganarse la vida honradamente como buenos ciudadanos lo último que quieren hacer al regresar a su casa es programar y yo no pienso pasar por lo mismo. Les contaría todas las cosas que he descubierto para lograr esto pero dado que para muchos uno no es rico hasta que tiene una bolsa de dinero al que todos le pueden meter la mano las guardaré para otra ocasión. De momento y nada más para hacer enojar a los normies que alguna vez quisieron hacer juegos diré que puedo moverme de la casa a la palanca que le da el queso a otros sin gastar dinero ni ser detenido por el tráfico, que averigué como mantener un buen estado de salud sin pagar gimnasios ni ejercitarme en casa, que puedo comer en casi cualquier parte donde no se me prohiba explícitamente hacerlo y casi gratis, mantener un aspecto presentable sin importar las condiciones del camino y por supuesto que puedo dormir mis 8 horas reglamentarias y en el peor de los casos dedicar un mínimo de dos horas diarias a la programación. Y estoy investigando como hacer para moverme en círculos sociales conflictivos sin meterme en lios. Para ellos iré desapareciendo poco a poco mientras que para ustedes que me siguen por la programación cada dia sabrán más de mi.

Ya para irme les dejo una anécdota que se dice le pasó a un sabio de la antiguedad: Estaba un dia un hombre comiendo un plato de lentejas cuando alguien se le acercó y dijo: -«Si te sometieras al emperador no tendrias que comer lentejas». A lo que aquel que estaba comiendo el plato de legumbres le contestó: -«Y si tú comieras lentejas no tendrias que quedar bien con el emperador»

Silencio Radial

Si no he posteado casi nada en meses es porque estoy reorganizando cosas en el blog.Quiero subir más código y sobre todo demos jugables.

Por cierto, un asunto ocurrido recientemente en la comunidad geek me dejó claro que un programador es realmente dos personas y la que ustedes conocen de mi es tan solo el Caminante Binario. El Caminante Material por el contrario no lo reconocerian ni aunque caminara frente a ustedes. Si el Caminante Binario cae puede reprogramarse pero si el Caminante Material muere todo se acaba. Así que por un tiempo estaré en mi forma de Caminante Material recolectando sangre y relojes (tiempo y energias pero me gusta hacerla de drama) para dárselos al Caminante Binario y que siga su lucha en el universo en el que ustedes me conocen. El dinero no sirve en el mundo de las computadoras ni el código en la calle. Así que si el Caminante Material le consigue suficiente sangre y relojes a su homónimo digital existe la posibilidad de que construya algo con lo que ambos puedan salir adelante. No garantizo nada, pero si el Caminante Binario triunfa ustedes serán los primeros en saberlo. Pero si el Caminante Material fracasa este blog quedará abandonado.

Ahora es momento de que salga y consiga esas dos cosas. Porque ni el dinero, ni la fama me ayudarán para salir de esta. O como dicen en el Cyberpunk: «¿Qué es la vida? Vida es un mínimo de actividad eléctrica cerebral. Cualquier cosa por encima de eso es algo por lo que debes dar las gracias.» En fin, no se cual sea la suerte del Caminante Material pero mientras registre actividad cerebral y tenga tiempo para ponerla en práctica no los abandonaré… espero.

Pequeños Códigos Hacen Grandes Sistemas

–Reune las partes y construye tu software–

¿Qué es mejor para un programador? ¿Un código que funciona pero no sabe como ni porqué o un pseudocódigo que sabe perfectamente como funciona pero que no tiene idea de como introducir en una computadora?

Para una persona normal no hay duda de que lo mejor es el código que ya funciona pero para el programador no es una decisión facil. Unos podrian decir que puede estudiar el código que ya funciona y a partir de ahí hacer el suyo. Esto es posible pero no siempre es la mejor opción.

Esta nota la escribo porque estoy pensando como compartir información sobre código y no se exactamente qué es lo que tengo que publicar. Pues como ya saben intento explicar las cosas de la misma manera en la que a mi me hubiera gustado que alguien me las explicara cuando comenzaba a programar. Recuerdo la frustración que sentía en aquellos años al intentar descifrar los símbolos inexplicables que formaban los códigos de programación y luego cuando intentaba introducirlos a la computadora sin saber que estos no hicieran lo que creía que debian hacer. Pero en esos libros de códigos indescifrables y términos que me sonaban por completo ajenos había algo que mi limitada mente podía entender: Los algoritmos.

Ya una vez comenté que el primer libro de programación que compré fue uno sobre algoritmos. En esos tiempos no sabía ni lo que significaba la palabra ni mucho menos la diferencia entre un algoritmo y un código de programación. Pero leyendo ese libro hasta donde pude entenderlo pude aprender como hacer algunas cosas como por ejemplo calcular un cerco envolvente o unir un montón de puntos de manera que no se cruzaran entre ellos. Detectar una secuencia de símbolos en un texto y por supuesto ordenar listas de números y buscar algo entre ellas. ¡Pero no sabía programar!

Así es. Conocía como hacer muchas cosas en papel y lapiz y más adelante que tuve en mis manos documentos como los manuales de intel también sabía como funcionaba un CPU y las cosas que era capaz de hacer pero aún así no podía hacer ningún programa. Para explicarlo contaré una vieja anécdota de programación:

Cuando empezaba a programar sabía por muchos escritos que había leido sobre como funcionaba una PC de aquel entonces que si quería escribir imágenes directo en pantalla necesitaba primero inicializar el modo gráfico y luego escribir en a partir de la posición de memoria A0000h. Que cada byte era uno de 256 posibles colores y que una pantalla de 320×200 pixeles ocupaba una región de memoria de 64000 bytes. Sabía lo que tenía que hacer pero no como hacerlo.

Lo peor era cuando iba y le preguntaba a los que yo creía que sabian del tema: Parecía que el hecho de que ya supiera lo que tenía que hacer pero no como hacerlo los hacía enojar más que si les preguntara desde cero como hacer las cosas. Recuerdo haber recibido toda clase de respuestas absurdas como cuando una vez pregunté como podía hacer para evitar que el buffer de teclado se desbordara y sonara ese sonido de campanita un alumno de últimos semestres me dijo que abriera la PC y le quitara la bocina interna.

Al final pude hacer ambas cosas con un viejo compilador de C de 16 bits usando punteros largos y guardando los punteros a funciones de los vectores de interrupción pero esas cosas eran demasiado revoltosas para hacerlas en C y las hacía metiendo instrucciones de ensamblador inline en el código en C. Y el resto de la historia ya la saben: Llegó el momento en el que decidí programar todo completamente en ensamblador para evitarme problemas.

El asunto es que hubo una época bastante larga en la que sabía muchas cosas pero no programaba nada de nada. Pero hubo un momento en el que comencé a programar usando todo lo que ya había averiguado y me volví imparable a partir de entonces. No estoy seguro de como ni por qué pero en ese tiempo comencé a programar por ráfagas. Unos cuantos meses al año escribia muchos programas y el resto lo dedicaba a leer y aprender. Hasta la fecha he intentado dedicar más tiempo a programar sin dejar por ello de aprender.

¿Pero a qué viene todo esto? Pues como dije al principio quiero compartir código pero no quiero subir instrucciones que nadie entienda ni tampoco quiero subir explicaciones que sean cansadas de leer. Para que me entiendan lo que quiero es escribir piezas pequeñas de código y empaquetarlas de manera sistemática para hacerlas fáciles de leer y entender. Hasta ahora cada paquete incluirá un poco de código en ensamblador, un texto explicando como funciona y una serie de imágenes o pequeños archivos de video para explicar algo. Lo que todavía no se es que tanto partir los programas.

Cada parte es util por si misma
Pero en equipo constituyen una fuerza imparable

Un programa completo en ASM es demasiado grande y describir su funcionamiento a alguien que no ha programado nunca requeriría miles de páginas de texto. Así que lo mejor es partir ese programa en partes intercambiables que puedan usarse en proyectos más grandes. Pero si parto esos programas en partes muy pequeñas tampoco es bueno, pues para empezar el programa no se podría compilar ni ejecutar y si las partes fueran lo bastante pequeñas no serian más que unas pocas instrucciones que en realidad no harian nada. Sería casi mejor hablar sobre cada OpCode. La idea es que esas partes sean lo bastante elaboradas para hacer algo apreciable y a la vez lo bastante sencillas para detallar su funcionamiento en una entrada como esta. Lo interesante sería ver funcionar cada una de estas partes por separado y esa es la parte que me falta resolver.

Ahora que lo veo con calma este proyecto me recuerda a aquellos antiguos cursos de modelismo por correspondencia en los que cada semana salia a la venta un fascículo impreso que incluia una pieza de un barco o avión para armar. Si el aficionado tenía la suficiente paciencia para comprar la revista durante meses sin perderse ni un solo número al final podía armar su modelo a escala y lucirlo en una repisa junto con toda la colección de tomos a modo de pequeña enciclopedia de ese modelo a escala en particular.

Si, ya se lo que están pensando: I«Otra vez el que escribe esto va a comenzar un nuevo proyecto que no va a terminar nunca» ¿Y saben una cosa? ¡Tienen razón!

Este proyecto no se va a terminar nunca porque no va a tener fin. Cada que me de la gana liberaré uno de estos paquetes aparentemente inservibles con código incluido y explicaré su funcionamiento de manera exhaustiva. Estas pequeñas unidades de por si ya sirven para algo aunque sea poco pero su verdadera utilidad será cuando trabajen unas con otras. Algo así como esos robots gigantes de las antiguas series japonesas que se construian a partir de vehículos que también podian funcionar por separado. Aunque aquí esas unidades independientes podrian construir muchos robots gigantes diferentes dependiendo de como se conecten unas con otras.

En fin, en cuanto averigue un formato conveniente para sacar a la luz estas partes intercambiables las sacaré una por una. Aunque debo advertirles de una buena vez de que si quieren ver estas partes funcionar de manera separada van a necesitar un debugger y algunas partes muy básicas sin las cuales las piezas no serian compilables. Obvio esas partes indispensables serán las primeras que voy a soltar. Ahora por lo menos necesito un lugar donde poder subir archivos y el resto será historia. Allá va un proyecto que nunca voy a terminar pero esta vez no se terminará porque se trata de un proyecto que no va a tener fin.

Informe asm86[11]=»mantra»;

–Recuerda tu Mantra–

«No tengas pensamientos negativos. Recuerda tu mantra» Esta frase aparecía en el juego Faxanadu de NES cada que el jugador caia en combate. Cuando recuperaba la conciencia aparecía a los pies del altar del templo y desde este el gurú le decía lo que aparece en la imagen: «Tú necesitas la paz mental. Meditaré contigo». Y por supuesto la meditación que traia la paz mental era el password que el jugador podía apuntar para continuar su juego otro dia.

Esta es una de las mejores secuencias de continue que recuerdo de los videojuegos de esa época. Pues bien, esta vez traigo otra idea para evitar que el blog se contamine como en tiempos pasados

Pues resulta que mi bolsa de suerte está a punto de acabarse y la de experiencia no está lo suficientemente llena. Mi último plan maestro si bien no ha sido frustrado sufrió un revés que me dejó en una situación dificil. Eso sería lo suficientemente dramático como para escribir toda clase de cosas que nada tienen que ver con la programación. Así que antes de tener esos pensamientos negativos no programables mejor recuerdo mi mantra y cuento exclusivamente la parte que tiene que ver con programación.

Para los que ven que escribo menos y no saben la causa es porque alguna vez prometí no escribir cosas que no fueran sobre programación. Todas las otras cosas están limitadas al «Informe asm86» y estos no los publico muy seguido.

Mi Plan de los Dos Años se vio frenado por cuestiones médicas que aunque no son mortales si me hubieran causado problemas muy serios de haber seguido como iba. Toca arreglar unos papeleos más y sobre todo dejar de andarme con esto de las operaciones encubiertas y «Dejar caer el Yunque» no sin antes avisar con unos cuantos ciclos de reloj de anticipación para evitar activar falsas alarmas.

Pues bien, va a haber algunas mejoras en este blog a partir de ahora. La principal es que voy a hablar mucho sobre ensamblador de 64 bits. Es una lástima que en estos años haya hablado tan poco del ASM de 32 bits pero más lástima me hubiera dado hablar de ese tema y que a nadie le importara. Ya hablaré de los procesadores de 32 bits cuando hable de retroinformática y tecnologias antiguas.

Otra cosa que no se si ventilar o no es la de los proyectos. Ya me cansó eso de comenzar proyectos que nunca termino o que pasan años antes de continuarlos pero si lo que muestro son pequeñas rutinas con principio y fin fáciles de explicar creo que puedo contribuir algo a la programación sin exponerme demasiado y sin importar que deje sin terminar las cosas.

No recuerdo haberlo comentado en este blog pero estoy seguro de que lo conté a más de uno. Llevo algún tiempo tratando de programar una herramienta que a primera vista parece una versión de Paint de los primeros Windows. Si bien funciona como un editor de sprites su verdadero propósito es convertir archivos multimedia en formatos intermedios que sean más sencillos de programar así como crear algunos assets de manera automatizada. Obvio no tendría la capacidad para hacer verdadero arte pero por lo menos botones o texturas sencillas de esas que quitan tanto tiempo si que puede hacer. Pues no pude continuar con mi último proyecto por ese tema. Aunque hubiera tenido todo un equipo de artistas creando assets para el juego no tenía una manera eficiente de transformarlos para poder ser usados en el juego y si simplemente hubiera hecho rutinas para abrir los archivos multimedia hubiera necesitado mucho más código para eso que para hacer funcionar el juego.

«No tengas pensamientos negativos.
Recuerda tu mantra»

Diversos sucesos me han hecho pensar. Hasta hace apenas un año estaba dispuesto a mantener la programación a un nivel mínimo para dedicar el tiempo para obtener recursos y programar de tiempo completo otra vez pero he visto como gente cerca de mi está cayendo y yo habría caido igual si hubiera seguido por ese camino. No cabe duda que el arma que necesitas para derrotar a los monstruos no siempre es la que estás buscando y mucho menos aquella que otros te dicen que necesitas encontrar. Es más. De haber seguido como iba ahora mismo estaría muerto, suicidado o con problemas físicos y mentales que me hubieran acortado la vida de manera significativa.

La emoción que siento ahora mismo es extraña. Es como cuando la guerra es inevitable pero uno es un mercenario. Parece que lo que llevo investigando de programación por cuenta propia y que por tanto tiempo me dijeron que no me iba a servir para conseguir un trabajo serio por fin va a tener un buen uso. Y antes de que comiencen a hacerse ideas aclaro de que nadie me ofreció empleo haciendo videojuegos como dicen algunos chismes malintencionados de internet.

No se como explicar esto pero en estos últimos meses alcancé un cierto conocimiento personal, inexplicable e intransferible que me va a hacer bastante más dificil de derrotar de lo que era antes. Lo más parecido a esto es el Chip Zen mencionado en el viejo videojuego de Neuromancer. La habilidad Zen le permitía al personaje recuperar sus capacidades mentales cuando su cerebro conectado a la red de datos estaba a punto de colapsar. Y no hubiera llegado a este conocimiento si no hubiera vivido todo lo que viví desde hace poco más de un año incluyendo el accidente de tránsito, las amenazas, mi conveniente desaparición de cierto lugar y una más de las veces en las que mis oportunidades de trabajar por comida se reducen. Veces que por cierto ya dejé de contar desde que vi que en mi penúltimo ‘trabajo’ nadie estaba ahí por ser buenos con las computadoras. De no haber pasado por todo esto tal vez ahora mismo sería ese empleado que existe en todas las oficinas del que nadie sabe ni quiere saber nada, que evitan cruzarse con él en los pasillos y con el que nadie quiere quedarse solo a deshoras. Que nunca habla con nadie y que la última vez que lo vieron animado y social fue una semana antes de que no volviera a la oficina nunca por una razón que nadie parece saber y los que la saben no se atreven a mencionar. Ese empleado que regresa todos los dias del trabajo a un lugar sucio y solitario a repetir toda la rutina una y otra vez hasta que un dia ya no puede más.

Lo se, mi situación actual no es nada envidiable pero es mi propia situación. Por lo menos en cuanto a la programación ahora me preocupa más entregar un buen producto y no como antes que el producto por el que me tenía que preocupar por entregar era yo. Ahora en el peor de los casos seré ese empleado antisocial que un dia desaparece porque se aburrió de la oficina y que cuando no está presenciando el apareamiento de los godinez silvestres está en su lugar sucio y solitario programando cosas que sus compañeros y jefes nada más han visto en Steam y ni siquiera tienen tiempo para jugarlas porque sus responsabilidades de adultos no los dejan. Lo se, es una guerra y la guerra no es bonita pero es mi guerra y justo ahora es cuando estoy por estrenar esta nueva arma de 64 bits que hace tiempo que quería ver en acción.

Así que es hora de reiniciar la consola, ingresar el último password y continuar la aventura. Y si las cosas salen mal leer de nuevo el mensaje de: «No tengas pensamientos negativos. Recuerda tu mantra» y luego volver a intentarlo.