Programación en Lenguaje Ensamblador

-El Verdadero Lenguaje de las Máquinas-

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.

julio 20, 2017 Posted by | Uncategorized | , , | 1 comentario

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

marzo 1, 2017 Posted by | Uncategorized | 2 comentarios

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.

febrero 19, 2017 Posted by | programación | 2 comentarios

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.

noviembre 17, 2016 Posted by | Uncategorized | Deja un comentario

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

noviembre 10, 2016 Posted by | programación | 2 comentarios

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.

agosto 17, 2016 Posted by | Uncategorized | , | 2 comentarios

¿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á.

agosto 1, 2016 Posted by | Uncategorized | , , | 5 comentarios

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.

julio 19, 2016 Posted by | Uncategorized | , | 1 comentario

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.

junio 26, 2016 Posted by | Uncategorized | , | Deja un comentario

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.

junio 21, 2016 Posted by | programación, videojuegos | 1 comentario

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.

junio 17, 2016 Posted by | Uncategorized | Deja un comentario

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”

mayo 31, 2016 Posted by | Uncategorized | 3 comentarios

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.

diciembre 6, 2015 Posted by | Uncategorized | 1 comentario

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.

julio 9, 2015 Posted by | Uncategorized | 9 comentarios

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.

julio 3, 2015 Posted by | Uncategorized | Deja un comentario

¿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

abril 17, 2015 Posted by | ensamblador, programación, Uncategorized | , , | 8 comentarios

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.

febrero 16, 2015 Posted by | ensamblador, programación, videojuegos | 3 comentarios

Informe ASM86[009]: He Visto el Futuro

–El Artesano y el Refugiado Tecnológico–

He visto el futuro. Verán, llevo un par de años siguiendo las aventuras de cierto artesano que alguna vez fue muy poderoso en su medio pero que un cambio tecnológico lo redujo a poco menos que un vagabundo sin empleo formal que vive recluido defendiendo sus sueños con los escasos recursos humanos y mecánicos con los que todavia cuenta. Si bien este personaje hizo cosas bastante cuestionables en su juventud sus acciones son travesuras de niños tomando en cuenta toda la asquerosidad que es normal entre la gente que se dedica a lo que él y que no voy a mencionar ni como insulto porque no quiero que me acusen de fomentar la discriminación. Ha resistido por décadas rodeado de drogas, corrupción y desintegración familiar donde tarde o temprano al practicante se le obliga a abandonar sus sueños a cambio de una subsistencia moral y económicamente miserable.

Y sin embargo ese artesano sigue luchando, incluso he sabido que es tan diestro con las modernas herramientas computarizadas que imitan hasta donde pueden las propiedades físicas como con aquellas que dominó en sus mejores años. Dejando en claro que su habilidad está intacta a pesar de los múltiples problemas de salud que le dejó la vida que eligió seguir. Tal vez la única cosa que podría recriminarle sea que a pesar de su poder y habilidades nunca consiguió volver a levantar el negocio que alguna vez tuvo. Yo en lo personal considero que nunca pudo levantarse por un cambio tecnológico que hizo que los productos que fabricaba dejaran de ser redituables aunque sus detractores que son muchos cuentan otras historias.

¿Y qué tiene que ver la historia de este genio acorralado con la programación? Pues bien, estoy presenciando un cambio tecnológico que me va a hacer acabar como él o incluso peor porque al menos yo nunca fui capaz de poner a la venta un producto de consumo masivo. La programación ha cambiado mucho y en los últimos 20 años pasó de ser un campo donde un individuo podía obtener fama y riquezas si sabía programar a una industria mecanizada donde se contrata a miles de personas para trabajar en pequeñas partes de un sinfin de proyectos pequeños. Acabando por completo con toda la posible gloria personal de los antiguos programadores. Un cambio muy similar al ocurrido en el mundo de aquel artesano. Por no mencionar que desde que se popularizaron los dispositivos móviles la gente ya no quiere pagar ni siquiera un dolar por el software. En fin, si no hago algo en este mismo instante voy a dar con todo y mis códigos de ensamblador al mismo agujero en el que está aquel artesano del inicio de esta entrada. Que si bien admiro por su espíritu indomable me entristece verlo en esa situación. Misma situación en la que estoy muy cerca de caer si no es que a mi me va peor.

¿Y qué voy a hacer? Pues para empezar voy a cambiar la dirección de este barco. Hay muchos temas de programación que parece que a nadie le interesan y no se si es porque nadie los entiende o porque no cree que le vayan a servir para algo. Y por otro lado hay otros temas que parecen muy sencillos que son los que más se leen. Verán, cuando empecé a escribir este blog lo hice porque me costaba mucho encontrar información de programación no solo de ensamblador sino de otros temas como por ejemplo ingeniería inversa, programación gráfica o de videojuegos y no quería que otros que se interesaran en estos temas llegaran a creer que no hallarian nunca nada sobre esto. Pero por situaciones no muy gratas en años recientes me he dado cuenta de que la estoy fastidiando. No se que esperaba al escribir sobre esos temas en internet. Sin embargo, revisando tablas como la de la foto he dado con que hay un cierto subgrupo que si toma en serio ciertos temas y quiero concentrarme en darle a ese pequeño grupo lo que quiere. Ese pequeño grupo son los programadores principiantes de ensamblador. Así que me concentraré en ellos y dejaré que los grandes profesionales de La Industria vayan a otro lado a buscar esa cosa que llaman Know How porque este pobre diablo prietito, anciano y sin preparación no tiene nada que ofrecerles. Aquí iba a rematar con una trolleada pero ni siquiera eso se merecen. Así que mejor paso a otro tema.

Lo que tanto temía que hubiera pasado no pasó…
…pero lo que más temo todavía puede pasar

La verdad es que no me gusta ventilar mi vida personal en internet pero ya cumplí un mes de aquel Plan de los Dos Años que mencioné hace algunas entradas. Ahorrándome todos los detalles no relacionados con la programación diré que ese plan es mi último intento para no acabar administrando bases de datos por comida y me obliga a hacer una serie de cosas que en otro tiempo nunca hubiera hecho o que me da demasiada verguenza admitir que estoy haciendo. Aunque respeto el que para muchos dichas experiencias son logros muy importantes en sus vidas y hasta dan gracias a sus respectivos dioses por no haberlos matado antes de que ese dia llegara. Y de las pocas cosas confesables que involucra ese plan la primera ya comenzó. Para no meterme en lios digamos que llegué a una tierra mágica llena de otakus que quieren hacer videojuegos y da la casualidad de que ahí si se toma en serio el ASM. O al menos lo suficientemente en serio como para que mis tan despreciados conocimientos en la materia valgan para algo. En un par de meses les contaré si fui capaz de hacer esos códigos o no. Por cierto, a diferencia de mucha gente que se me ha acercado pidiéndome ayuda y a la que le he quedado mal (y que agradezco que unos pocos de ellos todavía me siguen) esta vez tengo una razón muy importante para hacer las cosas bien. Así que más me vale hacer esos códigos porque necesito construirme una reputación en ese peculiar microcosmos y tengo un margen de poco más de 2 años que es lo que tardará el trámite burocrático que tengo que completar para que los amos de esas tierras me permitan irme a vivir y trabajar ahí legalmente. Trámite que por cierto va muy mal por culpa de un percance que tuve tuve a inicios del verano de este 2014. Por cierto, ese trámite “migratorio” es una de esas cosas que me da mucha verguenza admitir que estoy haciendo. Así que me referiré a este y todo lo relacionado con éso como “El Permiso”

No quiero adelantar cosas que tal vez no pasen pero parece que en ese pequeño microcosmos hay muchas oportunidades para el ASM. Aunque eso no es lo que más me preocupa. Hay otro asunto muy personal que me inquieta y que publicaré en internet cuando lo resuelva pero que si se resuelve prometo que haré lo imposible por completar este plan. Otra razón por la que quiero que esto se de es porque ese es el único modo de vida que me garantiza que voy a poder seguir programando y que no voy a acabar mis dias administrando bases de datos por comida. No quiero regresar a casa de un trabajo que no quiero hacer y sin tiempo ni energias para programar. Hasta ahora he tratado de estar en esa situación el menor tiempo posible y he ahorrado para seguir intentando una y otra vez pero si el cambio tecnológico sigue como va pronto no voy a tener otra opción mas que acabar en uno de esos trabajos del que probablemente nunca voy a salir o peor aún del que voy a salir cuando ese cambio tecnológico me deje como el artesano del principio de esta entrada. Estoy seguro que si dicho artesano me conociera y me dedicara a lo mismo que él desaprobaria que hiciera esto. Yo mismo lo desapruebo. Me siento como si estuviera huyendo por mi vida. Pero esto no es una retirada. Ni siquiera aplica aquello de vivir para pelear otro dia. Más bien voy a moverme a una posición desde la que pueda seguir peleando porque en este espacio que he defendido durante años ya no queda nada que proteger. Lo bueno es que a diferencia de aquel artesano enfermo que compadezco casi tanto como admiro he aprendido muchas técnicas para sobrevivir en situaciones difíciles. Pero se que tarde o temprano también voy a caer. ¡Es hora de movilizar mis fuerzas a otra posición!

octubre 4, 2014 Posted by | Uncategorized | 3 comentarios

Sistemas de 8, 16 o 32 bits ¿Qué significa eso?

–Longitud de Palabra de una Máquina–

Las computadoras no siempre se vendieron tan alegremente como se venden ahora. En otros tiempos eran productos para gente muy técnica y lo único que distinguía una computadora de otra era su capacidad. Cualquier sistema relacionado con la computación desde las avanzadas estaciones de trabajo de ingeniería hasta las mas sencillas consolas de videojuegos se anunciaban por sus capacidades técnicas. Esta moda tuvo su punto más notorio a principio de la década de los noventa cuando estas características técnicas se usaron para vender estos equipos. Como en el caso de esta imagen que muestra una publicidad del SNES

Sin embargo hubo un problema, y es que ahora le estaban vendiendo computadoras a gente que no tenía por qué saber cuestiones técnicas de los equipos y hubo muchos malentendidos entre los consumidores que en otra entrada les detallaré. Y estos problemas terminaron cuando alguien en algún departamento de mercadotecnia se dio cuenta de esto y cambiaron la publicidad. Uno de los mejores ejemplos fueron los procesadores de Intel que ya no se anuncian por sus capacidades técnicas sino por crípticos números de modelo y ya es cosa de que a quién le interese se compre el CPU que más le convenga.

En otra entrada les comentaré esta confusión sobre los detalles técnicos de las computadoras entre los consumidores pero ahora les contaré unas cuantas que presencié yo mismo en la época de las consolas de videojuegos de 16 bits:

Eran principios de los años noventa, las computadoras de escritorio contaban con CPU de 32 bits capaces de correr en modo de 16 bits para fines de retrocompatibilidad. En ese tiempo las consolas de videojuegos de 8 bits como el venerable NES aún estaban en circulación. Y en un buen dia comenzaron a venderse las nuevas consolas de 16 bits como el Sega Genesis/Megadrive y el Super Nintendo Entertainment System (SNES). Ambos sistemas se anunciaban como sistemas “revolucionarios” de 16 bits y si bien eran revolucionarios si los comparábamos con la generación anterior de 8 bits sus procesadores no eran nada comparados con un intel 486 de 32 bits corriendo en Modo Protegido. Sin embargo como en esa época los gamers de PC no jugaban juegos de acción rápida como los vistos en las salas de arcade o las consolas sino lentas y tediosas aventuras gráficas con animaciones lentas y pitidos horrorosos del PC speaker la gente que no sabía nada de programación creyó que sistemas de 16 bits de no más de 200 dólares eran más poderosos que computadoras completas de 2000 dólares. Algo similar pasó con el Nintendo 64 y el primer Playstation pero como ya dije esa historia la contaré otro dia.

Volviendo a la pregunta original: ¿Qué demonios significa cuando nos dicen que un sistema es de 16, 32, 64 o cualquier otra cantidad de bits? Cuando nos dicen esto se refieren a la longitud de palabra del CPU. Para explicar este concepto vamos a repasar primero lo que es un BIT. Un bit es un dígito binario que puede ser 0 o 1. Las computadoras usan bits para representar la información y procesarla y mientras más bits sea capaz de manejar un sistema mayor será la cantidad de información que podrá manejar. Piensen en un bit como en un dedo. Levanten una de sus manos y elijan el dedo que quieran. Pueden estirar el dedo o mantenerlo doblado. Si estiran el dedo contará como un uno y si lo doblan como un cero. De ese modo pueden representar información. Digamos que a alguien que no puede oirlos le quieren dar órdenes de que avance o se detenga. Si levantan la mano con todos los dedos doblados en forma de puño puede significar que se detenga y si lo hacen con un dedo levantado significa que avance.

Pues bien, ese dedo que pueden doblar o estirar es un bit. Y las computadoras trabajan así. Ese Bit puede significar encendido o apagado, verdadero o falso, avanzar o detenerse. ¿Pero qué pasa si usamos más bits? Al tener más bits podemos representar más información. Regresando a las manos si en lugar de usar un solo dedo usáramos 2 podríamos podríamos mandar 4 tipos diferentes de mensajes: 2 dedos doblados, el primero doblado y el segundo extendido, el primero extendido y el segundo doblado o los dos extendidos. Siguiendo está lógica si usamos 3 dedos podemos combinarlos de 8 maneras diferentes, 4 de 16 y así hasta usar los 10 dedos de las manos que pueden ponerse en 1024 posiciones diferentes. Pero de momento ignoremos los pulgares y quedémonos con 8 dedos que pueden representar 256 diferentes posiciones.


LAS MANOS DE LAS COMPUTADORAS

¿Y qué tiene que ver esto con las computadoras? Pues resulta que las computadoras también tienen manos con dedos que pueden doblar y estirar. Manos con dedos con las que pueden recoger, manipular y depositar información digitalizada dentro del sistema. Esas manos se llaman Registros de CPU y todo sistema de computación por insignificante que parezca tiene por lo menos uno de estos. Aunque estas pequeñas manos y su comportamiento puede ser muy diferente entre un sistema y otro. Cuando comenzaba a programar nadie me sabía explicar exactamente lo que era un registro de CPU y en ese momento me quedé con la definición de “Variable de hardware”. Pero si bien un registro puede almacenar información como lo hace aquello que los programadores entienden como una variable es mucho más que eso. Un registro de CPU es como una mano y al igual que una variable puede tomar un valor y almacenarlo pero puede hacer muchas más cosas. Ya hablaré en detalle de lo que es un registro de CPU en otra entrada para principiantes. Por ahora seguiré explicando el asunto ese de los bits de un sistema.

A diferencia de las variables que conocen los programadores los registros de CPU son físicos y en verdad existen dentro del CPU. En algún lugar hay una imagen de Intel que muestra uno de sus primeros CPU en la época en la que su circuitería todavía podía verse con instrumentos ópticos y claramente pueden verse los circuitos de los registros principales de CPU. Si programan en ensamblador tendrán control directo sobre esos registros como si fueran manos. Pueden darle instrucciones al CPU de que el registro principal lea una localidad de memoria específica, le sume algún valor que les de la gana y la vuelva a guardar en otra localidad de memoria diferente tal y como un trabajador de un taller tomaría una pieza de un lugar de la mesa, le haría alguna modificación y la dejaría en algún lugar de la mesa diferente. Si programan en cualquier otro lenguaje que no sea ensamblador no verán nunca un registro de CPU en su código, sin embargo en algunos como por ejemplo C tendrán que tener en mente cuantos bits miden las variables para evitar pérdidas de información.

Ahora bien, ya sabemos que las computadoras tienen manos con las que trabajan y que estas manos tienen dedos que se llaman bits. Y la cantidad de bits que hay en un registro de CPU es lo que le llaman Longitud de Palabra de la Máquina. Mientras mayor sea la longitud de palabra de un sistema mayor será el número que puede almacenar dentro de un registro de CPU con los que trabaja. Y dependiendo de como esté construido el resto del sistema serán más las cosas que podemos hacer. Sin embargo, aunque el CPU tenga una longitud de palabra determinada el resto del sistema no tiene por qué tener las mismas longitudes. Es más, por regla general el CPU siempre tiene una longitud de palabra mayor que la del resto del sistema. Esto permite bajar costos pero pueden darse situaciones graciosas. Por ejemplo recuerdo un sistema cuyo CPU era de 64 bits pero el sistema de memoria era de 32 así que para cargar o guardar un solo valor entre el registro y la memoria tenía que leerlo en 2 mitades y hacer una serie de operaciones binarias para acomodarlo y esto era mucho más tardado que hacer varias operaciones matemáticas con ese mismo valor. A veces se utilizan sistemas así cuando se trabaja con números muy grandes como los que salen cuando calculamos factoriales. Pero también puede darse el caso opuesto como pasó con el PCengine/TurboGraphics que era una consola de videojuegos con un CPU de 8 bits y un procesador gráfico de 16 que le permitió correr juegos con arte bastante detallado para su tiempo sin elevar demasiado los costos de programación. Ahora bien, otra razón por la que no todo el sistema comparte la misma longitud de palabra que el CPU es porque no siempre se necesita. El humano tiene sus limitaciones físicas. Por ejemplo sus ojos no pueden percibir más de 16.7 millones de colores para eso bastan 24 bits (aunque se usan 32 bits para optimizar la velocidad), el oido apenas si percibe una frecuencia de hasta 22.1 kHz y para reproducir sonido estereo calidad de CD basta un sistema de 16 bits. En cuanto al manejo de memoria apenas se comienzan a vender a civiles computadoras con más de 4 Gb de memoria aunque esta cantidad de memoria era perfectamente manejable para un CPU 386 de intel construido a mediados de los años ochenta. Tal vez los sistemas cuyas longitudes de palabra más grandes que existan, o por lo menos que conozco son las unidades vectoriales usadas para gráficas por computadora que le aplican una misma operación matemática a varios números en forma paralela y que he visto que miden de 128 bits hacia arriba. Estas longitudes de palabra también se usan para hacer encriptación.

Tener un sistema de muchos bits o con una longitud de palabra muy grande permite hacer más cosas aunque también es más costoso y dificil de programar. Por regla general cuando se habla de los bits de un sistema casi siempre se refieren a la longitud de palabra de su procesador principal. En el caso de las unidades de almacenamiento como los discos la cantidad de bits hace referencia a cuanta información puede almacenar y en el caso de las memorias internas hay que dejar en claro la diferencia entre capacidad de almacenamiento, velocidad de acceso y el “Throughput” que es la cantidad máxima de bits que podemos mover entre la memoria y el CPU de una sola vez. En resumen, una gran cantidad de bits en un sistema no siempre es garantía de que sea más poderoso que uno de menos bits, solo que su uso es diferente. Como comenté al principio muchos juegos de consola de la era de los 16 bits eran mucho mejores que los juegos hechos para las primeras PC de 32 bits porque su hardware al tener que ser más barato tenía que estar más optimizado y la técnica para programarlo era más refinada. Pero como dije al principio este asunto de los bits de un sistema solo les importa a los que programan en ensamblador, los que usan otros lenguajes les basta con tener una idea de las limitaciones de manera general y tal vez saber cual es el número más grande con el que pueden trabajar sin causar un error de desbordamiento. Pero dejémoslos a ellos y quedémonos con la programación en ensamblador. Por ahora me basta con que sepan a qué se refieren cuando dicen (o decian) que un sistema es de una determinada cantidad de bits. Otro dia les platicaré como durante los noventa se hizo todo un caos por usar detalles técnicos en la publicidad de las consolas de videojuegos y la razón por la que se dejó de hacer. Por ahora mejor pónganse a programar.

agosto 25, 2014 Posted by | Uncategorized | 2 comentarios

Tuve un percance del que salí sin secuelas… visibles

–Cambiaré de camino pero no de costumbres–

Estuve ausente algún tiempo del internet debido a una serie de incidentes bastante feos que me ocurrieron seguidos desde finales de marzo hasta finales de junio del 2014 y las consecuencias de dichos eventos todavía las vengo arrastrando. De esas cosas la única que me atrevo a contar en internet fue un accidente en la calle cuyos detalles físicos no detallaré para no hacerme el martir. Solo digamos que la medicina moderna y pagable evitó que saliera de ese golpe con marcas visibles permanentes. Pero como comenté en otra parte, de todas los golpes recibidos en ese período este fue el que menos me dolió, del que más rápido me recuperé y el que me dejó menos marcado. Hay heridas muy feas que las radiografias craneales no son capaces de revelar.

El resultado de esto y de otros incidentes previos fue que tuve que retrasar muchas cosas que estaba haciendo y cambiar por completo una serie de planes a largo plazo. No se si fue por el miedo que viví en esa primera mitad del año o por el golpe que recibí en la cabeza contra el pavimento pero quiero hacer algunas cosas que me había resistido a hacer desde hace ya muchos años. Por lo menos el golpe no me afectó la capacidad de programar y programar es lo que voy a hacer para salir de esta.

Y como dicen en las noticias, no daré detalles para no ‘entorpecer las investigaciones’ pero lo expresaré de modo que quienes me conocen y se que leen esto sepan que esperar. Y es que una de las consecuencias de esta caida fue la (afortunada) pérdida de oportunidad de que me vendieran barato. Como saben los trabajos relacionados con computadoras que se ofrecen en mi pueblo tienen muy poco que ver con programar y mucho con cuestiones sociales cuyos requisitos (incluso biológicos) no cumplo. Ahora estoy donde al principio y mi oportunidad de trabajar de modo independiente volvió a alejarse. Por suerte me salió otra oportunidad de subsistencia algo lejana pero mucho más digna que consiste en que me paguen por hacer algo legal pero que no me enorgullece y que tiene que ver con computadoras. No es mucho pero con las técnicas de supervivencia postapocalíptica entre las que se cuentan el Vulture y el Soylent Verde será más que suficiente para sobrevivir. Si bien ya había pensado en esto porque tenía pensado llevar esto del gamedev a cierto lugar pero al parecer no tengo “lo que se necesita” para poder entrar y el saber programar no me va a servir de nada. Además de que a ese lugar poco le interesa la programación.

No quiero que la imagen de mi que tengan quienes leen esto cambie. Me gusta que las cosas que obtengo sean gracias a mi propia fuerza y habilidad y no a la manera como le caigo a otras personas. Y pienso ir a cierto lugar en el que se dice necesitan de personajes como este que les escribe. Serán más de dos años de viaje y tendré que comenzar a preparar el terreno desde ahora. Y aquí es donde me pongo ambiguo y filosófico. Pues cierto asunto que deje pendiente decidirá donde terminará ese camino. Un final del camino al que debo de llegar ya convertido en otra cosa. Y aunque no lo crean esta página en la que escribo sin pensarlo me ayudó en esto. Pues para algunos ya soy alguien. Tal vez no sea muy impresionante un programador errante que le gusta el ensamblador pero a algunos les parecen interesantes mis aventuras. A veces pienso que a muchos de estos lectores les parece aburrida su vida apacible de trabajo y estudio y por eso me ven como un niño que va al circo mira a un acróbata o payaso hacer un acto peligroso. Pues al menos al lugar a donde pienso ir ya conocen las rutinas que puede hacer este payaso y no me han visto sin la pintura ni la nariz roja.

¿Qué sigue? Pues comenzar haciendo contactos en ese sitio para irme haciendo de prestigio, aunque me dicen que por lo menos mis escritos de ensamblador son bien conocidos y aprovechados ahí. No se como se llame eso pero se que me ayudará mucho en lo que quiero hacer. Por lo que voy a dedicarle más tiempo al blog porque ya lo estaba dejando morir. De momento continuaré con la serie sobre proyectos grandes pero intercalaré las entradas con cosas de ensamblador para principiantes, pues son las entradas que más se leen. Dejaré el trolleo a La Industria para cuando sean capaces de vivir de las ventas de sus propios juegos porque ya me da verguenza que me asocien con ellos. El resto del tiempo haré lo que hacen los programadores cuando no están programando y preparandome para recorrer ese camino que no se exactamente a donde me llevará. Tal vez me toque el final malo pero ya me preocuparé por eso cuando suceda. Mientras seguiré el consejo de la imagen y sonreiré mientras pueda hacerlo. Pues tal vez, o si no es que casi seguro, al final del camino me van a quedar muy pocos motivos sino es que dientes para poder hacerlo. Así que le dejaré toda la responsabilidad de ello a las probabilidades. ¡Ahora a programar!

agosto 16, 2014 Posted by | Uncategorized | Deja un comentario