Programación en Lenguaje Ensamblador

-El Verdadero Lenguaje de las Máquinas-

Modo Protegido 015: El Caso Yogome y La Industria de Videojuegos de México

No todos los que hacen juegos en México son estafadores. Muchos sólo son ineptos. Los buenos son pocos

 

Una empresa de videojuegos de México cae por los malos manejos de su CEO. No es la primera ni será la última. Cosas como esta son comunes en un ambiente donde un grupo decide quienes pueden hacer juegos y quienes no de modo arbitrario. Conozcan a “La Industria” y eviten crear algo así en sus paises

Descargar en MP3

octubre 5, 2018 Posted by | Uncategorized | Deja un comentario

Modo Protegido 014: Tu Consola de Videojuegos es una Computadora

–Y los videojuegos son programas de computadora que trabajan con numeritos–

¿Cómo juegas con un aparato diseñado para guardar números y hacer cálculos matemáticos con ellos? Este es el primer episodio dirigido a los que quieren aprender a programar videojuegos. Si no se aburren, puede que lo consigan.

Descargar en MP3

octubre 2, 2018 Posted by | Uncategorized | Deja un comentario

Modo Protegido 013: La Caida de Telltale Games

–Los Gringos también retocan botones de interfaces–

¿Qué mató Telltale games? ¿Contratar a gente que no hacia nada?¿Explotar a unos pocos que hacian todo? ¿O sus juegos sin gameplay basados en shows famosos? Esas cosas no mataron a Telltale. ¡De esas cosas vivia!

Descargar en MP3

septiembre 24, 2018 Posted by | Uncategorized | 1 comentario

Modo Protegido 012: Indies que se Cuelgan de Videojuegos Famosos

Cuando las ideas no valen ni 10 centavos la docena

Parte 1: Cuando indies que no saben programar quieren disimular su ineptitud dicendo que su juego es “retro”. Y encima se cuelgan de juegos famosos porque nadie jugaria sus propios juegos

Parte 2: ¿En qué se gastan tanto dinero los indies? Un indie reunió 3 millones de dólares en 2015 y a casi finales del 2018 su juego todavia no sale. ¿Pero por qué le perdonan tantas cosas a ese indie…? oh wait.

NOTA: El nuevo episodio del podcast tiene una miniatura engañosa. No habla nada de Kirby. Debí poner a Mega Man o a Samus. Pero Kirby era más fácil de hacer en plastilina

Descargar en MP3

septiembre 19, 2018 Posted by | Uncategorized | Deja un comentario

Modo Protegido 011: El Tercer Ratón

–El infierno que aguarda a los geeks y estrategias para escapar de él–

Parte 1: ¿Quién es el dueño de tu tiempo de vida?

Parte 2: Un famoso geek de internet tuvo un final muy triste. Espero con este audio evitar que a otros les pase lo mismo

Descargar en mp3

septiembre 14, 2018 Posted by | Uncategorized | Deja un comentario

Modo Protegido 010: Herramientas Juegomáticas

–Hacer videojuegos hoy es más fácil… por desgracia–

Hacer videojuegos hoy es más fácil con estas herramientas. Pero hacer juegos que no sean basura sigue siendo tan dificil como lo ha sido siempre.

Descarga el podcast en MP3 desde iVoox

septiembre 7, 2018 Posted by | Uncategorized | Deja un comentario

Modo Protegido 009: La Tribu de la Basura

–Falso buenismo y artistas desencantados–

Parte 1:
Hay entidades cuya mera visión es suficiente para causarle una crisis nerviosa a quienes no están preparados. Pero tales entidades son usadas por algo mas grande.

Parte 2:
Un evento local promete ayudar a artistas y creativos a ganarse la vida. ¿Pero ganarse la vida con un trabajo “artístico” es realmente lo que los artistas más jóvenes quieren?

septiembre 4, 2018 Posted by | Uncategorized | Deja un comentario

Modo Protegido 008: El Caballero Negro

-No es el héroe que quieren, pero si el que se merecen–

¿Así que ahora necesitan “héroes” que lo arriesguen todo y le den empleo de desarrollo de videojuegos a un montón de señoritos zoquetes?

Pues esto es lo que obtienen cuando le piden ayuda a la misma gente que menospreciaron tantas veces.

Versión en MP3

septiembre 1, 2018 Posted by | Uncategorized | 1 comentario

Modo Protegido 005: El Efecto Cobra

–El dinero no siempre es la solución–

Cuando se invierte dinero en resolver un problema, el problema se vuelve más grande. Apoyar con fondos el desarrollo de videojuegos hizo que hacerlos se volviera mucho más caro que antes cuando no habia apoyos de ningún tipo

Link del podcast de ivoox en MP3

septiembre 1, 2018 Posted by | Uncategorized | 1 comentario

Modo Protegido 007: Elitismo en los foros de Desarrollo de Videojuegos

–Los trolls no aparecen nada mas porque si–

Existen en internet comunidades creadas por gente que quiere aprender a hacer videojuegos. Pero en ellas hay mucho elitismo. Gente que se siente dios sin haber hecho un juego propio. Aqui menciono 3 tipos de elitista que he podido identificar.
Spoiler. Yo soy del Tipo 1

agosto 29, 2018 Posted by | Uncategorized | 2 comentarios

Modo Protegido: El Podcast…

…de un autoproclamado programador de videojuegos

Por la conjunción de una serie de pequeñas acciones que no parecian tener nada que ver entre si me metí en una situación digna de intro de un programa cómico. De comedia de humor negro para ser exacto. Pero para no hacer spoilers les diré que voy a hacer una serie de cosas paralelas al blog de ensamblador y al gamedev. Y la primera de ellas, y que ya está en funcionamiento es ni más ni menos que un podcast: Modo Protegido: El podcast de un autoproclamado programador de videojuegos.

logo_pm_cuadradoPara cuando esta nota suba a internet ya habrá al menos dos programas de unos cuarenta minutos cada uno mas pequeños pedazos de estos para facilitar la escucha a los adultos responsables que no tienen cuarenta minutos libres seguidos en un dia. ¿Y de qué trata? Pues a diferencia del intento anterior, este será un programa mucho menos técnico. No muy diferente a un monólogo con ínfulas de discurso. Y como reza el subtítulo. El tema principal será lo que he aprendido, vivido y presenciado en los años de ser un autoproclamado programador de videojuegos. ¿Pero por qué autoproclamado? Pues porque hubo un tiempo cuando el dolar estaba más caro en el que empresas de videojuegos del primer mundo vinieron a México a buscar mano de obra barata. Como mi plan nunca fue tropicalizar juegos de smartphone chino ya hechos sino hacer mis propios juegos para PC Master Race, pronto me vi superado en número por un enorme enjambre de mano de obra barata con la autoestima disparada que no dejaban de proclamar lo profesionales que eran porque les pagaban por “trabajar en la industria” y mirarme para abajo aunque para ello tuvieran que arquear la espalda como en el juego de limbo. Acusándome de que yo no era nadie porque ninguna empresa respetable me daria ese tipo de “oportunidades”. Con el tiempo, el cambio de moneda y gracias a la coronación del Emperador, amado por todos, ocurrida en 2016. La mayoría de esos profesionales fueron echados o deportados de regreso al tercer mundo y hoy se ganan la vida manejando bases de datos, dando clases por horas o los más afortunados sirviendo de reclamo para que algún “pimp” del desarrollo de videojuegos le baje dinero a algún burócrata incuauto que no sabe como administrar los fondos destinados a fomentar la tecnología en el pais.

Y esos profesionalísimos en su tiempo me decian que yo no merecía declararme a mi mismo como programador de videojuegos porque mi nombre no aparecia en los créditos de ningún videojuego famoso. O al menos eso era lo que… mejor no doy más spoilers.

Para acabar pronto, será un programa de opinión, anécdotas y experiencias relacionadas con la programación que he vivido a lo largo de muchos años. Y si la Policia del Pensamiento me lo permite, también habrá bastante trolleo. Más o menos lo mismo que se ve en esta página. Pero como escuchar un audio es mucho más cómodo y versatil que leer para la mayoría de los mortales tengo la esperanza de que podré llevar la palabra del ensamblador a más creyentes. Además de que producir un podcast de menos de una hora me cuesta mucho menos recursos que escribir una nota típica en esta página.

¡Pero vas a abandonar todo como lo haces siempre!

Casi puedo escucharlos pensar esto mientras leen estas lineas. Así que, conociendo mis propias debilidades, he tomado medidas y monté una infraestructura para producir audios con un mínimo de inconvenientes. Y a cambio de retrasar la compra de una nueva computadora un par de meses conseguí el equipo de grabación más barato que encontré en las tiendas de música de mi ciudad. Por lo menos ya no me escucharé como el Zeratul Español de los videos antiguos. Y combinado con el sistema actual de manejo de espacio del Centro de Operaciones que describiré en otra entrada, tal equipo está listo para grabar en cualquier momento. Aunque lo más prudente es pensar el tema antes de grabar.

En cuanto al resto de la edición, todo se hace por linea de comando con archivos de proceso por lotes. Así que puedo dejar la máquina trabajando sola mientras el podcast se “ensambla”. ¿O acaso se imaginan a alguien como yo editando audio en una Mac con software de edición profesional supercaro? Además, la estructura que el podcast tiene de momento es de tres partes. La principal o el “main” es un audio especialmente preparado para ese capítulo. Escrito antes de grabar para minimizar lo más posible los errores de dicción. La segunda es una entrada de esta misma página leida en voz alta y la última una sección en la que aunque no escribo todo lo que voy a decir discuto sobre pequeños temas para inflar el podcast. Con el tiempo iré integrando más secciones.

De momento hay un único problema: El producto es audio puro. Para colmo, se me ocurrió poner ese audio en ivoox donde se me limita mucho la distribución a menos que pague. Por lo que tuve que subir también los archivos a youtube para que le llegue a más gente. Y ahí es donde salíó el problema del audio. Tuve que convertir los archivos MP3 a MP4 porque no se permite subir archivos que no sean de video. Para ello tuve que improvisar un sistema de generación de imágenes con código. De hecho el logo y las pantallas con la descripción de los segmentos no fueron dibujadas en un editor gráfico sino generadas con código. Y para que se vieran lo más retro posible corrí código de BASIC en DosBox en una resolución de 320×200. ¿O acaso pensaron que hice ese dibujo en una Mac con Photoshop y tableta Wacom? Yo no, pero no duden que más de uno de los reputados profesionales de la industria que ya les describí si lo haría así.

Esto trae a colación otro tema: El podcast será parte de una prueba de una cierta herramienta que nunca terminé y que se supone que generaría este tipo de productos gráficos siempre tan necesitados por nosotros los programadores cuadrados y aburridos. Así que conforme vaya avanzando el podcast verán que los materiales gráficos irán evolucionando como lo hacen las máquinas. Porque esa es una de las consignas tanto del podcast como de otros productos: La producción debe de tener el mínimo de mano de obra humana que sea posible. No quiero que se me vaya todo el dia haciéndolos ni mucho menos tener que pagarle a alguien para que los haga por mi. Esto último al menos por ahora.

Así que sin más, y porque esta página es el producto con má tráfico de todos los que tengo. Aquí están los links al podcast

Podcast Modo Protegido en iVoox

Podcast Modo Protegido en YouTube

julio 30, 2018 Posted by | Uncategorized | 3 comentarios

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

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

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

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

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

SNOOZE: Ese botón que parece tan inutil

sno

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

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

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

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

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

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

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

junio 11, 2018 Posted by | Uncategorized | 3 comentarios

Regreso al Cementerio de los Sueños

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

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

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

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

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

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

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

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

 

junio 2, 2018 Posted by | Uncategorized | Deja un comentario

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

–Si no usas medidas reales inventa la tuya–

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

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

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

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

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

Los pixeles no son lineales

p_01

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

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

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

p_02

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

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

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

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

p_03

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

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

 

mayo 11, 2018 Posted by | Uncategorized | 2 comentarios

El mito del emprendedor que comenzó desde cero

–Cuando el perderlo todo no significa nada–

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

img01

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

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

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

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

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

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

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

¿Apuestas tu vida?

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

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

Y tú… ¿Apuestas tu vida?

febrero 17, 2018 Posted by | Uncategorized | Deja un comentario

Eficiencia del Software contra Eficiencia de Desarrollo

–¿Cual es más importante?–

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

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

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

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

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

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

Como vivir del software sin saber programar

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

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

¿Pero de donde salió el término “app”?

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

Y llegan las Bottled Web Apps

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

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

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

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

Nada es gratis.

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

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

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

octubre 30, 2017 Posted by | Uncategorized | , | 3 comentarios

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 | , , | 3 comentarios

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Actualización del caso: Marzo 1, 2017

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

marzo 1, 2017 Posted by | Uncategorized | 2 comentarios

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

–La Técnica del Escudo de Papel–

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

febrero 19, 2017 Posted by | programación | 3 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