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.

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.»

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.

¿Necesitan ayuda para ese examen, proyecto o tarea de ensamblador de final de semestre y no sabes nada?

–¡Pues hay un maestro que puede ayudarles!–

La oferta es simple. Si ustedes viven en o cerca de Monterrey, México les propongo reunirnos para revisar esos proyectos y exámenes extraordinarios que para estas fechas ya deben de estar preparando. Las materias en las que puedo ayudarlos son las de lenguaje ensamblador, programación con Winapi, algoritmos y estructuras de datos y otras relacionadas con el gamedev. Lo que ofrezco es darles una capacitación presencial intensiva sobre estas materias. Si ustedes no tienen ningún impedimento mental serio les prometo que un curso express de una semana será suficiente para aprobar una de estas materias en extraordinario por lo menos en la materia de ensamblador. En cuanto a los proyectos si es que tienen alguno podemos hacer en ese mismo tiempo algo mínimamente aceptable para aprobar sus materias.

Pero dejemos primero dos cosas claras: La primera es que no les voy a hacer la tarea. Las tareas y los proyectos los van a hacer ustedes porque luego de que termine con ustedes serán capaces de hacerla. A lo mucho los voy a guiar paso por paso si es que mis explicaciones no fueron lo suficientemente claras.

La segunda es que no lo estoy haciendo por dinero. No les voy a cobrar un centavo ni los voy a obligar a hacer nada. Si quieren la ayuda y pasan que bueno y si no les gustó pueden irse en cualquier momento y considerar esto una simple reunión de amigos de internet.

¿Y qué ganó yo? Pues que hago esto porque necesito hacer una pequeña demostración pública. Probar que puedo tomar a un grupo de estudiantes promedio interesados en hacer videojuegos pero con poca o ninguna experiencia y capacitarlos de manera rápida y eficiente en una materia tan oscura como lo es la programación en ensamblador. Y qué mejor que hacer esto en una situación límite como lo es al final de semestre para probarlo.
Había considerado ofrecer este trato hace meses pero nada como esperar hasta el último momento para ser tomado más en serio. O tal vez este ofrecimiento sea demasiado temprano si es que tienen pensado volver a cursar la materia el próximo semestre.

A partir de aquí no hay vuelta atrás. El trato está frente a ustedes. Tomen la píldora azul si no les interesa. Despertarán mañana y será lo que quieran creer. Pasarán la materia si es que no tienen problemas o tal vez reprueben y consideren cambiarse a una carrera que no tenga tanta programación. O bien pueden tomar la píldora roja y ver hasta donde llega la madriguera del conejo. Se como se sienten. Lo se porque yo estuve en su lugar. Con mi ayuda podrán leer esas páginas llenas de códigos de ensamblador que ahora ven como superficies de símbolos sin significado y podrán manejar esas herramientas que no tienen idea de como funcionan.

¿Y como pueden contactarme? Muy simple. Al final de esta entrada voy a dejar un link a mi página de ASK. Ahí podrán hacer preguntas de forma anónima y sin registro sobre como, cuando y donde hacer las reuniones. Aunque la foto de avatar de ASK conteste casi todas estas preguntas. Por cierto. Algunos de ustedes reconocerán el lugar donde fue tomada esa foto y tal vez hasta cursen ahí la única carrera que lleva ensamblador. Pero la invitación está abierta a cualquiera que pueda estar físicamente en la ciudad. Y ahora la invitación está frente a ustedes.

Pregunten más información en este ASK. No necesitan registrarse

Informe asm86[010] = «Minidemo»;

–Entre la subsistencia y las ganas de vivir–

Aunque este es un informe más no se puede decir que sea por completo ajeno a la programación. Por primera vez en todo el tiempo que llevo escribiendo aquí tengo un proyecto terminado y ejecutable. O por lo menos bastante completo como para correr y hacer algo. Más adelante puede que comente como funciona y le corregiré algunos bugs para que lo puedan descargar. Por ahora les contaré de modo breve la historia de este minidemo.

A nivel técnico este minidemo es un ejecutable de Windows de 32 bits que pude comprobar que corre sin problemas en sistemas Windows Vista y 7 y que si no me equivoco debería correr también en cualquier sistema basado en Windows de 32 bits usados en los últimos 20 años. Está programado cien porciento en ensamblador y compilado en Flatassembler y todos los efectos gráficos están hechos con instrucciones de manejo de memoria. Se usó unicamente un par de funciones antiguas de DirectX para inicializar el modo de video y obtener acceso directo al frame buffer. Los sprites son archivos TGA de 32 bits que son decodificados y cargados a la memoria a nivel binario. Sprites que debo advertir de una vez que no fueron dibujados por mi sino que me los descargué de manera gandalla de otros sitios de aficionados al RPG maker. Los personajes interactuan entre ellos y con el escenario en formas que detallaré más adelante. Y también pueden ser controlador por el usuario con el teclado. Pero ya contaré los detalles de este demo con calma en otra entrada. Ahora veamos los no menos interesantes motivos de su creación. Click en la imagen para ampliarla.

Hasta que no arregle ciertos asuntos omitiré nombres de personas y organizaciones para que nadie salga desprestigiado pero lo más problable es que esos picos de visitas que he tenido esta semana tengan algo que ver con ellas. En fin, comencemos por el principio.

Resulta que hay cierto lugar muy especial relacionado con los videojuegos en el que no encontraban gente que supiera de programación en ensamblador. Me enteré por chismes que incluso levantaron por una vez su costumbre de contratar tan solo a familiares de trabajadores con tal de encontrar a alguien que supiera y se rebajaron a buscarlos fuera de su círculo de confianza. En ese tiempo no me interesaba lo que hicieran pero por otra razón que rebelaré cuando esté más ebrio decidí intervenir.

Por lo que me enteré quien estaba a cargo de programar en ASM no tenía mucha idea de lo que estaba haciendo. Y no debería de culparlo porque en las carreras de ingeniería en computación actuales no solo no se enseña ensamblador sino que no ven ninguno de los algoritomos necesarios para hacer este tipo de cosas. En fin, el demo tuvo su origen en una especie de reto, pues me enteré que había necesidad de programar un demo que cumpliera una serie de requisitos. Requisitos que estoy bien seguro que nadie de los que estaban ahí pudo cumplir al cien por ciento. Y por lo que escuché dudo que ni siquiera quién los pidió pudiera haberlos hecho. Por lo que investigué lo más que se acercaron fue a hacer algunos ejecutables que necesitaban correr en máquinas virtuales que emulaban sistemas antiguos como el DosBox.

Mencionaré alguno de los requisitos que debía de tener el programa. No los recuerdo todos: 1.- Al menos un sprite animado controlable por el jugador y que respondiera a la dirección que estuviera mirando. 2.- Un segundo personaje animado que se moviera por si mismo y que interactuara con el personaje controlado por el jugador de alguna manera.3.- El fondo debía de ser una imagen cargada y por supuesto los personajes debian de moverse sobre ella sin afectarla.4.- Debia de haber detección de colisiones 5.- Debía incluir efecto de fade (cambiar la tonalidad de las imágenes de fondo) 6.- La imagen de fondo debía de poder cambiarse en tiempo de ejecución. 7.- Las imágenes debian de tener efecto de rotación y escalado.

De momento no recuerdo más requisitos pero por lo que investigué si a quienes se les encargó esto hubieran sido capaces de abrir un sencillo archivo de imagen en ensamblador y mostrarlo en pantalla sin ningún tipo de interacción hubiera sido un logro enorme. En fin, como parte de un elaborado plan decidí que haría un programa que cumpliera con todos los requisitos y que además corriera en un sistema actual sin necesidad de máquinas virtuales.

Los datos para poder hacer el programa me llegaron el 12 de octubre del 2014 y en ese momento comencé a programar. El proyecto que creí terminaría en un més al final me llevó casi dos meses y para cuando tuve un avance jugable ya era demasiado tarde. Lo que más me costó programar fue un sistema de animación que cargara un archivo de imagen con una secuencia de animación y la mostrara en el programa de modo que reaccionara de acuerdo a lo que estuviera ocurriendo en el juego. Hubo bugs que en ese entonces no pude resolver y al final adapté el código para que no fuera posible que los bugs aparecieran. En fin, llegó el mes de diciembre y se acabó la oportunidad de cumplir mis planes presentando ese minidemo. O al menos eso creí en ese momento.

Mi plan diabólico consistía en presentar el demo y ofrecer ayuda de manera encubierta para irme construyendo una reputación pero al no tener el programa a tiempo pensé que había perdido la oportunidad. Pero para mi sorpresa me enteré que si hubo interés en ese código. Así que decidí aumentarle cosas y volver a presentarlo. Pero fue entonces cuando ocurrieron los problemas. Cuando parecía que mi vida se había solucionado resultó que se me requirió para un par de asuntos bastante menos heróicos.

No entraré en detalles porque no quiero desviarme demasiado del asunto del demo y la programación. Bastará con que sepan que este que es el primero de muchos demos es parte de un plan bastante grande que si sale bien me permitirá seguir programando por muchos años más en lugar de tener que «ganarme la vida honradamente» haciendo cualquier otra cosa que no quiera hacer por comida. Esos demos servirán para ganarme una reputación. Y esos demos a su debido tiempo los iré subiendo cuando hayan cumplido la función para la que fueron creados. Y ahora para ponerme poético agregaré que en este momento tengo que elegir entre obtener la mínima subsistencia o recuperar las ganas de vivir. Creo que iré por las ganas de vivir porque como comprobé con los incidentes del verano pasado en el que tuve todos los recursos materiales y humanos para recuperarme de aquella caida fue bastante poco lo que hice para mejorar. Esa experiencia me enseñó que prefiero mil veces estar rodeado de horrores a los que enfrento con renovado espíritu de combate que rodeado de gente dándome ánimos para levantarme y continuar viviendo una vida que ya no tiene nada para mi. Las amenazas anteriores ya no me preocupan. Tal vez sea hora de encontrar algo nuevo o tal vez volver atrás y regresar por algo que en verdad me preocupe perder. Sea como sea, esto es una oportunidad no de conseguir algo, sino una oportunidad para volver una vez más a la acción. Ya me preocuparé de las amanazas cuando lleguen.

Mas Máquina que Hombre

–Como programar en lenguaje máquina–

Un programador de Ensamblador que no sabe programar en lenguaje máquina es como un químico que desconoce la manipulación del átomo. También se ha dicho mucho que programar en lenguaje máquina es imposible. Sin embargo, luego de algunos meses de insultar lamers y ver dibujitos en paint, considero que ya están listos para comenzar a hacer tal proeza.

No todos los campos se usan en todas las instrucciones. El único indispensable es el de OpCode. Todos los demás son opcionales.

Veamos un poco que significa cada campo:

Prefijos.- Existen prefijos que modifican las instrucciones. Algunos de ellos son los modificadores de ancho de operando/dirección (66h y 67h), los de repetición para funciones de manejo de cadenas y el temible prefijo REX del que se hablará en otra nota.

OpCode.- Este es el único obligatorio. Una instrucción puede medir desde un solo byte, como por ejemplo un NOP (90h) o hasta 16 bytes como en algunos saltos largos. El campo de OpCode por si solo puede medir entre 1 y 3 bytes.

ModR/M.- Este es un byte que especifica los operandos de la instrucción. Por lo general se pueden expresar las combinaciones de operandos mas usuales tan solo con este, pero a veces es necesario otro byte para direccionamientos mas complejos.

SIB.- Su nombre viene de Scalar Index Base. Es el complemento de ModR/M. Con este es posible hacer combinaciones de registros y desplazamientos que no era posible lograr en los antiguos modelos de 16 bits.

Desplazamiento.- Puede medir entre 1 y 4 bytes. Especifica una localidad de memoria que puede ser absoluta o relativa.

Valor Inmediato.- Semejante al anterior, pero este número se usa para representar un valor inmediato. Un valor inmediato es cuando uno de los operandos de la instrucción es una constante.

Definitivamente tengo que poner un link mas directo a los manuales de Intel.

Ahora a insultar.- Lo primero que han de preguntarse es que gana uno programando en lenguaje máquina. Bueno, ademas de hacer algo que no cualquiera puede hacer y el aumento de la autoestima a lo que esto conduce. Si conocen por ejemplo los bytes ModRM y SIB ya no tendrán dudas sobre que combinaciones son válidas. También es posible activar instrucciones de los procesadores mas recientes sin tener que esperar a que aparezca un compilador que las use. Aunque en mi experiencia personal es mas sencillo construir tu propio ensamblador que hacer programas completos en lenguaje máquina y el resultado es igual de eficiente. Otra gracia que tiene es que cuando las instrucciones cumplen ciertas reglas de alineación dentro de la memoria se ejecutan mucho mas rápido que si solo las aventaras así como van.

Por cierto, este diagrama solo es válido para lo que Intel llama “modo de compatibilidad” es decir que si su sistema Windows es de 64 bits. El formato de la instrucción cambia un poco. En ese formato conocido como “IA-32e”. En ese modo de operación es posible manejar memoria mas allá de la barrera de los 4 Gbytes de manera directa. Aunque la única diferencia entre lo que acabo de explicar y este modo, tan solo es el prefijo REX que va entre los prefijos y el OpCode.

Por último, y nada mas para que se sientan un poco como Neo de Matrix, intenten insertar en el código de siempre algunas instrucciones en lenguaje máquina.

Para insertar una instrucción en lenguaje máquina, hacemos lo mismo que cuando inicializamos una localidad de memoria. Por ejemplo. Supongamos que tenemos este código:

         mov    eax, 666h

Si mandamos desplegar el contenido del acumulador con una función o usamos un depurador de códigos, veremos que eax contiene el valor hexadecimal 666. Ahora, si modificaramos el código de esta forma:

         mov	eax, 666h
         db  	90h

no sucedería nada. Pues db 90h es la instrucción NOP, daría lo mismo si escribiéramos NOP en lugar de 90h. Estanstrucción aperentemente inutil se usa para alinear código y acelerar su ejecución dentro del CPU. Ahora hagamos algo mas visible:

              mov       eax, 666h
              db	90h
              db	33h,0c0h

Si ahora desplegamos el contenido de EAX, este mostrará CERO. Esto es porque 33h,0c0h es el código máquina de XOR EAX, EAX. Pone en cero el contenido de EAX y es mucho mas rápida y ocupa un tercio de la memoria que MOV EAX, 0. En realidad no es necesario poner cada instrucción en un renglón. Es posible poner todos los códigos máquina en uno solo o partirnos como queramos. Al final el Ensamblador va a juntarlos todos de manera lineal.

Bueno, ya me extendí mucho, en próximas notas veremos mas sobre el lenguaje máquina y de paso exploraremos un poco el modo de operación de 64 bits. Esperen un pequeño BOOM de notas, porque ya vienen las vacaciones y voy a tener mas tiempo libre para escribir estupideces. Y si se aburren, consiganse la segunda parte de los manuales de intel (Instruction Set Reference) y traten de desensamblar a mano el programa PEDEMO.EXE. Con solo un editor HEX, o si no se atreven, con el OllyDbg pero sin mirar las instrucciones. Si pueden hacer esto y además se divierten, definitivamente les va a gustar programar en Ensamblador.