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

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

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 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[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

CMPGPV: Como obtener los módulos de código

–¿Qué sucede? ¿Qué hacen? Los blancos se mueven–

En la entrada anterior vimos como podemos procesar un texto sencillo con la descripción del videojuego y obtener de él todas las estructuras de datos que necesitamos. Ahora veamos como obtener los módulos básicos que vamos a necesitar. En la etapa anterior recogimos todos los sustantivos y los usamos para determinar estructuras de datos (que mas adelante veremos como llenar) y en esta otra lo que veremos es que procedimientos o funciones básicas vamos a necesitar. Para esto vamos a retomar las descripciones de enunciados de alcance pero en lugar de sustantivos lo que vamos a extraer son los verbos.

De nuevo, para los que no recuerdan su educación básica los verbos son las palabras que indican acciones y que son muy importantes en programación. De hecho muchos lenguajes de programación están basados en el idioma inglés debido a su estructura imperativa que pocos otros idiomas tienen. Para que uno pueda obtener esa misma facilidad si habla un idioma como el español u otro de la misma familia la clave es pasar todos los verbos al infinitivo. Esto además evita ciertas ambiguedades hace las funciones mas fáciles de identificar en el código. En fin, ahora tomemos el enunciado de alcance del videojuego del ninja que nos presentó el ‘idea guy’:

Ancho = 1

Profundidad = 1

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

Los verbos en este enunciado son:

Cuenta

busca

viaja

sospecha

esconde

abre

lleva

descubrir

revivir

llevará

es

impedirlo

Si bien muchos de los verbos extraidos tienen mas que ver con la historia que con el propio gameplay programable otros nos muestran mucho de los que vamos a programar. “Cuenta” indica que necesitamos una funcionalidad capaz de contar la historia, e historia es una estructura definida en la entrada anterior. De ahi sacamos que necesitamos una función que cuente una historia que reciba la estructura historia y la cuente al jugador. Busca y viaja revelan que el juego puede ser un RPG de acción o un hack’n’slash de mundo abierto y que necesitamos 2 funciones que nos permitan buscar y viajar por un mundo. Sospecha puede ser descartado por ser parte de la historia pero ‘esconde’ indica que debemos programar algo que oculte al jefe ya sea que tengamos que implementar un sistema de pistas o simplemente colocarlo al final del camino que el jugador tiene que recorrer. ‘Abre’ muestra que necesitamos una función que permita ir avanzando por un mundo mientras cumplimos alguna acción. Ya sea encontrando pistas o venciendo enemigos. Para poder abrirnos camino necesitamos cumplir el requisito que es vencer a los enemigos que controlan y protegen los niveles y necesitamos 2 funciones capaces de detectar esa condición de protección de un área. “Lleva, descubrir y revivir” son otras 3 funciones encargadas de activar algo. En este caso pueden ser funciones que detecten cuando se ha llevado a cabo el ritual para revivir al ejército infernal. Esta funcion puede por ejemplo hacer que estatuas de monstruos que solo parecian ser parte del escenario se vuelvan personajes activos o que estos aparezcan para atacar al jugador. “Llevará, ser e impedirlo” son otras 3 funciones que muestran las condiciones de terminación del juego. Si el ninja logra detener la conspiración de revivir al ejército de demonios el juego se termina y se presenta el final feliz.

Hasta aquí no tenemos mucha idea de las funciones pero eso es porque estas no son funciones reales de esas que uno dice hazesto(con_estas_cosas); sino que son módulos. Un módulo no necesariamente es una función. Un módulo es una sección de código que tiene una función específica. No hay reglas en cuanto a qué tamaño puede tener un módulo pero existe un concepto llamado “puntos funcionales” que sirve para medirlos y que veremos mas adelante en esta serie. Por ahora lo que importa no es definir como se van a hacer las cosas. Pero si dejar claro que cosas son las que se van a hacer

Ahora bajemos al siguiente nivel de profundidad:


“…armado con sus espada y su gran agilidad…”

Ancho = 1

Profundidad = 2

“El ninja es capaz de estar de pie o correr sobre terreno o una plataforma, agacharse para esquivar ataques por arriba o atacar a enemigos que se arrastran. Saltar desde su lugar directo hacia arriba o mientras corre para pasar sobre abismos o subir a plataformas mas altas. El ninja puede saltar lo suficiente para pasar sobre un enemigo de su propia altura. Con su espada puede atacar hacia lo que tiene frente a él y puede usarla tanto si está de pie, agachado o a mitad de un salto para destruir enemigos voladores.”

Verbos:

estar

correr

agacharse

esquivar

arrastran

saltar

pasar

subir

puede

atacar

tener

usarla

estar

destruir

No voy a describir todos los verbos esta vez porque ya debieron entenderlo. Pero aquí las cosas se ponen mas claras. “Estar” en este caso indica que el ninja se encuentra en un lugar determinado. Los demás verbos como correr, agachar, saltar, atacar y destruir son acciones directas que puede llevar acabo el ninja. Otras son acciones o situaciones que pueden ser detectadas cuando ocurren como pasar o subir. En el caso de subir significa que hay un módulo capaz de detectar que el ninja saltó lo suficientemente alto como para aterrizar en una plataforma. Ahora pasemos al siguiente nivel de profundidad.


“El ninja es capaz de estar de pie o correr sobre terreno o una plataforma”

ancho = 1

profundidad = 3

“Para que la plataforma o el terreno sostengan al ninja este debe de tener los pies bien puestos sobre alguna de estas cosas. Si no es así el ninja caerá al vacio y a menos que sus pies toquen algo que lo sostenga morirá al pisar la parte inferior de la pantalla. Si el ninja se encuentra parado sobre el terreno o una plataforma puede correr, agacharse y saltar desde ahí y si a la mitad de una caida o un salto sus pies se acercan lo suficiente a una plataforma puede aterrizar sobre ella”
sostengan

debe

tiene

puestos

es

caerá

tocar

morirá

pisar

encuentra

parado

puede

correr

agacharse

saltar

acercan

aterrizar


Los verbos SER, HABER y ESTAR delatan código que prueba una condición

En este punto ya podríamos comenzar a programar algunos módulos que detecten situaciones como por ejemplo uno que detenga la caida del ninja si detecta que puso los pies sobre una plataforma si esta cayendo o saltando o que pongan en marcha una secuencia de eventos como el destruir a un enemigo si otro módulo detecta que está dentro del rango de ataque del ninja y ha sido golpeado con la espada. Como ya conocemos las estructuras de datos tenemos una idea como interactuan estas con los módulos. Pero todavía faltan dos cosas: Saber qué es lo que contienen las estructuras y qué datos de estas estructuras son procesados por los módulos.

Hay otro detalle en el análisis del enunciado de alcance relacionado con los verbos y es que si están en infinitivo, participio (terminados en -ado, -ido, -to, -so, y -cho) o gerundio(-ando, -iendo) indican diferentes cosas. Los verbos terminados en participio indican que el módulo lee el estado de un tipo de variable de estado conocida como bandera y los de gerundio que el módulo puede cambiar el estado de esas banderas. Los verbos en infinitivo se relacionan con módulos del tipo (iniciar/detener algo). En realidad en los videojuegos y muchas otras aplicaciones con importantes niveles de interactividad con el usuario hay muchos módulos dedicados a detectar determinadas condiciones y arrancar y detener procesos. Y en cuanto a lo de las banderas, una bandera es como un interruptor que indica si una condición se cumplió o no y con ello determinar si algo se va o no a hacer. La verdad es que los verbos en participio y gerundio se usan también para definir propiedades de alguna estructura. Otro punto muy importante es que los verbos “SER” y “Estar” son muy importantes. Casi siempre luego de estos 2 verbos viene un adjetivo o un verbo terminado en participio o gerundio. Por ejemplo en las expresiones “es invisible” o “está quemándose”. En este tipo de casos los módulos se limitan a probar una propiedad o campo dentro de una estructura y regresar un valor de verdad dependiendo de si la condición se cumple o no.

En la siguiente entrada veremos que hay otros dos análisis de palabras que nos permitirán definir las estructuras con detalle y determinar con seguridad qué módulos interactuan con cuales datos.

diciembre 30, 2013 Posted by | Uncategorized | Deja un comentario

CMPGPV: Como identificar las estructuras de datos

–¿Quién? ¿Qué? Los blancos toman forma —

En la entrada anterior vimos que como programadores podemos recibir una descripción del juego de manos del escritor y que existe un proceso para obtener entidades capaces de ser programadas. Lo primero que debemos definir son las estructuras de datos. Es muy importante definir las estructuras de datos desde el principio. Incluso antes que el código. Para los que ya no se acuerdan lo que es una estructura de datos se trata de una zona de la memoria donde guaradamos información sobre algo. Por ejemplo podemos tener una estructura que defina a un monstruo y que contenga su nombre, sus puntos de vida, su vida máxima, el daño que puede hacerle al héroe si lo alcanza y los puntos que da al ser vencido. Todos esos valores pueden guardarse en una zona de la memoria y ser actualizados por el código cuando sea necesario. Pues bien, ahora tomemos la descripción del juego del ninja que nos dio el escritor, agreguémosle algunos datos de encabezado e identifiquemos los adjetivos.

Enunciado de alcance

Ancho 1

Profundidad 1

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

Para los que no lo recuerdan los sustantivos son las palabras que describen entidades como personas, lugares, cosas y cualquiér cosa suceptible de ser descrita, hacer o recibir una acción. Aquí tenemos todo en una tabla

juego

historia

ninja

asesinato

padre

occidente

culpable

espada

agilidad

conocimientos

camino

lugares

ciudades

pandillas

selvas

fieras

templos

fanáticos

búsqueda

venganza

conspiración

demonio

ejército

humanidad

destrucción

ser

De momento estas serán las estructuras mas importantes. Si expandimos el enunciado de alcance a lo ancho obtendremos mas y si lo expandimos a lo profundo obtendremos mas información de estas. Otra cosa importante es aprender a distinguir sinónimos. O cuando palabras diferentes se refieran a lo mismo y marcarlas como si fueran una sola. Bueno, a partir de aquí ya podemos ver que hay sustantivos que describen la mecánica del juego y características del código. A primera vista podemos intuir que “historia” sugiere que necesitamos código que muestre una historia entre misiones ya sea como una animación o un simple texto con una imagen. “Ninja” describe al personaje principal manejado por el jugador, “asesinato” y “padre” pueden no ser importantes en el gameplay a menos que el escritor decida que van a aparecer de alguna manera en el juego, por ejemplo que mas adelante se revele que el padre está vivo o que regrese convertido en un ser de ultratumba. “Occidente” sugiere un tipo de escenario y “culpable” un enemigo poderoso al que hay que enfrentar. “Espada” es el arma principal. Y así seguimos con el resto de los sustantivos. Si ponemos atención estos describen cosas de manera muy general sin entrar en detalles. Por ejemplo el sustantivo “pandilleros” describe a todos los pandilleros a los que el ninja habrá de enfrentarse en la ciudad pero no deja claro como son, su modo de pelear o las armas que cargan. Esas cosas se definirán al extender el enunciado en profundidad. Extender el enunciado en ancho es tan sencillo como agregar mas descripción al final pero extenderlo en profundidad no es tan sencillo. Para extender el enunciado en profundida primero tenemos que seleccionar una parte del enunciado original y a partir de ahí extenderlo. De esta extensión van a brotar mas palabras que podemos procesar. Si bien hay que limitar la ampliación en ancho no es lo mismo en profundidad. Podemos ampliar un enunciado en profundida hasta que lleguemos a un nivel de detalle en que podamos describir dicha entidad en el lenguaje de programación que estemos usando. Como a mi me gusta programar en ensamblador voy a llegar a niveles mas profundos que los que usen otros lenguajes pero eso ya se verá a su tiempo.

Hagamos una pequeña extensión que defina los movimientos básicos del personaje. Tomemos la parte donde dice “Armado con su espada y su gran agilidad” y definamos los movimientos básicos del ninja.

“…armado con sus espada y su gran agilidad…”

Ancho 1

Profundidad 2

“El ninja es capaz de estar de pie o correr sobre terreno o una plataforma, agacharse para esquivar ataques por arriba o atacar a enemigos que se arrastran. Saltar desde su lugar directo hacia arriba o mientras corre para pasar sobre abismos o subir a plataformas mas altas. El ninja puede saltar lo suficiente para pasar sobre un enemigo de su propia altura. Con su espada puede atacar hacia lo que tiene frente a él y puede usarla tanto si está de pie, agachado o a mitad de un salto para destruir enemigos voladores.”

De esta nueva extensión podemos sacar mas sustantivos para determinar estructuras, omitiré los que ya salieron en la pasada anterior:

pie

terreno

plataforma

ataques

enemigos

lugar

abismos

altura

salto

Estos sustantivos nos dan idea de mas estructuras. Pie indica que necesitamos saber donde tiene los pies puestos el ninja, terreno indica el suelo firme que sostiene estos pies, plataforma una cosa que puede sostener a los personajes, ataques algo que puede efectuar el personaje, abismos algo que puede matarlo si cae en ellos, altura una estructura de datos con información que nos puede decir a que altura está el ninja y si está por encima o por debajo de un obstáculo y salto otra acción cuyos datos tienen que registrarse en su propia estructura.

Poco a poco esto comienza a parecer un sistema de reglas de un videojuego pero todavía no vemos algo que podamos poner en forma de código o por lo menos un conjunto de datos que podamos definir en formato de bytes, words, strings o flotantes. Ahora tomemos la parte de de “El ninja es capaz de estar de pie o correr sobre terreno o una plataforma…” y hagamos otra extensión de profundidad:


“El ninja es capaz de estar de pie o correr sobre terreno o una plataforma”

ancho 1

profundidad 3

“Para que la plataforma o el terreno sostengan al ninja este debe de tener los pies bien puestos sobre alguna de estas cosas. Si no es así el ninja caerá al vacio y a menos que sus pies toquen algo que lo sostenga morirá al pisar la parte inferior de la pantalla. Si el ninja se encuentra parado sobre el terreno o una plataforma puede correr, agacharse y saltar desde ahí y si a la mitad de una caida o un salto sus pies se acercan lo suficiente a una plataforma puede aterrizar sobre ella”

Aquí los sustantivos son:

plataforma

terreno

ninja

pies

cosas (alias de terreno y plataforma)

vacio

pantalla

caida

salto

En este nivel ya se tiene la suficiente información para comenzar a programar por lo menos la estructuras. Con esto ya pueden manejar los datos de un plataformas básico hecho en un engine 2D que ya tenga las funciones de plataformas predefinidas. Podríamos seguir expandiendo en profundidad para obtener mas detalles pero necesitamos analizar otro tipo de términos para conseguirlo. Noten que aquí vemos que hay diferencia entre caida y salto.

Pues bien, hasta aquí vimos como obtener estructuras de datos básicas a partir de un sencillo texto que describe el videojuego de forma muy general. Mas adelante veremos como definir sus elementos o atributos y como asociarlas con el código. En la siguiente entrada veremos como obtener los módulos de código básicos con un análisis de palabras similar.

diciembre 30, 2013 Posted by | Uncategorized | Deja un comentario

CMPGPV: Programador vs Idea Guy

Como convertir una idea en código fuente

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

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

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

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


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

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

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


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

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

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

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

diciembre 19, 2013 Posted by | Uncategorized | | Deja un comentario

CMPGPV: Sala de Situación

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

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

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

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

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

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

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

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

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

Ultimas advertencias

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

diciembre 18, 2013 Posted by | Uncategorized | | Deja un comentario