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 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:

[code language=”cpp”]
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;
}
} [/code]

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:

[code language=”cpp”]
QByteArray array = QString(source.c_str()).toLatin1();
strncpy ((char*)buffer, array.data(), source.length());
[/code]

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:

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

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.

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.

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”)

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.