Esta es una serie de pensamientos sobre gamedev. Ver la anterior aquí.

1. Este post. El autor habla sobre el proceso de programar un juego completamente desde scratch, incluyendo string classes, rutinas de compresion, script parsing e inclusive la virtual machine. En los comentarios en reddit hay una interesante respuesta en relación al uso del tiempo: “I get up at about 4:30am and do an hour or so of work on my stuff before heading off to work. I have a family so evening are usually spent with them…” (“Me levanto a las 4:30 am y trabajo alrededor de una hora antes de salir a trabajar. Yo tengo una familia por lo que las noches se las dedico a ellos”. Yo hago lo mismo, y me resulta tortuoso ver lo ineficiente que soy, una hora nunca me ha alcanzado para nada. Me dolió mucho lo de “Yo tengo una familia”. Ouch, yo también, se lo que es eso, y lo que es el sacrificio doble de dedicarles tiempo y no dedicarles el tiempo que se merecen debido a mi manía de se un gamedev. Enlace.
2. Tengo varios años visitando 4chan.org/v/, el canal de video juegos de 4chan y todavía no he conseguido alguna información de utilidad. Usualmente no tengo idea de qué es lo están hablando, qué relación tienen las imágenes con lo que dicen, y la secuencia de los comentarios. Todavía no he visto algo que se pueda llamar una conversación, y la coherencia entre comentarios de un mismo hilo es nula.
3. Yo soy una persona honesta. Para mi Kickstarter es un préstamo. No es algo gratis que alguien me está dando, me están prestando dinero para hacer un juego, y ese dinero yo lo tengo que pagar con un producto. ¿Pero entonces de dónde sacas el dinero para hacer tu juego? Si pides un préstamo para hacer tu negocio eres un idiota. Hay demasiadas variables en juego para que le sumes la obligación de pagar el préstamo. Sobretodo si eres un procrastinador empedernido como yo. Uff. La respuesta es con inteligencia y trabajo. No hay alternativa.
4. Asheron Call estará disponible hasta el 31 de enero. Al parecer ya no estaba generando suficiente revenue para justificar el costo de los servidores (este es un señor que tiene 17 años jugando este juego, así que es uno de esos juegos que generan lealtad, y por lo que se lee en reddit al parecer así es) Me pregunto que tan costoso puede ser, porque los muds (por ejemplo batmud) tiene décadas funcionando con alguna contribución ocasional. Claro la exigencia de un juego como AC debe ser mayor que un mmo de texto, y para AC (no tengo idea) debe ser mucho más que 100 jugadores simultáneos. Pero de todas formas debería estar en el orden de miles de dólares cosa que se podría recaudar entre los jugadores dado el caso de que efectivamente son muchos. O más de 100. Y si la lealtad es tal, cuál podría ser el problema.
5. Esto es una historia de terror.  Los dueños de Playdead la compañía detrás de Limbo se pelearon y uno terminó comprando la parte del otro. Toda mi vida le he estado temiendo a este tipo de divorcios porque participé en múltiples empresas desde su fundación, y estas disputas son más comunes de lo que la gente se imagina. Y sí, son terribles, porque amistades son destruidas en el proceso. Una amiga y yo tratamos de montar una compañía para hacer páginas web. Nos peleamos decidiendo si usábamos su compañía o la mía, ya que ambos teníamos empresas de desarrollo creadas. Así que al menos en este caso la situación se resolvió sin problemas porque ni siquiera empezamos.
6. He estado usando este timer para medir cuánto tiempo efectivo uso en el proyecto. Mis cálculos indican que fueron alrededor de 600 horas el año pasado, pero no estoy ni remotamente seguro. Quiero hacer un seguimiento de esto este año. El punto es que es bien difícil detener el contador cada vez que me distraigo. Que es aproximadamente cada 5 minutos. Es bueno porque de esa forma puedo contabilizar con precisión mi nivel de distracción. Eso. Cada 5 minutos. Interesante. No sabía lo distraído que era, o al menos lo sospechaba pero no lo había cuantificado. Tengo problemas con el flow ultimamente.

1. Gamedev se refiere a game development, que se traduce en programación de juegos. Como cualquiera que esté dedicado a gamedev sabe, el inglés es tan omnipresente no solamente porque la mayoría de los foros están en inglés y porque toda la documentación está en este lenguaje, sino además porque las herramientas usan este lenguaje, y fueron desarrolladas originalmente en inglés. Finalmente, sacar al mercado un juego sin una versión multilenguage (que muestre textos, instrucciones y controles en inglés, además del español) es un suicidio de mercadeo. Así, tal como debes saber como programador (o si eres un buen programador que se ufana de serlo, como todos hacemos) el inglés no es necesidad, es obligatorio.
2. Estaba leyendo este comentario en reddit: “You also have to have a good grasp of project management and planing. If your game code and assets are a mess 30% into the development time, you will have a very hard time to keep the discipline and your progress will slow” (“Usted también tiene que tener una buena comprensión de la gestión del proyecto y el planeamiento. Si el código del juego y los recursos son un desastre al 30% en el tiempo de desarrollo, usted pasará un difícil rato para mantener la disciplina y su progreso va a ser lento”). Me llamó la atención la consecuencia de la falta de planeamiento: es difícil mantener la disciplina. Cualquiera que entre en el mundo de gamedev sabe que la gestión del proyecto es fundamental porque son demasiados componentes, demasiadas tareas (tasks) que hay que hacer, y si el juego es un mmo, o un juego que requiera 20+ horas para completarlo (desde el punto de vista del jugador), es casi imposible llevar el control y que las cosas no se desordenen. Y cualquiera en medio de un desorden pierde la calma, el desorden se incrementa exponencialmente y las cosas se salen de control. El desarrollo se hace lento y cosas pasan.
3. En la misma onda del comentario anterior: “Si el código del juego y los recursos son un desastre” ¿es posible evitar esto con planeamiento? Lo dudo. A menos que seas Niko, quien tiene en su haber 18 productos publicados, un motor gráfico, 2 juegos, etc. psyblast tiene pululando al menos 4 años en mi baúl de zombies y decir que el código es un desastre es al mismo tiempo injusto y una buena aproximación a la realidad. Yo soy 7/8 project manager (no certificado pero con al menos 30 proyectos de más de 200 horas) y escribo documentación para  psyblast cada vez que trabajo en él. El año pasado, 2016, me senté 96 veces a trabajar en el proyecto (implica 96 días diferentes, un 27% de los días del año si mi matemática es correcta) lo cual implicó al menos 300 horas de trabajo. Yo no sé ustedes pero 300 horas de trabajo es plata. Dinero. Enero de 2016 tuvo 18 entradas en mi bitácora, estamos a 6 de enero 2017 y ya llevo 4, así que me imagino que mantendré mi performance del año pasado. Sin embargo, a pesar de todo este tiempo, se puede leer en la bitácora cosas como lo siguiente: “Why CMmgr class instance is a member of CGui, m_mmgr?” (¿por qué una instancia de CMmgr es un miembro de la clase CGui? Debería ser un apuntador, o ambas clases deberían ser friend, no sé.
4. Por ejemplo. ¿Cómo están organizadas las clases en psyblast? Correcto. No están organizados. Alguna vez tenían un diseño Componente-Entidad, pero en este momento las clases están organizadas en grandes bloques de código super especializados CGui que maneja la interacción con el jugador, CMmgr que maneja los modelos pero también manipula el comportamiento de los npcs, CNpcInt que maneja la interacción de los npcs. En mi bitácora se lee por todas partes “tengo que corregir esto” porque en el fondo se que algo tengo que hacer para seguir las mejores prácticas, como aplicar diversos paradigmas según el caso, por ejemplo un enfoque Model-View-Controller. Pero, eso entra en contradicción con el tiempo de entrega, que debe mantenerse en “pronto”.
5. Lo cual me lleva a la lentitud del desarrollo que es algo tan difícil de explicar a alguien que no sabe nada de los intrilinguis de todo lo anterior, como explicármelo a mí. Me quedé atascado en julio pasado porque un boss se estaba desplegando mal en el juego, y podía ser por una multitud de razones, blender, el plugin que exporta el modelo, o que no estaba generando las animaciones correctamente, etc. Hace un par de días descubrí que la armature (el esqueleto) estaba rotado 90° en las X’s, y que algunos huesos tenían un roll diferente de 0°. Porqué no me dí cuenta de eso el año pasado que parece tan obvio es un misterio. Ayer el código que detecta que no hay obstáculos entre el player y un npc estaba fallando, y luego de una hora debugueando aquí y allá descubrí que en la llamada a la función cmgr->rayIntersect (start…) el start debe corresponder al npc no al player, de otra forma el resultado es cualquier cosa. ¿Qué tiene que ver esto con el planeamiento? Nada, resolver estos problemas toma tiempo, y no se puede planificar no tener estos problemas, hay que tener la disciplina para abordarlos y resolverlos sin ceder al impulso de tirar todo esto y llevar una vida divertida (pero vacía) sin el endemoniado gamedev. Por otro lado, ¿tener las clases mejor organizadas evitará estos problemas? Tampoco. ¿Y entonces? Ya lo dije, hay que tener paciencia y disciplina, el resto se deriva de aquí. Quizás mi mentalidad tropical juega en mi contra, es posible que Niko en bavaria quizás tiene los genes y el ambiente flemático que se requiere para mantener el ritmo en un proyecto que toma tiempo para completarse. Quizás.
6. La mentalidad tropical se caracteriza por la urgencia de resultados inmediatos ignorando los pasos que se requieren para completar una tarea. Como todo en la vida, hay que tener paciencia y disciplina. O, dicho de otra forma, quizás, como el campesino que tenía un caballo, un hijo y unos vecinos que se apresuraban a decir lo bueno de tener un caballo, lo malo de perder un caballo, lo bueno de recuperar el caballo, lo malo de que tu hijo se rompa una pierna montando el caballo, lo bueno de que como tu hijo se rompió una pierna ya no tiene que ir al ejército. Bueno. Malo. Quizás y quizás. No hay nada que pueda contra la paciencia y disciplina.

ESTE POST NO TIENE SPOILERS PERO HABLA DE SPOILERS

Con Rogue One me pasó lo mismo que con Titanic: alguien me dijo el final. En el caso de Titanic una señora que estaba en el asiento de atrás  comentó con alguien “Ay, Leonardo es tan bueno, lástima que su personaje muere al final de la película”. Con Rogue One fue igual de ridículo, ví un post de este sitio horrible llamado Taringa, con un título inocente y sin aviso ni protesto comenzaba por revelar el final de la película. Me de-suscribí de inmediato.

En realidad yo no tenía muchas expectativas.  Episodio 7 fue casi una decepción por los problemas que tiene la historia (sin mencionar que es casi idéntica a episodio 4). Así que fui al cine más por las obligación debido a mi afición a la saga que por la esperanza de que iba a ser una buena película. Teníamos la sala para nosotros solos (fuímos a una función a las 4 de la tarde un 22 de diciciembre) así que no había posibilidades de otras intromisiones.

Excelente. Divertida. Te mantiene agarrado del asiento las 2 horas. No hay un momento de respiro. A diferencia de las otras no hay ni un momento de reflexión, es sobre guerra, y la guerra rara vez tiene una presencia tan envolvente en la saga. Un excelente guión, sólidas actuaciones incluyendo la del personaje Tarkin, totalmente digital dado que el actor Peter Cushing murió en 1994, y que tiene un role vital en la película. Es fascinante como la historia desencadena en episodio 4, “una nueva esperanza“. Altamente recomendable.

Esto es obvio para cualquiera que tenga algún tiempo trabajando en computación y áreas conexas. También en el área administrativa de las empresas. Es tan obvio que me imagino que debe aparecer varias veces aquí y allá en este blog. Al menos me sorprendería si no es así. Tengo mucho trabajo como para ponerme a buscar.

La recompensa del trabajo es más trabajo. Lo que me lleva a pensar en la frase hay que trabajar para vivir y vivir para trabajar, los pescaditos de oro de Aureliano Buendía (vendía los pescaditos de oro por monedas de oro que fundía para hacer más pescaditos de oro), y el picapedrero de Kwai Chang Caine  (¿quién es el más poderoso, el picapedrero o el dueño de la montaña?), y muchas otras parábolas. Todas hablan sobre el mito alrededor del trabajo y para qué trabajamos. No me mal entiendan, yo me levanto a las 5am (4am hoy) y estoy trabajando hasta las 7pm (a veces hasta las 10pm) todos los días (incluyendo domingos), y si no tengo todas y cada una de mis neuronas al borde del agotamiento absoluto no me quedo tranquilo. Así que no estoy diciendo algo así como “si tienes ganas de trabajar, acuéstate a dormir y espera que se te pase” sino más bien, “acuérdate de por qué trabajas, porque puedes pasar toda tu vida haciéndolo por la razón equivocada”. Yo sé que hay personas que trabajan 50 años de 8-5, se recluyen en un hospicio y mueren sin jamás cuestionarse nada de esto, e inclusive me miran con lástima si me oyen mencionarlo, porque al cabo de cualquier discusión  estéril sobre el tema se llega a lo mismo: qué vas a hacer, la vida es así. Sí, yo he vivido ese camino, ahora pienso que no, la vida no tiene que ser así. O al menos me gustaría, en mi lecho de muerte, con una sonrisa mitad satisfacción, mitad alegría, tener mis pensamientos en paz con una vida llena de certidumbres sobre el qué, el por qué y el para qué.

No, no tengo respuestas definitivas a todo esto. Es diciembre, siempre tengo este tipo de pensamientos por esta época.