@ agnasg

6 pensamientos sobre Gamedev antes del desayuno (3)

26-01-2017 11:41 AM

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

  1. Este comentador piensa que con 1000 horas invertidas en un gamedev se puede tener un release pequeño. Será un juego de pong para android porque cualquier cosa ligeramente más complicada requiere más tiempo. ¿Cuándo decidí dedicarme tiempo completo a psyblast? 2013. No sé los primeros 3 años pero el año pasado fueron alrededor de 600 horas así que puedo estimar alrededor de 2000 horas hasta hoy, sin incluir las 52 de este mes. ¿Cuánto falta? Ni idea y he decidido no preocuparme más de eso. Yo no voy para ninguna parte ni tengo planeado cambiar de idea. Cuando llegamos a este tipo de resoluciones somos mucho más felices. ¿No es la idea que persigamos la felicidad? Bueno, eso es lo que estoy haciendo.
  2. Algún ruido ha generado este video donde un desarrollador (YandereDev) se queja que la gente de twitch prohibió la difusión de videos de su juego Yandere Simulator (tiene su propio subreddit, y es regularmente popular, su video donde habla del juego tiene 1.4 m vistas). Efectivamente está en la corta lista de juegos prohibidos. ¿De qué se trata este juego? Como leemos en el about, es un juego sobre el acoso a un chico por parte de una inocente (en apariencia) colegiala y la eliminación de cualquier chica que pueda estar interesada en él.  (“stalking a boy and secretly eliminating any girl who seems interested in him, while maintaining the image of an innocent schoolgirl”). Incluye asesinato, suicidio, acoso y abuso a través de redes sociales, algo de desnudez y todo con el estilo anime. Yay! ¿Por qué lo habrán prohibido? Al fin y al cabo, Ayano Aishi, la protagonista, o “Yan-chan” como es conocida cariñosamente por sus compañeros de clase tiene un perfil tipo psicópata similar a Dexter, el asesino serial que tuvo durante años su propia serie de televisión.Varios subreddits tienen cientos de comentarios sobre el tema: /r/pcgamming, /r/gamming/r/videos, etc. Mi primera reacción a todo esto es que este desarrollador es un pervertido y quiere explotar con facilidad las oscuras perversiones de algunos jugadores (su fanbase es de alrededor de un millón de personas, una mezcla de pervertidos y a los que les gusta el anime, aunque caso creo que es lo mismo). Así que inicialmente deseché el tema por amarillista. Mi segunda reacción fue descargar el juego por motivos educacionales. Como desarrollador debo estar en contacto con lo bueno y lo malo, y aprender de primera mano lo que no se debe hacer, o lo que se debe explotar al máximo. Ya comentaré al respecto. O quizás no.
  3. ¿Que me hubiera gustado saber cuando comencé a programar juegos? (“What is one thing you wish you knew back when you started? “, enlace) a) No reinventar la rueda: dedicar más tiempo al juego en sí y menos a las herramientas. b) Mejor no hacerlo (no dedicarme a gamedev) porque las probabilidades de éxtio son 0.0001% (ver este artículo para descubrir el por qué). c) Olvidar cualquier pensamiento asociado al punto anterior porque un programador de juegos no sabe vivir sin hacerlo. La gran lección es que tu exposición a la suerte es algo que puedes manejar (The big lesson is that your exposure to luck is something you can manage (enlace))
  4. Esto (las diversas formas de manipular apundadores a funciones en C) no solamente existe sino que es una realidad que le dedicamos un tiempo infinito a jugar con las peculiaridades de nuestro lenguaje de programación en vez de dedicarnos a programar. Muchas veces estuve horas probando diversas formas de colocar llamadas a una función miembro de una clase en una tabla. En realidad se puede hacer cualquier cosa con apuntadores a funciones, con el suficiente tiempo para malgastar. Otra de las formas que utilizo con frecuencias para procrastinar.
  5. Hablando de procrastinar leo por todas partes gente que abandona su trabajo para dedicarse a freelancing, o para dedicarse al sueño de su vida pero es poco frecuente abandonar freelancing para dedicarse a otra cosa. ¿Es un agujero negro? Quizás. En vez de formas de procrastinar debería buscar estrategias para reducir las horas de freelancing. El año pasado hice un esfuerzo pero no fue suficiente. Estaba pensando que otra forma de calcular el tiempo que le dedico a psyblast es calcular la merma en mis ingresos en comparación a los años donde le dediqué poco tiempo a gamedev. En el caso del año pasado es considerable, pero se puede haber visto afectado por otros elementos. Tengo algunas estadísticas pero tienen demasiadas variables difíciles de cuantificar. No parece ser el camino.
  6. Me voy a desayunar, el café ya me sabe a los mismo que sabe la cerveza a las 3 de la mañana, y ya no me queda tiempo para seguir pensando en trabajar sino solamente en trabajar en sí. El tiempo es un esclavista.

6 pensamientos sobre Gamedev antes del desayuno (2)

17-01-2017 7:29 AM

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 gamedevEnlace.
  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.

6 pensamientos sobre Gamedev antes del desayuno (1)

06-01-2017 5:31 AM
  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.

Rogue One

27-12-2016 1:14 AM
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.

La recompensa del trabajo es más trabajo

24-12-2016 2:54 AM

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.

 

 

 

 

Buenas y malas noticias: Eve es gratis… o algo así

17-11-2016 12:23 PM

Como es reportado por todas partes salió la expansión de Eve Ascencion que entre cosas ofrece f2p para los jugadores, es decir, jugar gratis. En reddit la discusión fue intensa, pasando de “siempre he querido probarlo” a “luego de un par de semanas seguía sin tener idea de qué es lo que estaba haciendo”, y además “eve es un asco y CCP es una porquería” (CCP es la compañia detrás de Eve).

Las opiniones son mixtas: en realidad no es exactamente gratis, es prueba ilimitada, pero con limitaciones, porque no puedes comprar un battleship, y hay quienes dicen que justamente es con los battleships que el juego se pone divertido.

Yo lo estuve probando hace 3 ó 4 años, durante un par de semanas.

La buena noticia es que Eve tiene esta nueva modalidad de prueba gratis.

La mala noticia es que borré el juego el año pasado (7gb)

No, esa es una buena noticia también, todas son buenas noticias.

No confies demasiado en google… o en stackoverflow… o en nada

16-11-2016 4:58 AM

No sé cómo se llama el proceso mental que sufren algunos programadores (me incluyo, por supuesto) cuando, usualmente después de 10 horas de trabajo en un algoritmo, las cosas comienzan a ponerse bizarras y confusas. Me refiero a casos como el siguiente:

for (int i = 1;i <= 4; i++) {
    switch (i) {
    case 1: execute1 (); break;
    case 2: execute2 (); break;
    case 3: execute3 (); break;
    case 4: execute4 (); break;
    }
} 

El algoritmo comienza a complicarse y aparecen monstruos a veces inofensivos, a veces destructivos, definitivamente risibles.
Ayer estaba trabajando en un complicado sistema que se conecta a un webserver y devuelve información via https, pero con un nivel adicional de encriptación por seguridad (en este caso los usuarios del sistema son capaces de cualquier cosa, incluyendo lo imposible). Pues cuando todo parecía funcionar los códigos de retorno comenzaron a llegar con basura (en realidad todo el tiempo estaban llegando con basura pero yo no había llegado aún a ese punto)
Luego de una hora de debugguing llegué a este código:

QByteArray array = QString(source.c_str()).toLatin1();
strncpy ((char*)buffer, array.data(), source.length());

Recordé que días atrás estaba buscando la forma de pasar de QString a unsigned char * de una forma estándard ( o cómo dice la página de stackoverflow, a clean way) El googleo me llevó a esta página: http://stackoverflow.com/questions/17936160/clean-way-to-convert-qstring-to-char-not-const-char. Quizás lo que sea que estaba tratando de hacer en aquél momento funcionó porque el código de conversión utilizando QByteArray y toLatin1 permaneció ahí, mas no el argumento. Este código toma un std::string, lo convierte a QString y luego a unsigned char * (ups, strncpy no acepta en un compilador estricto unsigned char * así que hay que hacer un cast)

El resultado es que 0xc4 se transformaba en 0xffffffc4. Supongo que este código tenía sentido cuando originalmente era un QString, pero cuando el argumento pasó a ser un std::string, las cosas se volvieron, ofuscosas.

Para hacer el cuento largo corto el código defectuoso se transformó en:

for (int i = 0; i < source.length();i++) {
    buffer[i] = source[i] &amp; 0xff;
}

2 horas después. Gracias stackoverflow. O quizás gracias sindrome de la ofuscación del código después de 10 horas de trabajo.

De la mala documentación

08-11-2016 3:39 PM

Me refiero en el título a las documentación que no cumple su cometido: documentar. Estoy migrando Qt a 5.7 y encontré muchos de los problemas descritos aquí. ¿Quién es el autor de esta documentación? Yo.

Por ejemplo, “C2061: syntax error : identifier ‘__RPC__out_xcount_part’” es un terrible error que casi nadie en google (me refiero a internet) sabe cómo resolver. Pues mi solución de hace dos años fue “eliminar completamente el include de DirectX en el makefile”, pues rearreglar las variables INCLUDE no funciona.

“eliminar completamente el include de DirectX en el makefile”

“eliminar completamente el include de DirectX en el makefile”

¿Qué significa eso? ¿Cuál makefile, yo no veo el makefile? Claro afortunadamente todavía tengo la instalación de qt 5.2 y pude descubrir (recordar) que el error se presenta en “qtmultimedia/src/plugins/directshow”

Lo que pasa es que haciendo pruebas se hace realmente engorroso hacer un clean a una configuración porque el “nmake clean” no funciona como uno supone, y eso es necesario cada vez que cambiamos la configuración. Así que descubrí cómo hacer un “shadow build”, es decir, usar un directorio de trabajo diferente al que está junto con los sources. Para hacer eso hay que hacer los siguientes pasos:

Supongamos que qt está instalado en c:\qt

mkdir c:\qt-build # este es nuestro directorio de trabajo donde se compilará todo (donde están los makefile)

cd c:\qt-build       # entramos en el directorio

..\qt\configure -debug-and-release -opensource -confirm-license -platform win32-msvc2013 (otros flags)

Así que los makefile quedan en la estructura  c:\qt-build no dentro de c:\qt y por eso

“eliminar completamente el include de DirectX en el makefile”

no hace sentido si no sabes dónde están los makefile.

Un misterio que todavía no estoy seguro pueda resolver es de dónde salen los

-I”C:\Program Files (x86)\Microsoft DirectX SDK (February 2007)\include”

que aparecen en los makefile despues de hacer el configure, si:

  1. La variable INCLUDE no lo tiene
  2. La variable DXSDK_DIR está eliminada (anteriormente apuntaba al SDK de feb 2007

Es posible que la variable DXSDK_DIR sea la culpable, tendré que hacer más auditoría forense. Como quiera que sea estoy en el día 2 de la migración a 5.6 Correcto, 5.7 parece estar llena de problemas.

Debe haber pasión en ambos lados de la pantalla

11-10-2016 5:36 PM

Estaba leyendo estos comentarios de Emily Short sobre el juego Timecrest (solo en Apple)  y luego de diversas divagaciones dilatorias y digresionales aterricé en esta página donde algunos fanáticos discuten el juego (me refiero a que discuten sobre el juego Timecrest).

La discusión comienza con esto: “Yo he jugado Timecrest casi 100 veces en el curso de los últimos 10 meses” (“I have played through Timecrest 1 almost 100 times over the course of the past 10 months”)

keanu-woo

Woo!

¿100 veces? Yo no creo haber jugado jamás un juego más de 1 vez. Quizás Rogue (el roguelike, y eso por la permamuerte), o la aventura original (Colossal Cave), y eso porque, bueno, tú sabes, ¡es la aventura original!. Así que 100 veces es algo sorprendente. Quitando la exageración, (debe ser muchas veces, definitivamente más de 10 veces) esto denota fanatismo, algo de locura, y pasión. Con esto acabo de definir a un jugador “hardcore”, pero uno muy especial, donde la pasión sobresale. Pero eso no es suficiente, también debe haber pasión del otro lado de la pantalla, los programadores también deben ser apasionados sobre su trabajo para producir una obra de arte que haga que al menos un jugador, al menos uno, exagere diciendo que ha jugado el juego casi 100 veces. Eso es algo.

¿Qué debe tener un juego para que genere reacciones como esa? Es difícil porque funciona como esos conceptos subjetivos, por ejemplo la felicidad, cada quien tiene que buscar su propia manera de ser feliz, de la misma manera,  cada juego es especial en su propia manera, casi siempre de una forma única. El mencionado juego “la aventura original” es especial por presentar cierta mecánica de juego, ciertos puzzles que generan el momento “woo”. Me refiero no solamente a cuando resuelves el puzzle del pajarito, sino particularmente el puzzle del oso (el que tiene la cadena de oro). Es simple pero al menos para mi generó ese momento “woo”.

Y esa podría ser una segunda característica: es una experiencia particular de cada juego y particular de cada quien, lo que para mí fue un momento “woo” para otro puede resultar una tontería. Pero la opinión personal  “genera” el consenso general y así ese juego se convierte en especial.

Parte de la gracia se pierde cuando sabes resolver el problema (después de que sabes cómo parar un huevo, consideras el hacerlo como algo tonto, pero si no sabes como hacerlo constituye una prueba en contra de tu nivel de inteligencia) . Estaba viendo jugar a alguien y en algún momento se confrontó con uno de esos puzzles donde hay que alinear bloques de colores con una señal emitida por un totem, una señal, por supuesto, del mismo color. La persona se quedó maravillada con el mecanismo y me preguntó “¿como se te ocurrió eso?”. No le respondí, y me quedé disfrutando el “woo”.

Es posible pensar o creer que todas las ideas sobre puzzles de nivel “woo” (o momentos de nivel “woo”) ya han sido probadas, pero no necesariamente. Las posibilidades son infinitas. Pero hay que apasionarse en la búsqueda de esos momentos porque pueden saltar en el momento que menos te lo imaginas.

 

No se puede publicar un juego donde no se ven las huellas en la nieve

25-09-2016 10:31 AM

Hace años era un tema importante de dilucidar cuál motor gráfico utilizar. Había varios pero en la arena de software libre, gratis, C/C++ y con una buena comunidad dos buenas alternativas eran Ogre3d e Irrlicht. Finalmente yo escogí Irrlicht honestamente porque estaba programado de una forma similar a como yo programo por lo que me resultaba más familiar. La documentación me gustó y los demos también.

Hoy en día no existe ese tema, cualquier programador novato o experimentado debería escoger Unity. Quizás Unreal pero este último requiere una cantidad de esfuerzo y trabajo que resulta intimidante para alguien que lo que quiere es hacer un simple juego.  En la última semana estuve considerando seriamente migrar psyblast a Ogre3d. He llegado a un punto donde estoy requiriendo un motor gráfico más o menos actualizado y lamentablemente irrlicht está muy lejos de eso. Lo que me queda es comenzar a implementar los efectos del juego e irrlicht no me va a dar los resultados que estoy esperando. O dicho de otra forma, estoy en un punto en que o bien continúo con irrlicht y trato de implementar los efectos, o cambio de plataforma a una que ya tenga las herramientas para esto. Lo que me ha detenido todo este tiempo en hacer cambios en el desarrollo es el efecto Duke Nukem Forever. Cuentan que George Broussard se la pasaba importunando al equipo de desarrollo con nuevos requerimientos, y cuando vio un juego donde los personajes dejaban huellas en la nieve, dijo que definitivamente DNF tenía que incluir eso. Este tipo de requerimientos y otras decisiones llevaron a que DNF cambiara de engine (Quake II a Unreal) con el ya conocido atraso en su desarrollo (15 años). Enlace.

Ogre3d por supuesto no es mi única opción, pero es la que tengo más a la mano y no va a requerir el sobretrabajo que necesitaría por ejemplo  trabajar con Unreal. Además todavía estoy pensando en pequeños pasos. Nada grande. Y Unreal va a requerir demasiado trabajo y me va a alejar más del lanzamiento (a mi no me sirve Unity en lo absoluto porque internamente su desarrollo es un caos y porque es un producto propietario y cerrado)

Pero Ogre3d no es fácil, inclusive para un programador experimentado como yo. A continuación mis notas sobre el proceso de compilación y pruebas del engine. Descubrí visitando el sitio de ogre que ya está en 2.1 pero la versión estable es 1.9 Como no quiero hacer migraciones posteriores voy a trabajar directamente con 2.1, extrayendo los archivos del repositorio git.

Así que me fui al sitio de Ogre3d y comencé a instalar el paquete. Si usted sigue estas instrucciones no debería tener problemas. No haga como yo que comencé a instalar dando tumbos hasta que descubrí que estaba instalando la versión incorrecta.

NOTA: lo que sigue no es un tutorial de lo que se debe hacer. Aquí en forma anecdótica describo mis pasos que parecen más un capítulo de los 3 chiflados que otra cosa. Lea detenidamente el sitio de Ogre3d para entender cómo es el proceso antes de hacer algo.

Sin embargo estas notas pueden ser de utilidad porque incluyen instrucciones para resolver diferentes problemas, incluyendo el error “d3dcompiler_47.dll is misssing” que ocurre si usted está trabajando en Windows 7.

Para configurar el archivo de proyecto sln que utilizará Visual Studio para compilar el paquete, hay que usar cmake-gui y configurar apropiadamente. Van a aparecer dependencias faltantes. Yo me imagino que hay una forma correcta de hacer esto pero la desconozco (hay que leer los manuales, insólito) porque las veces que he usado cmake de alguna forma los makefile están listos y no hay que estar haciendo cirugía archivo por archivo. En mi caso tuve que ir a la carpeta ogre/CMake/Packages y editar los archivos FindOIS.cmakeFindFreetype.cmake y colocar donde están instalados estos paquetes.

Luego descubrí un Quick Start donde se explica cómo evitar todo esto que es por donde debí comenzar.

Luego de varios intentos y discusiones con el comando “set” de CMAKE, finalmente encontró los paquetes y comenzó a compilar.

El primer error fue el inefable  syntax error : identifier ‘__RPC__inout_xcount’  que he visto en innumerables ocasiones, y que se corrige colocando los headers de DirectX al final de los include en VC++Directories, en la configuración del proyecto de Visual Studio. Lamentablemente en este caso no fue tan fácil porque CMAKE agrega esta dependencia en otro sitio, en “Additional Includes” en la pestaña General. Finalmente eliminado de este sitio se resuelve el problema.

En resumen y para que quede claro, si tienes el SDK de DirectX lo debes colocar en Include files en VC++ Directories.

En mi caso este es el path:

C:\Program Files (x86)\Microsoft DirectX SDK (February 2007)\Include;

Teóricamente esto se resuelve Windows 8.1 porque ya vienen incluídos.

Luego de 15 minutos de compilación un nuevo error:

IID_IDirect3DSwapChain9Ex undefined

google está lleno de callejones sin salida así que tuve que deducir la solución yo mismo. Recórcholis. Afortunadamente mi primera presunción fue correcta y era el mismo problema, incompatibilidades con DX, así que se resuelve asegurándose que use la librería  dxguid.lib actualizada y no la de 2007.

Cuando tratas de ejecutar aparece un nuevo error, esta vez a tiempo de ejecución:

d3dcompiler_47.dll is misssing

Este es fácil, se puede encontrar aquí: %ProgramFiles(x86)%\Windows Kits\8.1\Redist\D3D\ en las dos versiones  x86 and x64.

Windows 7 y DX11 no se llevan bien así que hay que actualizar el windows con esta actualización KB2670838. Esto lo encontré en la documentación de ogre.

Resueltos todos estos problemas apareció el configurador de Ogre que te permite decidir cuál render usar (DX9, DX11 o Opengl). Escogí DX11 (yo amo el peligro) y recibí en respuesta una adorable pantalla negra. Me imaginé que después de todos los problemas con DX11 seguramente con DX9 debería funcionar pero entonces no aparecía el menu donde se selecciona eso. Luego de varias cavilaciones descubrí que hay una cosa llamada ogre.cfg donde se guarda la configuración ( lo cual si, cierto, tiene sentido, te pregunta una vez y la segunda vez no te pregunta, pero esto no toma en cuenta qué pasa si no funciona). El siguiente problema es dónde está ogre.cfg. En la carpeta donde está el ejecutable están los otros archivos de configuración plugins_d.cfgresources_d.cfg, samples_d.cfg pero no está el ogre.cfg.

Después de googlear sin cesar encontré en un sitio en las profundidades de internet un comentario sobre un comentario donde alguien de pasada indicaba que ogre.cfg está en  C:/Users/<user_name>/MyDocuments/Ogre/<Ogre version> que es efectivamente donde se guardan los archivos de configuración en Windows, pero ¿por qué entonces los otros archivos están donde está el ejecutable? ¿por que la documentación no indica esta ubicación? I don’t know

Pues bien borré el archivo ogre.cfg y ejecuté el programa de nuevo. Pude cambiar de DX11 a DX9 pero la pantalla negra hizo nuevamente su triunfal entrada (es posible editar ogre.cfg pero quería hacer la cosas como un usuario normal)

En la misma carpeta donde está el ogre.cfg está ogre.log que ya había visto de reojo antes así que revisé los últimos mensajes:

Cannot find an archive factory to deal with archive of type Zip

Mi goggleo para este problema terminó en innumerables páginas tipo dead end (callejones sin salida) como es usual:

http://ogre3d.org/forums/viewtopic.php?f=2&t=64684

http://ogre3d.org/forums/viewtopic.php?f=2&t=69048

http://www.ogre3d.org/forums/viewtopic.php?f=2&t=80852

Así que tuve que ponerme a pensar (que problema). Regresé al CMAKE y descubrí que se me había pasado un error, no encontraba el zlib que luce como el orígen del problema. Tuve que instalar zlib (está en http://www.zlib.net/) y compilar haciendo zlib nmake -f win32/Makefile.msc

Luego editar el  FindZLIB.cmake que se encuentra en ogre/CMake/Packages como en las ocasiones anteriores. Pero nuevos errores hicieron su aparición:

error LNK2019: unresolved external symbol “public: __thiscall Ogre::ZipArchive::ZipArchive

y una docena de errores similares. Un estudio rápido del código fuente me llevó a  OGRE_NO_ZIP_ARCHIVE  que es definida en include\OgreBuildSettings.h Como este define incluye algo así como una doble negación y el código está lleno de preguntas como esta:

#if OGRE_NO_ZIP_ARCHIVE == 0

lo cual es bien confuso porque si yo digo “Si Juan no vino de Barcelona entonces vamos a no ir” la mayoría de la gente va a responder con un “¿qué?”. Así que tuve que jugar con este define colocándole “1” y “0” a ver qué hacía.

En este punto analizando la salida de CMAKE me encontré con esta perla:

Configuring OGRE 1.10.0unstable

¿Por qué dice 1.10 si se supone que estoy configurando 2.1??

Mi consuelo es que no soy al único que le ha pasado, este usuario tuvo el mismo problema. El problema está relacionado a bitbucket, no veo una forma de hacer un enlace a la página de la versión 2.1, o quizás sí, la página debería ser esta https://bitbucket.org/sinbad/ogre/branch/v2-1, pero si haces clone aquí, no selecciona 2.1 sino el default, y cómo yo venía de la página de Ogre pensé que ya estaba en la página correcta, tal como funciona github. Al parecer es obligado bajar y usar el software recomendado por bitbucket Atlassian SourceTree, lo cual, por supuesto, no me gusta, ya tengo git no debería necesitar un producto propietario para bajar un software dominio público. Claro el dueño de bitbucket es Atlassian. El sospechoso usual. En definitiva el comando correcto es

hg clone https://bitbucket.org/sinbad/ogre/branch/v2-1

Conclusión

Dejando de lado mis peripecias al instalar no estoy en lo absoluto impresionado con Ogre3d. En realidad, si hay alguna forma en que un paquete puede indicarme claramente que no quiero utilizarlo es la forma como Ogre3d lo hace. Los demos son la peor selección que me puedo imaginar, no hay demos de sistema de partícula, demos de elementos básicos para programación de juegos, el tutorial sobre collision detection es desesperanzador (hay que implementar a nivel de rayIntersects) , en general la forma cómo está implementado no puede ser más diferente a la forma como yo pienso que se debe trabajar ( la cual no es ni correcta ni incorrecta, es simplemente diferente). En definitiva quedé tan defraudado con todo el esfuerzo involucrado que regresé a mi trabajo de investigación sobre Irrlicht y buscar la forma de migrar. Informaré sobre mis avances al respecto en las próximas semanas (ya tengo algunas ideas para un post sobre efectos HLSL y cómo se usan en Irrlicht).