@ agnasg

Enlaces de Junio 2018

30-06-2018 9:22 AM

Yo recorro los caminos de este país perseguido por mi sombra. A veces la sigo yo a ella, a veces me acompaña a la izquierda, o a la derecha. Excepto cuando está nublado, o de noche

— Wally Brando

  • Un año de C. Evitar el gamelote de C++ es algo que cada vez más gente reconoce como una ventaja. Como ya he dicho, mi último proyecto está hecho en C++ pero sin clases, que es mi intento de trabajar en C pero usando algunas bondades de C++ como el STL, y otras cosas. Como dice el artículo “Escribir clases de C++ a menudo implica escribir constructores, destructores, operadores de asignaciones y movimientos, a veces métodos de setter y getter… y así sucesivamente.” (“Writing C++ classes often involves writing constructors, destructors, assignment- and move-operators, sometimes setter- and getter-methods… and so on”). A eso lo llaman “Boilerplate Code” o código gamelote (sic)
  • Byteball se hace viral en la USB. Leyendo la página byteball.org encuentro esta perla “El algoritmo de consenso utilizado para proteger contra los gastos dobles se basa en el establecimiento de un orden total dentro del DAG. Esto se logra seleccionando una cadena, llamada cadena principal, que gravita hacia unidades emitidas por usuarios de reputación comúnmente reconocida – testigos. Consulte el documento técnico para obtener más detalles.” (“The consensus algorithm used to protect from double-spends is based on establishing a total order within the DAG. This is achieved by selecting a chain, called main chain, which gravitates towards units issued by commonly recognized reputable users — witnesses. See the white paper for details.”). Define “reputación comúnmente reconocida”. Está raro esto.
  • Un bug en MSVC 2017
  • Ya antes he hablado de Yandere Simulator y su peculiar programador conocido como Yanderedev. Este mes sacó uno de sus afamados videos (con alrededor de 1m de visualizaciones cada uno, alguien quien dice que esto le genera ingresos por arriba de los $5k que gana en el patreon). En esta ocasión sacó un video donde trata de responder a la pregunta ¿cuánto tarda hacer un video juego?. Digo trata porque opino que es una pregunta que no se puede responder. Tarda lo que tarda, básicamente es infinito porque uno nunca termina un video juego, simplemente lo abandona. El video viene a propósito del drama que se está viviendo en este momento en el subreddit del juego porque la gente se está impacientando y porque cuando la gente le pregunta cosas sobre los features del juego, Yanderedev responde de una forma realmente agresiva porque, bueno él también se está impacientando. Muchos dicen que desde hace mucho tiempo. En relación al mencionado video, mi opinión es que si necesitas argumentar todo eso, es porque el problema es mucho más grave de lo que la gente del subreddit piensa. La gente comienza a especular, como este redditor que dice que él realmente no quiere terminar el juego, sino que quiere ser famoso. Yo creo que eventualmente Yanderedev va a terminar el juego, pero algo que puede ayudar a ese objetivo es dejar el drama y los videos sobre el drama. Pero, el sucio dinero tiene un rol aquí, los videos y el drama le generan dinero. ¿Ven hacia dónde voy con esto? Money.
  • php es un ratoncito en comparación al tren cargado con elefantes llamado node.js en nivel de inutilidad sin sentido (php is a mouse compared to node.js’s train of elephants level of bloat nonsense). Esto es reddit siendo reddit: todo comenzó con una discusión sobre las políticas de reddit de eliminar silencionamente mensajes directos que contengan enlaces a ciertos sitios vetados por alguna razón (o por ninguna razón) y la discusión degeneró en ataques como el mencionado a esa inmensa pila de basura llamado Node.js. (Disclaimer: Node.js no es una inmensa pila de basura, lo que pasa es que quedaba muy bien en este párrafo)
  • Estoy seguro que ya lo he linkeado antes pero aquí está de nuevo: la cuenta github con todo el código fuente de id software, los creadores de Doom, Wolfenstein 3D y Quake. Reportado este mes, de nuevo, en reddit.
  • Un corto ensayo de Stephen King sobre los autores prolíficos. Parece haber una conclusión, o quizás no. “Poco es mejor” está sobrecalificado como una opinión. Si puedes escribir mucho, que bueno, pero la gente le va a prestar atención a tus libros uno por uno. De todas formas, según él, los autores prolíficos lo son, en forma inevitable. A mi lo que me gustó fue la anécdota de los señoras que no se tomaban el vino. Stephen es un escritor genial para crear imágenes provocativas.
  • Un dominó de 5 mm de alto y unos gramos de peso tumbando a un dominó de 50 kg. Tomado de 9gag. Interesante para reflexionar sobre las consecuencias de nuestras más insignificantes acciones. O como los grandes cambios comienzan por imperceptibles detalles. En los comentarios discuten que las analogías estúpidas nada significan, y que una demostración de un efecto físico nada tiene que ver con filosofía, psicología del comportamiento y otras menudencias. Cierto. Pero es cuando hacemos una analogía en la forma en que crece la levadura y la forma como nos impactan los cambios: el día anterior a cuando la levadura alcanza el 100% del tamaño esperado, tiene un tamaño de 50%. Es decir, el crecimiento es geométrico: así es el impacto de los cambios, al principio son imperceptibles, pero al final el impacto es total. Yo puedo esto de múltiples formas, pero la metáfora de la levadura es perfecta para explicarlo claramente: ¿me expliqué?
  • El principio de Peter dice que todos alcanzamos eventualmente nuestro nivel de incompetencia en una organización jerárquica. Este paper propone y discute estrategias para combatir este hecho comprobado incluyendo que se deben hacer nombramientos random o ascender al mejor y al peor candidato para aumentar la eficiencia. Esto resulta contra intuitivo por decir lo menos, y debería más bien ser sustituido por múltiples criterios (que es lo que usan las organizaciones actualmente), por ejemplo, competencia, desempeño, capacidad para conseguir los logros del equipo de trabajo, etc..
  • Interesante lectura sobre los avances de Blizzard con WOW Classic. Esta va a ser una versión de World of Warcraft similar a la que estaba disponible alrededor de 2005, un viejo deseo de la fanaticada de jugar la versión original del juego. Enlace.
  • En relación a la Copa Mundial de Futbol 2018: toda la selección de Islandia (Iceland)está formada por personas cuyo apellido termina en “son”: Halldorsson, Runarsson, Arnason, Skulason, Saevarsson, Ingason, Magnusson, Eyjolfsson, Sigurdsson, Gudmundsson, Bjarnason, Traustason, Hallfredsson, Sigurdsson, Skulason, Gislason, Fridjonsson, Gunnarsson. Si el porcentaje de la población cuyo apellido termina en “son” es tan alto ¿por qué siguen usando el “son”?
  • Una charla corta sobre Unit testing. Pregunta: ¿Por qué ciertos componentes (métodos estáticos de una clase) no se pueden testear? El orador: porque no se puede. Él explica porque no tiene “costuras”.  Algo asi como que no tiene por dónde agarrarlo. Mi solución: no uses algo que no puedes testear. Este sitio está lleno de videos sobre diversos tópicos de programación. Bien interesante de navegar.
  • Fortnite: Battle Royale es el juego con más ganancias en un mes que cualquier otro juego gratis. Ganó $318m en mayo. Según reporte en slashdot. ¿De dónde proviene esta ganancia? Vendiendo artículos no importantes como ropa y movimientos de baile. Cierto.
  • Interesante artículo en Gamasutra sobre algunas estadísticas de Steam: Se publican hoy en día 180 juegos con el nuevo sistema Steam Direct (más del doble que con el viejo sistema Greenlight). Hay opiniones como siempre en ambos sentido: es bueno (como dice Valve, porque facilita la publicación y los juegos consiguen su audiencia). Es malo: porque entre tanta maleza y monte, los humildes juegos indie se hacen invisibles. Como me dijo un amigo en facebook: las opiniones son como los traseros, cada quien tiene el suyo. Digo.

Toma de decisiones

28-06-2018 2:57 PM

Esto iba a ser un enlace en la lista de enlaces de junio, pero se fue extendiendo demasiado y se convirtió en un post. Mis discusiones de fin de mes se supone que deben ser breves reflexiones alrededor de algún post o suceso interesante, pero a veces cobran vida propia y se transforman en algo difícil de precisar. Algunos simplemente desaparecen y se convierten en nada, otros se transforman en un post, como este.

El enlace viene de gamasutra, A producer’s guide to decision-making (Guía del productor sobre la toma de decisiones).

El artículo hace un excepcional resumen de todo lo que viene alrededor de las malas y buenas decisiones y las consecuencias o beneficios que pueden ocasionar. Estuve envuelto en una de estas decisiones este mes, así que me vino como anillo al dedo el artículo. No porque yo tenga problema tomando decisiones, sino que como dice el artículo, no las debemos tomar tan a la ligera. Pienso que luego de sopesar correctamente los pro y contras no queda más remedio, hay que proceder y tomar la decisión que en nuestra opinión es la más apropiada.

Pero hay decisiones que debemos tomar casi con los ojos cerrados. Como un ciego en un gallinero. En mi luna miel, en mi otra vida, nos fuimos manejando hasta Mérida. Resulta ser que la via hacia Barinitas tiene un tramo de alrededor 100 kilómetros sin ningún tipo de señalización. Hasta que llegamos a la ciudad realmente yo no estaba seguro que era la via correcta. Ciertamente iba más o menos en el sentido correcto (sur-oeste) pero había momentos en que la carretera cruzaba hacia el oeste e inclusive hacia el noreste.

Muchas decisiones son así. No hay señalización. Tomas una decisión y solamente vas a saber el resultado cuando llegas a la meta, no antes. Ni siquiera hay una buena pista que te dé alguna orientación. Solamente tu intuición y sentido común te pueden ayudar.

En este mes mi plan era trabajar tiempo completo con las misiones  y diálogos de mi juego espacial, khpx. Todo estaba almacenado en estructuras C++, inicializadas a través de las nuevas funcionalidades de c++11, todo en un archivo llamado db_init.cpp. Luego un proceso se encargaba de guardar estas estructuras en tablas de sqlite para ser leidas por el juego a tiempo de ejecución. Cuando el juego pase a producción la base de datos sqlite será eliminada y un sistema de archivos altamente optimizado tomará su lugar. Se supone.

El punto es que con 10 misiones, 10 npcs, 10 items, 10 recompensas, las estructuras de c++ se convierten en un código escrito en sánscrito encriptado en antiguas claves macedónicas.

Algo tenía que hacer, y todo apuntaba en una dirección que yo conozco perfectamente: hacer un editor tipo GameMaker que maneje la data del juego, y la almacene en una base de datos para que la lea posteriormente el juego. El problema de este enfoque es que contradice todas las reglas que he venido aplicando hasta ahora con khpx: debe ser simple, rápido, y lo que sea que se haga debe facilitar y acelerar la publicación del juego: un editor de la data y metadata de los objetos del juego ni es simple, ni es fácil, y es una enorme desviación en el objetivo de publicar el juego.

El riesgo es  que implementar este sistema puede tardar semanas, más de un mes quizás, y no sabemos si eso va a funcionar o cómo va a afectar al juego y su publicación. Históricamente (me refiero a mis otros desarrollos, taisec y psyblast) me he perdido en interminables desarrollo de características en este tipo de editores, y para cuando ya está casi listo he perdido interés en el proyecto en sí.

Claro que ahí vienen los argumentos y contra argumentos: esto va a ayudar a largo plazo el desarrollo, organiza lo que a todas luces es algo de por sí complicado, de todas formas hay que hacerlo porque parte de estos datos deben ser accesibles por el jugador para consulta, como si fuera una enciclopedia.  Y es una mejor practica (best practices). Al fin y al cabo no hay que ser como el herrero que trabaja en su casa con cuchillo de palo, blah, blah, blah.

Desde taisec (mi primer juego, tipo aventura, nunca publicado) he estado haciendo este tipo de editores. Este es un screenshot de lo que yo llamaba scredit porque se suponía que iba a implementar un script para controlar las acciones del juego:

Y en psyblast (otro zombie del baul de los zombies) hice un superprocesador del documento maestro para pasar la info al juego, es decir, hice un mega GDD (de 60 páginas) con un lenguaje que un procesador interpreta, y extrae para pasarlo a una base de datos. Lo cual por supuesto, es una inmensa locura. ¿Cuánto tiempo estuve trabajando en eso? Semanas.

Y para khpx lo que tengo que hacer es el super definitivo editor de worldbuilding. Que puede tomar meses.

El plan es hacer un editor, al que llamo summa, implementado en Qt, es un visor/editor de la base de datos del juego. Es decir, al mismo tiempo sirve para el juego y se puede visualizar en forma de wiki desde otro programa. Genial. ¿Cuánto tiempo le he dedicado a esto en este momento? 2 semanas y el plan es terminar en una semana más.

Así luce la pantalla que se encarga de la información de los planetas:

Ya reportaré de nuevo en julio si llegué a Barinitas o me perdí.

Enlaces de Mayo

31-05-2018 6:28 PM
  • “Bizarro” no significa en español lo que significa en inglés. “Bizarro” en español significa “Que es valiente y, por lo general, apuesto.” Terrible. No sé qué palabra usar entonces porque me encuentro situaciones descabelladas, ridículas, absurdas y sin sentido todo el tiempo. No consigo otra palabra que suene igual y genere la misma emoción. Y no voy a estar diciendo “descabellado, ridículo, absurdo y sin sentido” cada vez que me encuentre con estas situaciones. ¡Esto es descabellado, ridículo, absurdo y sin sentido!
  • Ya mencioné en alguna parte (queda como ejercicio encontrar el post), que si hay vida extraterrestre, ya para este momento la deberíamos haber encontrado. O sus restos. O sus señales. O algo. Pero no hemos conseguido nada más allá de ciertas evidencias aquí en la tierra. Estaba viendo esta película El descubrimiento (The Discovery), y se me ocurrió que puede haber una conexión. No hemos encontrado señales de civilizaciones extraterrestres porque antes de que esas civilizaciones comiencen a hacerse notar, algo sucede, sistemáticamente. La nuestra no es una civilización muy avanzada, apenas estamos empezando a enviar señales al espacio desde hace unos 100 años. Eso significa que nos haremos notar o alguien nos va a detectar dentro de algunos cientos de años cuando nuestras señales lleguen a alguna civilización. Además está el detalle de que alguien pueda entender nuestras señales. Quizás hemos estado recibiendo señales de otras civilizaciones pero no las entendemos. Solamente una civilización lo suficientemente avanzada se va a hacer notar claramente. Pero esas civilizaciones al parecer no llegan a edad adulta. Algo les sucede, y puede ser lo mismo que nos va a suceder a nosotros. Por ejemplo: descubrimos que hay vida después de la vida: y si es así, entonces ¿para qué continuar con esta vida llena de sufrimiento, trabajo y desesperanza? De acuerdo a la mencionada película (El descubrimiento ) si la gente descubre que hay un más allá garantizado, optará por el suicidio sin pensarlo dos veces. Es descabellado, ridículo, absurdo y sin sentido pero podría ser un explicación. En cierto momento de la edad adulta de una civilización, descubren esto, y la civilización desaparece. Bizarr… coño, joder!
  • “El diseño es un proceso iterativo. El número necesario de iteraciones es uno más que el número que usted ha hecho actualmente. Esto es cierto en cualquier momento.” (Akin’s Laws of Spacecraft Design)
  • ¿Quién controla glibc? Un artículo sobre un elegante “lo hacemos así porque lo digo yo“.
  • De una forma silenciosa, casi sin que nadie se dé cuenta, Plutón vuelve a la categoría de planeta, por lo que nuestro sistema solar nuevamente tiene 9 planetas. Enlace. O quizás no. Wikipedia sólo menciona las decisiones de 2006-2008. No pregunten. O pregúntenle a Neil. Drayss.
  • La gente se está aburriendo de la IA (inteligencia artificial). De nuevo. “AI Winter Is Well On Its Way” (“El invierno de IA está en camino”). La gente quiere que IA haga algo que realmente no puede. Y hay gente de mercadeo que piensan que se van a ganar unos reales. Internet hace el resto.

Sólo enlaces de abril

29-04-2018 8:12 AM
  • Mi comunicación conmigo mismo siempre es efectiva cuando me presto atención.
  • Me entero que el grupo detrás de NetHack sigue trabajando, por lo que con gran júbilo y fanfarria anuncian el lanzamiento de la versión 3.6.1 (luego de 2 años) Yo solía jugar con devoción esta familia de juegos siendo rogue y Hack mis favoritos. Nethack nunca realmente me gustó por ciertas adiciones que lo hacen aburrido, o molesto por decir lo menos. Ahora leyendo la guía descubro que hay una opción para eliminar la mascota (una de las cosas que me molestaba, me parece que siempre está en el medio y me distrae del objetivo real del juego, además no creo que aporte algo). La mencionada opción (para eliminar a la mascota) es pettype=none se puede seleccionar a un gato o un perro, y si eres un caballero puedes seleccionar un caballo. Estas opciones se pueden colocar en un archivo de configuración (defaults.nh) y definir una variable OPTIONS, por ejemplo:
    OPTIONS = autopickup,pettype=none
  • ¿Cómo se hace para ganar un premio nobel? Difícil pregunta pero un buen comienzo es ser el mejor investigador en tu campo de experticia. ¿Cómo se hace para perder un premio nobel? Esto es mucho más fácil basta con ser deshonesto, lo cual, cada vez es más frecuente. Inclusive en la investigación científica. Yo no soy fanático de la cosmología pero como todo el mundo me pregunto qué estamos haciendo aquí. Al parecer la cosmología no trata de responder esa pregunta, sino de teorías sobre el universo, una de las cuales incluye una interpretación sobre la gravedad y lo que podemos deducir por simple observación. Si el que está viendo por un telescopio no es honesto sobre lo que realmente está viendo, cualquier cosa puede pasar, incluyendo confirmar una teoría en falso. Interesante lectura. Por ejemplo esta parte “we desperately tried to rip them off, but they weren’t that dumb.” (“tratamos de engañarlos, pero no fueron tan tontos”). Sorprendente. Creía que eso solamente lo hacían los políticos y los vendedores. Ya no. Qué ingenuo soy.
  • El número cromático del plano al parecer es 5. ¿Cuántos colores se necesitan para dibujar un mapa sin que dos regiones o estados o provincias adjacentes tengan el mismo color? Al parecer es 4, pero si extendemos eso a un grafo (esos dibujos con puntos y rayas que los unen), el número correcto es más 5 que 4. ¿Para qué sirve esto? Es importante para los matemáticos y computistas. Comentarios sobre el paper.
  • Si piensas que google traslate es bueno, prueba con https://www.deepl.com/translator. Hasta ahora lo he encontrado más preciso.
  • Yo tengo 3-4 gigas de código fuente en mi máquina de trabajo. Conseguir un código que desarrollé para resolver un problema es fundamental en mi trabajo de programación diario. El search files de windows a veces funciona, a veces no. He llegado a usar el grep de cygwin para tratar de atrapar el archivo que estoy buscando, igualmente con resultados mixtos (una efectividad de 50%). Esto es fatal para mi. Hay una nueva herramienta Search My files, que quizás ayude. La he estado probando igualmente con resultados mixtos. He pensado en desarrollar mi propia herramienta. Mientras tanto estoy comenzando a escribir un documento con una lista de código fuente relevante, y tengo una carpeta llamada stuff con ejemplos de código para resolver problemas típicos (como hacer una llamada AJAX en jquery con despliegue del ícono “waiting”, o cómo abrir un archivo en c++ usando STL, y leer las líneas fácilmente, etc) Y sin embargo la última vez que escribí un programa server/client usando UDP tuve más o menos que hacerlo desde scratch porque no ocnseguí mi programa anterior. Ups.

git, fossil, unit testing

14-04-2018 6:30 AM

Estaba leyendo este artículo de la gente de SQLite, sobre por qué ellos no usan git, y por un momento pensé que era una buena idea estudiar fossil, que es lo que ellos usan. Y cuando digo un momento me refiero a 5-10 segundos, porque fossil, como es de imaginar, tiene su propia curva de aprendizaje, que es como todas las curvas de aprendizaje, una curva, con una excentricidad pronunciada. Así que como estoy en una onda de dedicarme a la programación de juegos y no a las herramientas para “ayudar” a programar, abandoné la idea. Por cierto que khpx usa por lo pronto SQLite para guardar los datos. Yo he desarrollado varias bases de datos portátiles, pero SQLite es insuperable en términos de eficiencia y confiabilidad. Como quiera que sea, khpx continúa sin un sistema de versiones (version control).

Y eso es grave.

Yo usé git con uno de mis zombies (un juego al que le dediqué una considerable cantidad de tiempo y no he publicado) y nunca descubrí el genuino beneficio de usarlo, más allá de la obstinación con sus rarezas y excentricidades (sabía que esa palabra tenía otra acepción). Actualmente hago respaldos para cubrirme las espaldas (¿por qué decimos eso si solamente tenemos una espalda) en caso de una pérdida, pero también para hacer el backtracking que me permita descubrir la naturaleza y orígen de un bug. Y eso es horrible. Identificar cuándo comenzó a aparecer un bug puede ser complicado e inútil con un sistema de respaldo, e inclusive con un sistema de versiones. git (y me imagino que fossil) tiene mecanismo de ayuda, pero solamente si lo usas en forma adecuada. Y eso consume tiempo. Hay un compromiso entre el tiempo que le dedicas a la preparación para una recuperación de desastre (corregir un bug) y el tiempo que le dedicarías si no te preparas en lo absoluto y lo haces con fuerza bruta. O con tus neuronas.

Y hay bugs que van a requerir todas y cada una de tus neuronas.

El último de estos bugs me sucedió esta semana. El ciclo del rendering es la parte crucial de todo el game loop (“el lazo del juego” no traduce todos los intrilinguis de “game loop”) . Inadvertidamente coloqué una llamada en el lugar incorrecto, y ¡bang!, perdí 30fps en el proceso (khpx está en 62fps, el bug lo redujo a 30fps). Luego de pasar un par de horas con los respaldos era evidente que no lo iba a descubrir de esa forma. En posible que con el sistema de versiones tampoco. Así que tuve que pensar. Durante 5 minutos, completos, largos y difíciles de incertidumbre y temor. Lo resolví, pero ¿cómo pudo suceder? ¿cómo fue que no me di cuenta del problema? Porque no solamente no tengo control de versiones sino porque el sistema de pruebas es muy rudimentario.

¿Qué aprendí? Nada que no supiera de antemano, necesito un sistema de versiones, un sistema robusto de pruebas, no dejar pasar cosas obvias (estar pendiente de) como un impacto en los valores de desempeño del juego, por ejemplo los fps. Lo único que voy a hacer por ahora es mejorar todo el sistema alrededor del cálculo del fps (ahora se despliega el promedio) y colocar una alarma cuando este promedio está por debajo (en forma consistente) con el normal. git, fossil, unit testing, siguen en pendiente.

D es por dolor

22-03-2018 8:03 AM

Estaba viendo un mod de Super Mario que se llama P is for pain (reddit) así que lo usé como el nombre de este post dedicado a la programación de  juegos. La P también es por los Post morten de juegos, exitosos o no.  Post morten hay de sobra y ya he comentado varios anteriormente. 1000 copias vendidas son un fracaso para algunos, un éxito para otros. Para mi, terminar mi juego es el verdadero triunfo. Así que me estoy preparando para que el post morten de khpx (un juego ambientado en el espacio) exista al menos. ¿Y el dolor? Viene de múltiples fuentes. La más frecuente en este momento es el cambio de las estructuras de datos: ¿cómo definir la correcta estructura de datos para manejar todos los casos que a los escritores (yo mismo, yo solo) se les ocurra? ¿Debe haber una lista de servidores en cada planeta o una lista de servidores asociada al planeta? Ambos enfoques tienen un impacto directo en todas las rutinas que manejan los servidores. Creo que estoy dedicando el 50% o más del tiempo a modificar las estructuras cuando descubro que no son capaces de manejar correctamente lo que quiero implementar. O, a veces, la estructura es correcta pero está generando exceso de código y hay que hacerle modificaciones para mejorar el código asociado. Esto genera retrasos, nuevos bugs, frustración. Afortunadamente decidí no usar classes en este juego y los cambios son más fáciles de hacer.  O quizás no. No lo se.

¿Falta de planificación? Con toda seguridad. Estos problemas suelen resolverse con un buen diagrama que muestre las relaciones entre las estructuras. Pero mi experiencia es que ahora tengo dos problemas: ahora debo actualizar y modificar los diagramas y modificar los algoritmos que implementan las funciones/datos de los diagramas. Siempre me ha resultado doble trabajo. Es como aquél dicho “Tengo un problema, voy a usar Java para resolverlo.” Ahora tengo dos problemas. La adaptación a este caso sería “Las estructuras de datos no se adaptan a los requerimientos cambiantes del juego, voy a usar diagramas”. Ahora tengo dos problemas.

Volviendo a los post morten estaba leyendo este artículo sobre el creador de Stardew Valley, esta vez un caso exitoso (realmente exitoso, 3.5 millones de copias vendidas el primer año). Hay cosas que me llaman la atención en ese artículo, por ejemplo, que Barone, el programador, realmente no quería dedicarse a programar juegos (al menos profesionalmente). Y luego terminó trabajando durante 4.5 años 12 horas al día (el artículo está lleno de datos que no tienen sentido alrededor de esto y otras cosas, pero eso no es importante, la vida de un programador es incomprensible desde cualquier punto de vista). Como quiera que sea, me gustaría saber que se siente tener esas ambiguedades en la vida. Yo, a los 20 años, descubrí que me gustaba la programación y me he dedicado a eso toda mi vida. (claro, trabajé 16 años como vendedor de tecnología (Sun) pero eso fue por otra cosa, si quieres saber cuál cosa te voy a dar una pista: es la respuesta a 99 de cada 100 preguntas, está en el párrafo 1, página 1 de todo libro de ventas: sí, eso mismo: dinero).

También me llamó la atención (es de resaltar como dicen los políticos) detalles sobre la comezón del día a día del programador, por ejemplo esta perla: “Cada ajuste, de los cuales hubo miles, requirieron que él recargara el juego para refrescar  el código (“Each tweak, of which there were thousands, required him to reboot the game to refresh the game’s code“). “Refrescar el código” o reinicializar las variables y el estado del juego para estar seguro que todo funciona bien. Es una locura, es endemoniadamente repetitivo someterse a esto por el agotamiento que produce ver una y otra vez lo mismo en pantalla y tratar de devanar el cerebro pensando por qué funciona o por qué no. Lo cual me llevó a buscar estrategias, entre las cuales está el unit testing, que es una forma elegante de decir automatizar el testeo. Hay muchas posibilidades aquí, hay una librería altamente recomendable llamada Unit test cpp (UnitTest++), la cual por supuesto no uso ni voy a usar porque como buen inventor de la rueda no le veo sentido a usar una librería para implementar ES_IGUAL (algo, otra_cosa). Todo esto me llevó a considerar las razones por las cuales debería usar un lenguaje de scripting para acelerar el desarrollo (la idea es que al usar un lenguaje de scripting es más rapido implementar prototyping, nuevas características y modificarlas) pero también sirve para hacer pruebas. Yo odio Lua que es lo que todo el mundo suele usar en estos casos pero descubrí Wren que me luce más divertido (efectivamente en alguna parte de los manuales de Wren dice que a otros programadores en c++ les es raro usar Lua porque la sintaxis es diferente. Wren es  más del tipo c++). Claro que todo esto sería apartarse demasiado de mi objetivo de publicar kxpx, por lo que está de último en mi lista de cosas pendientes.

Pero lo que me llamó la atención del artículo (volviendo al artículo), la razón por la que lo menciono es por el proceso de Crear. Abandonar. Re-crear. ¿Suena conocido?

La programación de juegos es diferente

04-03-2018 12:16 PM

 

Esta discusión en r/gamedev es interesante (como la que estuve comentando en el post anterior). La discusión gira alrededor de este source code del juego Celeste. Es un archivo de la class Player (escrito en C#, buuu). Son 5500 lineas de if’s, else’s y variables para controlar el juego. He hecho un resumen de todas las posiciones, contradictorias entre si de los comentadores. La conclusión es que yo solo se que no se nada.

Le he agregado un  a aquellos puntos que en mi especializada opinión son los correctos.

 

  • Ninguna función debe exceder de 100 líneas y debe tener una sola responsabilidad. Ningún archivo debe exceder de 250.
  • Se debe utilizar algún programming pattern. Por ejemplo, en este caso sería ideal ECS (entity component system, o entidad-componente-sistema). Entonces las variables se colocan en componentes y el sistema maneja estos componentes.
  • Unity es un mal ejemplo para cualquier cosa.
  • Unity es un buen ejemplo para cualquier cosa.
  • Otro programming pattern interesante puede ser el observador, en donde cada componente envía mensajes y el objeto que debe recibirlo lo captura y lo usa. El resto de los objetos simplemente ignora los mensajes.
  • Utilizar mensajes para comunicación entre objetos es una pesadilla, porque en sistemas complejos es imposible saber lo que está pasando.
  • No se debe ser tan dogmático en relación a cómo programar, cada quien basado en su experiencia debe decidir qué es lo que funciona para él y qué no funciona.
  • Si el equipo de trabajo > 2 la situación cambia y se deben aplicar las mejores prácticas.
  • No hay nada malo con tener muchas variables privadas
  • No se deben tener muchas variables privadas, sino que todo se debe organizar en objetos (usar ECS, de nuevo)
  • El juego que utiliza esto ha sido un éxito, eso demuestra que un código desordenado y sin las mejores prácticas es irrelevante si funciona. Reviews en Steam.
  • No hace falta tener mejores prácticas, refactoring, etc. porque eso aplica en software que debe ser mantenido durante mucho tiempo. No es el caso de este juego. Si fuera un MMO, la situación sería diferente. Relevante xkcd 
  • No estoy de acuerdo con que esto es mal código. Yo no lo usaría para enseñanza, pero la complejidad justifica el estilo.
  • Esto es mal código. Por ejemplo hay un switch donde se selecciona cuál sonido usar dependiendo del valor de una variable. Eso debe estar en un arreglo. De esa forma al agregar/cambiar/eliminar un sonido, solo hay que hacerlo en un solo sitio.
  • Tener buen código es como un seguro: Si todo sale bien, no pasa nada. Si aparece un bug o hay que hacer un cambio, es mejor tenerlo que desear tenerlo.

Esto es relevante para mí últimamente porque estoy desarrollando activamente khpx, un juego espacial, y como ya he dicho en posts anteriones, no estoy usando classes sino  programación estilo C (archivos separados con variables globales) y el stl de c++. No cumple con la práctica de no usar variables globales, pero facilita y acelera el desarrollo (discutido en los posts anteriores).

Resumen febrero 2018

28-02-2018 11:34 AM
  • Estaba leyendo este post sobre hacer una “own engine (recuerdo una época en que leía los posts completos) y me puso a reflexionar, ¿estoy haciendo una engine propia para khpx? La respuesta corta es sí. Si  entramos  más en detalle, no exactamente. La respuesta completa estará en un futuro post sobre la tecnología detrás de khpx, pero baste decir por ahora que khpx está sólidamente basado en DirectX, que tiene respuesta a casi cualquier cosa que se requiera de un api gráfico. Esto deja por fuera cualquier posibilidad de migración a otras plataformas, pero qué me importa, hace tiempo dejé de preocuparme por la tecnología en sí y me dediqué a programar juegos (al menos las llamadas a DirectX están confinadas a rutinas xxx_render (), eso ayuda, ¿cierto?). En lo que al game engine en sí se refiere, es decir, la estructura que permite hacer el juego, es una amalgama de funciones estructuras alrededor del main-loop. No, no hay nada como esto (Godot engine) detrás de khpx (detrás y adelante de khpx está, khpx). No hay editores, ni Lua, plugins, ni flujo basado en nodos. Solo rutinas del juego: ¿no es eso lo que debe haber detrás de un juego?
  • Por cierto que en el mencionado post, aparece como uno de los principales errores que cometen los programadores de juegos generalizar demasiado temprano: es mejor copiar y pegar al ir desarrollando que abstraer las funciones principales y derivar de ellas  (” it’s better to default to copypasting it than to abstracting/generalizing it too early”). Nada puede ser más cierto. El post también menciona algo que yo estoy aplicando en khpx, ciertamente hay unas mejores prácticas de ingeniería de software pero están orientadas a software que va a ser compartido entre grandes grupos de trabajo o el público en general. Si eres un desarrollador solitario, algunas de estas prácticas no son necesarias. Por ejemplo, no hay problema en tener variables globales siempre que sean manejadas correctamente y estén confinadas a un archivo (salvo pocas excepciones). Esto acelera el desarrollo y garantiza hacer las cosas, aunque no sea de la forma más elegante.
  • Yo no sé cuántas horas paso sentado programando frente al computador. Con toda seguridad más de 10 horas diarias. Eso es destructivo para mis articulaciones. Por ello, y como un mecanismo anti-stress camino unos 40 minutos diarios, más breves interrupciones para estirar las piernas cada 45 mins. Encontré este artículo que dice que no solamente es suficiente caminar, también hay que usar a su máximo las articulaciones, de otra forma se interrumpe o se desmejora la creación del líquido sinovial, que es lo que mantiene lubricado las articulaciones. Una de las múltiples maneras de usar a su máximo las articulaciones es “agacharse”. Así que voy a incluir esto en mi rutina diaria ya que todavía no me decido a practicar yoga (donde se usan al extremo todas y cada una de las articulaciones). Debemos cuidar nuestra musculatura y huesos, al fin y al cabo, nuestros huesos no están hechos de acero, y por una razón.
  • Boom de YadaBoom de Yada . No me puedo sacar esta melodía de la cabeza. ¡Gracias reddit, gracias por nada!
  • Silenciosamente hice unos minúsculos cambios en el menú del lado izquierdo (the sidemenu). Eliminé enlaces a algunos temas que están en el olvido de post de años anteriores, y dejé los que son relevantes para mí en la actualidad. Ya yo no juego ficción interactiva pero leo detenidamente revisiones y comentarios en esa escena. Por ejemplo, este artículo de Gamasutra sobre sistemas de diálogos. Lo tenía guardado desde el año pasado y Emily Short me lo recordó.
  • nuklear, otra solución GUI totalmente independiente de la plataforma, 100% en un header desarrollado en C con 0% de dependencias, pequeño (~18kLOC), con características infinitas, fácil de usar con DirectX, opengl*, alegro, gdi, bindings para Lua, Java, Rust, C#, otros. Estuve una mañana examinando los fuentes y va a ser mi solución para ciertos menus de khpx, ya tengo desarrollado nativo en DX el despliegue de ventanas, botones, etc., pero otras cosas sofisticadas las haré en nuklear, entre otras razones por el look profesional y el buen acabado. Recomendado A+++++.

Cómo saber si estás enamorado, en una simple y fácil lección

22-02-2018 10:47 AM

Estoy tratando que ciertos detalles a los que nunca le presto atención, no se escapen esta vez en un pet proyect actual (khpx), incluyendo no tener externs inútiles en los archivos y que las funciones se llamen de una forma uniforme y consistente. Por ejemplo, ¿cómo se debe llamar la función de inicialización de los mapas, init_map () o map_init ()? Estoy descartando initMap () porque estoy dejando la notación Camel solamente para los nombres de las variables locales después del módulo: map_getTheCoordinates (), por ejemplo.

Pues pensaba que yo tenía alguna preferencia linguistica sobre el tema, volviendo a la controversia init_map () vs. map_init (), pero no, resulta ser que en los fuentes de umoria podemos encontrar store_init () y magic_init(), pero también init_signals(). Por otro lado en los de rogue se ve init_player(), init_colors(), init_materials (). Por su parte en doom, predomina InitSlidingDoorFrames (), InitData (), InitThinkers (), etc. Así que no, no hay alguna regla discernible por lo que voy a inventar una, me quedo con map_init (), khpx_init () y help_init (). De esa forma la búsqueda en los drop down menu de Visual studio aparecen ordenados por módulo y por función.

Toda esta atención y dedicación a khpx me resulta inusitada, debe ser que estoy enamorado. Porque eso es amor, eso es estar enamorado: cuando le dedicas el tiempo y tu esmero al objeto de tu amor. Fácil de deducir y entender.

4 horas de “trabajo”

14-02-2018 12:33 PM
¿Quieren ver como pierdo 4 horas de trabajo? Este bug:
CUSTOMVERTEX* pV;
for (i = 0; i < MAX_MODIFIED_OBJS; i++) { 
        pV = pVertices += i * 4; 
        pV++; 
        pV->Z = 2.1f;
        pV++; pV++;
        pV->Z = 2.1f;
}

En mi defensa, este bug estaba profundo en el sistema de update antes del final rendering. En khpx el código está extremadamente modulado, con funciones lo más compactas posible (que es como se debe programar) Eso trae como consecuencia el problema de que para conseguir un bug tienes que seguir la secuencia de funciones y un bug puede desaparecer aun cuando sea obvio, como el de arriba.

La idea de esa rutina es colocarle 2.1f a la coordenada “Z” de los objetos de tipo CUSTOMVERTEX con índice 1 y 3. Lamentablemente la variable pV tenía serios problemas al ser inicializada. MAX_MODIFIED_OBJS eran 6 objetos de tamaño sizeof (CUSTOMVERTEX) * 4. Esta rutina generaba la inicialización solamente de los objetos 1, 2 y 4 lo cual parecía algo tan bizarro como imposible. Adiós a 4 horas de productividad echadas a la basura. Que lástima.