Programación en Lenguaje Ensamblador

-El Verdadero Lenguaje de las Máquinas-

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

  1. 25.000€ en USA es ser pobre? Joder, a eso en España, que no es de los países pobres de la UE le llamamos clase media. Estoy de acuerdo contigo, lo de los Indie se pasa ya de cara dura. No entiendo como juegos que deberían funcionar en mi GameBoy necesiten 2GB de RAM un Core2 Dúo y 500MB de disco y encima me vendan que los requisitos son muy bajos y que corren en cualquier PC… Al final cualquier juego Open Source alojado en los repositorios de todas las distrito cumplen mejor con las expectativas de jugabilidad, gráficos y requisitos para jugar… Ahí están Battle for Wesnoth, Open Arena, Superficie, SuperTux Kart… Y eso que muchos de ellos están programados en lenguajes de alto nivel… Si los hiciesen en C y ensamblador podrían correr en cualquier Pentium del 95.

    Comentarios por leperotero | marzo 6, 2017 | Responder

  2. Un juego digamos, como Battlefiel 4, si hubiera sido programado en ensamblador, ¿qué tanto mejoraría su rendimiento y peso?
    ¿Qué tanto cambiarían los requerimientos de hardware?
    ¿Si cambiarían de forma radical?

    Comentarios por Ismael Salas López | marzo 13, 2017 | Responder


Deja un comentario