@ agnasg

En el comienzo

06-09-2019 3:44 PM

Primer párrafo del mejor libro que nunca he leído: “En el comienzo el universo fue creado. Esto enfureció a mucha gente y ha sido considerado como un mal movimiento”.

El libro se llama “Hitchhiker’s Guide To The Galaxy”, así comienza el segundo libro “El restaurante al final del universo”, un libro que nunca he leído, y seguramente nunca leeré. Tengo en cola un par de libros de Kafka, 3 libros con cuentos de terror, y varios libros más.

Me preguntan qué significa ese comienzo.  Lo primero que hay que entender es que esa serie de libros son una parodia, o quizás un monumental chiste. Por ejemplo, en ese comienzo hay varios chistes. El primero es que todo el mundo esté en desacuerdo con la creación de universo. ¿quién le dio permiso a dios o a la entidad creadora (lo cual es central al libro) para crear al universo? ¿por qué? ¿fue sometido a votación? El otro chiste subyacente es que quién se va a oponer si antes de crear al universo no había nadie, la gente fue creada después del universo. Finalmente, en inglés se entiende mejor, “bad move” se refiere a cuando estás jugando ajedrez y haces una mala jugada. “la creación del universo” fue una mala jugada. Hay todo un sub-género de ciencia ficción sobre esto, de hecho “Prometheus” de Ridley Scott, explora esto profundamente. ¿cómo nos sentiríamos si confrontados con el creador descubriéramos que la creación fue parte de un juego, o una apuesta. O peor aun, un capricho, “lo hice porque podía hacerlo”. Douglas Addams el autor, tiene toda una visión cosmológica bien elaborada sobre el tema. De hecho, en “Hombres de Negro I” el final sugiere que todo nuestro universo está en una canica, y que hay unos extraterrestres jugando con ellas. Interesante.

Enlace en reddit,

De ser dadivosos

02-09-2019 7:48 AM

La vida es espléndida y nos regala una lluvia de amor y bendiciones todos los días. De niños repartimos ese esplendor dadivosos y llenos de alegría, derrochando y regalando nuestra energía por doquier. ¿Por qué, entonces, nos rompemos por dentro y somos tacaños untando el paté en las galletas para nosotros y los que amamos?

o

De niños conocemos a un nuevo vecino, o nos encontramos un nuevo compañero de clases en el recreo, y lo miramos con los ojos abiertos y le decimos “¿quieres que seamos amigos?” y nos abrazamos y somos mejores incondicionales amigos sin examinarlos ni cuestionarles nada. Pero de adultos miramos con recelo a los desconocidos y desenfundamos la pistola dispuestos a defendernos de cualquier amenaza imaginaria. ¿Por qué?

o

Llegamos a un trabajo nuevo y ayudamos decididamente a todo el mundo aun cuando nadie nos ayude, y llenos de entusiasmo emprendemos cualquier labor rápidamente como si de eso dependiera el éxito de la compañía, por insignificante que sea. Y luego perdemos el ánimo, perdemos el empuje, y desdeñamos todo y apenas sacamos la vista del periódico y despachamos a los nuevos con un aburrido ademán. ¿Por qué?

El guión de una entrevista a los actores, directores y productores de películas

19-08-2019 1:41 PM

Tengo algunas notas sobre películas que he visto recientemente pero en esta oportunidad no quiero hablar sobre películas en sí sino sobre la promoción de las mismas. Los actores (y también directores y productores) deben conceder entrevistas a los periodistas para promocionar las películas. ¿Cuántas entrevistas? Muchas. Deben ser interminables sesiones de entrevistas donde seguramente se repiten una y otra vez las preguntas. Para ejemplo, podemos recordar esas escenas en “Un lugar llamado Notting Hill” donde Hugh Grant, quien trataba de hablar con Julia Roberts es obligado a hacerle preguntas a los actores (“¿Cuál fue tu mejor experiencia hasta ahora?” – “Trabajar con Leonardo” – “¿Leonardo da Vinci?” – “Leonardo di Caprio”)

Una forma fácil de saber si una película te va a gustar o no es ver el trailer, pero mucho mejor es ver los análisis que hacen los periodistas dedicados al medio. Lo malo es cuando llegan a la parte de entrevistas y los actores comienzan a responder a las preguntas en forma mecánica y sin inspiración. Entiendo que hay que hacer amable en las entrevistas, pero llegar a la adulación forzada se hace bien pesado de ver.

A veces las preguntas no tienen mucha inspiración:

  • ¿Qué fue lo mejor de tu personaje?
  • ¿Qué te inspiró para la realización de tu personaje?
  • ¿Hay algo de ti en ese personaje? o el inefable: ¿Te identificas con tu personaje?

y rara vez son preguntas interesantes:

  • Jane Austen trató de representar la candidez de una época a través de sus personajes. ¿Crees que tu interpretación hace honor a ese genuino y siempre muy alabado esfuerzo?
  • ¿Por qué otra película de zombies?
  • ¿Sientes vergüenza de hacer un remake?

Pero lo más increíble de todo son los cliches que usan cuando se trata de hablar de sus compañeros en el set o del director:

  • “Es una persona bondadosa, generosa, su calurosa presencia siempre fue una inspiración”
  • “Él sacó cosas de mi que yo no sabía que tenía”
  • “Ella es graciosa, siempre tiene una palabra que me calmaba y me llenaba de entusiasmo”
  • “Él es el tipo de actor con el que siempre he querido trabajar. Yo andaba en la búsqueda de un actor que no fuese fácil de identificar con algún tipo de rol en particular. No me mal interpretes, sus películas han sido excelentes, pero no han tenido la publicidad que se merecen. Son el tipo de películas, que alguna vez yo quisiera hacer”

Claro, la alternativa es algo difícil de ver y los entrevistadores van a cortar cualquier desliz: “Fue horrible el set de grabación, es imposible trabajar con él”. Además, parece que hay un código de honor o algo por el estilo que obliga a actores y directores a adular a sus compañeros de trabajo, so pena de no ser llamados para la próxima película. Megan Fox tuvo problemas con Michael Bay, y fue despedida de inmediato. Christian Bale tiene fama de tener mal carácter y quizás por eso no continuó en Terminator. Y ya es sabido que hay actores que se niegan a conceder entrevistas, o que han tenido muy malas experiencias en las entrevistas.

Así que estamos destinados a ver siempre las mismas entrevistas con el mismo formato. En Hollywood rara vez hay sorpresas.

Las consecuencias a largo plazo del uso de OOP

22-07-2019 4:23 AM

“limitar el proyecto a C significa que las personas no van a arruinar las cosas con un ‘modelo de objeto’ idiota” (“limiting your project to C means that people don’t screw things up with any idiotic ‘object model’.”) — Linus Torvalds

Interesante artículo (“La programación orientada a objetos es un desastre de un trillón de dólares“) que desmitifica OOP y coloca el dedo en la llaga: “es imposible escribir código orientado a objeto que sea bueno y posible de mantener“. En mi serie de artículos sobre khpx (mi último juego todavía no publicado, en fase de postproducción) yo explico las razones por las cuales apenas uso una pizca de C++: no es solamente que la encapsulación, la abstracción y el uso de patrones de diseño genera código difícil de mantener e innecesariamente complejo, es que la belleza de C se pierde en una grandilocuencia inútil que no aporta nada. Como dice el artículo, OOP tenía como objetivo mejorar la organización del código. El resultado en cambio, es código incomprensible que oculta su función y lo hace oscuro e inaccesible. Los proyectos lucen muy bien cuando están comenzando, pero cuando se convierten en una codebase enorme, son una bomba de tiempo: “los cambios comienzan a retrasarse, nuevas versiones pierden los deadlines, y agregar nuevas características es casi imposible”. Mención y discusión en slashdot.

Una sonrisa forzada que no convence a nadie

21-06-2019 2:03 PM

Antes de entrar en materia, macronosis.com, mi compañía de desarrollo de sistemas, que he estado actualizando últimamente se dedica a web design, desarrollo de aplicaciones y productos de diversa índole. Tiene también una sección de mercado de trabajo/ freelance, para aquellos que quieren desligarse de las grandes corporaciones.

Wow Classic

Finalmente tenemos el wow original en betatesting. En los innumerables posts en bloglandia (syncaine por ejemplo, ver los enlaces para otros), se menciona principalmente lo divertido que es volver al pasado, con los niveles de dificultad al máximo, misiones repetitivas (mata 30 ratas) la ausencia de las herramientas para formar grupos, y la muerte como una compañera frecuente. Pero todos parecen coincidir que es divertido (y a veces aburrido, es difícil de entender) y que las soluciones que Blizzard aplicó para los problemas (principalmente después de wotlk) echaron a perder el juego. Aunque ciertamente me encantó burning crusade y wotlk, también me gustó mucho cataclismo, pandaria y draenor. Yo creo que Battle for Azeroth fue la hecatombe, pero eso solo es mi opinión.

Google Game Builder

Este es un sistema para crear juegos tipo minecraft. El juego funciona de inmediato sin tener que compilar y es multijugador todo el tiempo. Enlace. Discusión en hackernews.

Esto me recuerda cuando vi por primera vez que google había sacado otro navegador (chrome). Mi primer pensamiento fue, “¿qué? ¿para qué es esto? esta gente no tiene nada que hacer” así que esta vez voy a ser cauteloso.

Nota: Google Game Builder luce bien divertido.

twitter

Mi twitter como dice arriba en el encabezado es @agnasg. Yo paso por aquí por micronosis 1-2 veces al mes. Por mi twitter casi todos los días.

Ficción Interactiva

El género dentro de desarrollo de juegos que me gustaría cultivar más, inclusive tengo una sección en el sidebar (ficción interactiva). Esta vez me quedo estupefacto con el último post de Emily  Short donde presenta una lista de sitios, blogs, páginas web con info sobre narrativa orientada a juegos y escritura para juegos en general. Ojalá tuviera tiempo para tanta lectura (o un buen internet! 8|)

Formalización matemática

Este paper que apareció recientemente en hackernews pero que es de 2017, donde el autor aplica eigenvalores para demostrar que una aventura no tiene estados muertos (es decir que el juego se puede terminar, o que es posible llegar al final del juego, sin importar en qué estado se encuentre el juego). Me resultó entretenido aunque dudo que se pueda aplicar a cualquiera de los juegos de ficción interactiva con nivel de dificultad media. O a Zork.

… y ahora la sonrisa fingida,  que no pertenece al tractac.

Oh felicidad

Oh felicidad, dónde habías estado todos estos años
Oh felicidad, no me abandones nunca, nunca te vayas,
Oh felicidad, tú sabes que yo te extrañaba, a veces,
a veces ,te miraba por la ventana, hola te decía,
te decía, ven, pero ven ya.
Ven y abrázame  una vez más.

Tratando de domar una tormenta tropical

29-05-2019 11:52 AM

Yo soy un tomador de decisiones. También soy un tomador de whisky, pero eso es otra historia. Siempre me he ufanado de tomar las decisiones en el momento correcto, porque las decisiones, al igual que las oportunidades, tienen un componente temporal indispensable para su efectividad: una decisión tomada a des-tiempo, valga decir, en forma tardía, la mayoría de las veces es peor que ninguna decisión. Y yo soy el autor de la teoría de que pasamos la vida preparándonos para nuestro próximo error, así que potencialmente, nuestra próxima decisión puede ser también nuestro próximo error. Así que debemos ser cuidadosos, a pesar de que no tenemos mucho tiempo para serlo.  Pero no, no me considero pesimista per se, intrínsecamente yo soy optimista, pero reconozco la turbulencia en la que vivimos, que nos retuerce en una vorágine impredecible, estemos decididos o no.

Me perturba, no obstante, luego de mis 40 años de adultez, la sospecha de que mis decisiones han sido tan acertadas o tan equivocadas como si las hubiera tomado usando un dado.

Glass

05-05-2019 6:21 PM

La película de M. Night Shyamalan me permite reforzar las ideas que he estado meditando durante algún tiempo, que me permitieron formular las siguientes  3 teorías sobre su curiosa carrera como escritor y director :

  1. Luego de filmar Señales, M. Night Shyamalan fue secuestrado por unos aliens que llegaron a la tierra en una nave espacial proveniente de otra galaxia. Ellos se encuentran ahora disfrutando de sus películas, pues los alienígenas pensaron que era demasiado buen director y escritor para nosotros y se lo reservaron para ellos. Para que esto no fuera descubierto, los aliens colocaron a un facsímil, un impostor en su lugar, que resultó, por supuesto, un pésimo director.
  2. Todos, los 7 mil millones de habitantes de la tierra fuimos secuestrados por unos aliens que llegaron a la tierra en una nave espacial proveniente de otra galaxia. Solamente una persona no fue llevada por los aliens: M. Night Shyamalan. Para que él no se diera cuenta, los 7 mil millones de habitantes de la tierra fuimos sustituidos por unos facsímiles, por unos impostores. Pero el plan de los aliens fracasó. M. Night Shyamalan descubrió el secuestro. Como protesta, ahora el hace películas malas, con la esperanza de que los aliens cambien de parecer, y regresen a los habitantes de la tierra a su hogar.
  3. M. Night Shyamalan es un director y escritor malo, que hizo, en sus comienzos 2-3 buenas películas, debido a un fenómeno desconocido que es poco probable que sea descubierto, porque las mentes más brillantes de la tierra se encuentran ocupadas tratando de descubrir la cura del cáncer.

Teoría de conspiración extra: el tiempo se está moviendo al revés, en realidad estamos viendo estas películas en orden inverso, por ello primero vemos películas malas y al final su mejor película, Sexto Sentido.

Intimidad y autonomía

20-04-2019 2:55 AM

Leo alarmado en mi whatsapp:

“Podemos discutir hasta el infinitum sobre la naturaleza del problema y cada quien contribuirá certeza e incertidumbre, equilibrio y entropia. Como dice el libro “los hombres son de marte, las mujeres son de venus”, los hombres necesitamos el equilibrio correcto entre intimidad y autonomía, y en mi caso particular necesito al menos un  80% de autonomía y un 80% de intimidad. No quiero extenderme más en los detalles, pues en mi opinión, dicho en 2 platos, el meollo de la cuestión es que abultamos la importancia de nuestros problemas de la misma forma en que abusamos de los porcentajes”.

Por algo las mujeres dicen que todos los hombres son iguales.

Resoluciones

12-04-2019 7:28 AM

Ya he dicho anteriormente lo repetitivo que son algunas actividades/módulos en el desarrollo de juegos. El mejor ejemplo es el scripting, que permite configurar y en parte diseñar ciertos elementos del juego. Desde mi primer intento hace 20 años mi primera versión hice un programa que permitía configurar el comportamiento de los npcs, y modelar algunos aspectos del flujo de juegos (hablo sobre este sofisticado y complicado programa en este post, donde también hablo sobre la toma de decisiones involucrada). He hecho varias veces programas de scripting estilo Lua (cómo funciona en World of Warcraft), pero nunca he usado Lua en sí mismo, me he dedicado a reinventar la rueda una ya otra vez.

Otra actividad repetitiva es el sistema de manejo de npcs y sus diálogos: he hecho 3 versiones (entre ellas una que permite extraer los diálogos del documento de diseño del juego. Crazy). Y así sucesivamente repeticiones hasta el infinito: pero hay otra actividad/módulo que es también común a todos los juegos pero que ahora con khpx por primera vez realizo: el manejo de resoluciones. Todos los juegos deben adaptarse a la resolución que el sistema del jugador tenga, y debe hacerlo de una forma que permita que todo se vea más o menos igual. Hasta ahora es la primera que llego a esta etapa porque es la primera vez que hago un juego hasta tan avanzado nivel de completitud (mis zombies deambulan incompletos por ciudades en ruinas). Además siempre he usado irrlicht (el motor gráfico) quien se encarga de todo.

Hasta ahora como cualquier otro módulo es tan complicado como se puede imaginar, está unido con todo el juego (o al menos la la parte gráfica) y tiene esa característica que a veces resulta bien molesta que cuando acomodas una parte echas a perder la otra. Inicialmente traté de hacerlo lo más multifuncional posible y que luego lo pueda reutilizar para otros juegos. 2 meses después va a ser un milagro si funciona bien al menos para khpx.

Bugs

08-02-2019 9:18 AM

En el post anterior el tema de los bugs quedó sin mucha explicación, y dado que he hablado poco de ellos, más allá de una que otra queja, este post es entonces un post sobre bugs.

Para los pocos que no lo saben, los programadores llamamos bugs a las fallas en los programas. El nombre (bug es insecto en inglés) viene dado por razones históricas. En los albores de la computación los equipos fallaban por insectos que se introducían en los antiguos circuitos y tubos que lo formaban, en una época en que nadie soñaba con los circuitos integrados, chips y otras tecnologías modernas.

Todo el tema de programación orientada a objetos (oop), clases, encapsulamiento, cero variables globales, las metodologías de software engineering  y otras ideas son mecanismos para evitar los bugs y otras alimañas que hacen que los programas no funcionen. Los resultados son mixtos.

Mi último juego, khpx, está implementado utilizando una idea descabellada: nada de clases, nada de encapsulamiento, y cientos de variables globales para mantener el estado del juego. Luego de programar decenas de aplicaciones y juegos en C++ y su parafernalia, llegué a la conclusión de que hay que usar C++ por las razones correctas, no necesariamente para evitar los bugs, pues C++ tiene un costo. Un programa en C++ es 50% más voluminoso y complejo que su equivalente en C.

No tengo una estadística que sustente ese 50%, puede ser 20% o 100%. El punto es el siguiente: ¿cuál programa tiene más probabilidad de tener bugs, uno de 1000 líneas o uno de 100? Algunos programadores sesudos argumentarán que los bugs blah, blah, blah y blah. En realidad la probabilidad de un bug no es directamente proporcional a nada, porque los bugs se rigen por la ley de Murphy, por lo que ambos programas, el de 1000 líneas y el de 100 líneas pueden tener bugs, o puede que no lo tengan. Y si ese es el caso, entonces ¿por qué voy a pasar el trabajo de escribir un programa de 1000 líneas, y la desventaja de tener que entenderlo y darle mantenimiento, en lugar de un programa de 100 líneas que con una mirada rápida puede revelar sus misterios rápidamente?

Mi respuesta es no, no tienes que pasar trabajo. Claro que hay unos beneficios adicionales de la programación orientada a objetos (oop): el código queda más organizado, se supone que es más fácil de entender para el grupo de trabajo, es más fácil de mantener. Puesto que soy un lobo estepario (un programador solo)  esos beneficios no existen o al menos estoy hastiado del costo involucrado. Y para ello, baste mencionar como ejemplo el bug que tuve esta semana que involucró 12 horas de pesquisa y trabajo detectivesco para su solución (sí, en el post anterior decía que yo estaba muy sagaz resolviendo bugs, famosas últimas palabras, horas después apareció uno que me callaría la boca).

khpx está implementado con unos arreglos que guardan la información de los sprites. Hay un arreglo g_spr_obj_tbl que guarda los objetos que no requieren modificar el vertex buffer, g_modified_spr_obj_tbl guarda los objetos que lo requieren. Modificar el vertex buffer significa hacer la llamada Lock (), modificar los vértices de los meshes (estoy hablando en términos de DirectX) y Unlock () para terminar las modificaciones.

El punto es que esta semana estuve implementando el fadein/fadeout de la cónsola que muestra los datos de los sensores y controles de la nave, y cuando agregué los objetos para manejar los sensores y controles correspondientes a una batalla, comenzaron a suceder cosas inesperadas: él nuevo sprite perdía su posición en la pantalla y su su tamaño (scale). Era claro que cuando estaba de último en el arreglo fallaba, cuando lo movía a la posición penúltima funcionaba. 12 horas después y luego de revisar el codigo decenas de veces descubrí que el objeto que muestra la posición del scroll en los listados (SCROLL_BAR) estaba mal inicializado, debía estar en el arreglo de los objetos que no modifican el vertex buffer (g_spr_obj_tbl) y en cambio estaba en g_modified_spr_obj_tbl. El índice de este objeto está indicado con un define SCROLL_BAR cuyo valor es 10, que casualmente corresponde al último índice en g_modified_spr_obj_tbl. Esto producía un cambio en cualquiera que fuera el objeto que estuviera en esa posición, que resultó ser el nuevo sprite que yo estaba insertando esta semana.

Este bug me recordó mis proyectos usando oop, porque parece el tipo de bugs que sucede con frecuencia en ese tipo de proyectos. De hecho, en todo el tiempo que tengo programando khpx (un año) primera vez que sucede algo así. El encapsulamiento de la data persigue que este tipo de fallas no ocurran, pero todo depende de que coloques la data en la variable correcta. Si te equivocas de variable, el bug sucede, con o sin oop.

Claro que una alternativa a arreglos e índices son los containers, std::vector por ejemplo, y su iterator’s. El uso de índices y arreglos son peligrosos, o al menos deben ser utilizados con suma precaución. Hay ocasiones que requieres usar ciertos objetos por nombre y apellido, por ejemplo un sprite, y su uso incorrecto afecta todo el sistema. Si revisas el código de Doom (el juego de Id Software los creadores de Quake) está llenos de arreglos, y de accesos por índice. No hay ningún mecanismo especial para evitar este tipo de bugs, más allá de un programador alerta.

Hay múltiples moralejas, y hay múltiples formas de decirlo, pero una de las que más me gusta, está en este libro “Essential C” de Nick Parlante: ” The C programming model is that the programmer knows exactly what they want to do and how to use the language constructs to achieve that goal. The language lets the expert programmer express what they want in the minimum time by staying out of their way” (“El modelo de programación en C es que el programador sabe exactamente lo que quiere hacer y cómo usar las construcciones del lenguaje para lograr esa meta. El lenguaje permite que el programador experto exprese lo que quiere en el mínimo tiempo, manteniéndose fuera de su camino”). El lenguaje C es una herramienta que ayuda a resolver problemas, en múltiples formas, pero principalmente no estorbando. Y eso es realmente una gran ayuda.

Aclaratoria: como está dicho en los posts anteriores khpx, está programado en C++ pero utilizando al mínimo los paradigmas oop. Es prácticamente C pero con el STL. Utilizo intensamente los containers std::vector y std::map lo cual garantiza un código robusto y simple (y por añadidura el mínimo uso de arreglos, pero al parecer, no lo suficiente)