@ agnasg

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)

Una decisión acertada por accidente

04-02-2019 1:31 PM

Programar un juego es una aventura en sí misma. Por ello puedo decir con toda la autoridad de mis años programando juegos que es un juego difícil de jugar. Hay sistemas que combinan múltiples interfases, pero los juegos las tienen todas: graficos, bases de datos, scripting, inteligencia artificial, redes, interpretadores, interfases de usuarios muy complicadas, y muchas otras cosas.

Por todo ello, los bugs son especialmente espeluznantes. Desconcertantes. A veces puedo tardar horas en resolverlos. Los he tenido de toda una tarde.

Pero… últimamente he estado muy acertado resolviendo bugs en khpx. Ayer apareció un bug al crear un reqNrew (requerimientos y recompensas) desde una misión, que hacía que el sistema olvidara la operación original en la misión (la operación puede ser agregar o actualizar). Resolverlo fue fácil porque simplemente tuve que agregar una variable para guardar este estatus. Bien interesante. El viernes otro bug pero esta vez en khpx, el sistema mostraba caracteres desordenados al presentar el inventario, claro como cada línea en una columna es un objeto era obvio que dos objetos estaba quedando en la misma posición. ¿Por qué? Un nombre puede ocupar más líneas que una descripción. Ups.

Lo que me lleva a responder cuándo voy a terminar khpx: cuando lo termine. Acabo de tener la brillante idea de que cuando un equipo armado  de penetración profunda en terreno enemigo entra en combate, la consola de la nave se transforma en una consola de combate. Estaba pensando en una fedeout/fadein (transición entre cónsolas) tipo persiana, una baja y la otra sube, y mientras escribía esto me dí cuenta que eso sería igual al sistema de worl of warcraff. No. Noo. Nooooo.

Pero en otro orden de ideas, Niko (irrlicht) acaba de twitear que el interés en la versión Mac y Linux de su próximo juego es menos del 1%. Afortunadamente ya yo había pensando en hacer khpx solamente para Windows. Ups, khpx está programado en DirectX que es Windows only. Ups, fue una decisión acertada por accidente.

Los juegos “nacen”

19-01-2019 7:42 AM

“Without insight into the process and without the perspective of work over time like this, games “just come out”, and when struggling with my own despair at the seemingly pointless slog of working on my own projects and the endless churn of not feeling like things are actually getting done, logs like this are a firm reminder that a result is a product of work multiplied by time. The time aspect can sometimes be forgotten, or imagined as some kind of hill that just needs to be climbed: I for one get the absurd idea that if only I worked more and harder the time could be traversed quicker, but all it winds up doing is bleed me dry, and the project as well.”

(“Sin comprender el proceso y sin la perspectiva del trabajo a lo largo del tiempo, los juegos “nacen”, y cuando lucho con mi propia desesperación ante la aparente inútil tarea de trabajar en mis propios proyectos y la interminable perturbación de no sentir que las cosas se están haciendo realmente,  registros como este son un firme recordatorio de que un resultado es un producto del trabajo multiplicado por el tiempo. El tiempo como elemento a veces se olvida, o se imagina como una especie de colina que sólo necesita ser escalada: Yo por lo menos tengo la absurda idea de que si trabajara más y más duro el tiempo podría ser atravesado más rápido, pero todo lo que termina haciendo es desangrarme, y desangrar al proyecto también.”)

De un hilo sobre el juego Obra Dinn