Ala, un saludo a todo el mundo.

Así que a partir de julio empezaré a retomar el blog un poco para comentar algunas de las cosas que he ido aprendiendo últimamente. También querría comentar a modo de post-mortem como ha sido la experiencia de realizar el master y sobre todo el proyecto en el que he participado, del cual espero poder hablar durante el verano poco a poco, porque hay mucho que contar. Que por cierto es gracioso que hace tiempo intenté aprender Ogre con muy poco éxito y el proyecto que estamos realizando está montado sobre dicho motor gráfico, así que para bien o para mal al final he aprendido a utilizarlo y bueno… puedo decir que más o menos es un motor aceptable, aunque hay algunas zonas oscuras que no disponen de una documentación muy clara, pero qué se le va a hacer. En fin, mientras tanto a programar hasta el fallo el proyecto hasta julio… xD

typedef struct _GenericData {
    int type;
    void * data;
} GenericData;

No es el fin del mundo, ni mucho menos, pero luego llega el típico include con una lista de #define para recoger todos los posibles tipos de información, reunidos en un solo fichero para evitar equivocarnos y poner como identificador de tipo a dos estructuras distintas el mismo entero. El problema de esto, es que al añadir un nuevo identificador, a recompilar todos los .c que lo incluían. La vida así no es especialmente cómoda, la verdad. Y no es especialmente natural esta forma de trabajar.

#include <iostream>
#include <string>
using namespace std;

class Father {
public:
    Father() {}
    virtual ~Father() {}
    virtual void ShowMsg() {
        cout << "Father wins..." << endl;
    }
};

class Child : public Father {
public:
    Child() {}
    virtual ~Child() {}
    virtual void ShowMsg() {
        cout << "Child wins..." << endl;
    }
    void ShowExtraMsg() {
        cout << "Child extra wins..." << endl;
    }
};

Así que ahora estamos en C++, recién llegados de C y tras leer libros, tutoriales y manuales, hemos más o menos comprendido de qué va eso de la encapsulación, la herencia y el polimorfismo. Tras un buen rato alucinando y maldiciendo, afirmando incluso que esto es una locura y que en C todo es mucho más sencillo, nos acabamos acostumbrando a la forma de expresarnos en C++. Pero llegamos al punto de hacer una lista con punteros a la clase padre, para poder contener todo tipo de hijos… y tras un buen rato, uno frunce el ceño y se pregunta: “¿Y ahora como coño voy a saber de qué tipo es cada objeto?”

La primera idea que viene a la cabeza es meter en el padre un entero para poder indicar el tipo del objeto, que es exactamente lo mismo que se haría en C. ¿El problema? Pues el mismo que C o mayor, porque el número de .cpp que tendrían incluida la cabecera con la lista de constantes de identificadores de tipo sería mayor, al final perderíamos la cordura de un modo u otro. Entonces sumido en la desesperación, es posible que uno recuerde de haber leído algo sobre un operador parecido a sizeof, pero que se llama typeid, algo que leímos y pensamos en su momento: “Bah, esto seguro que no sirve para nada…”

Father father;
Child child;

string fatherTypeName = "(father: " +
       string(typeid(father).name()) + ")";
string childTypeName = "(child: " +
       string(typeid(child).name()) + ")";
string classFatherTypeName = "(" +
       string(typeid(Father).name()) + ")";

bool fstEq = typeid(father) == typeid(child);
bool sndEq = typeid(father) == typeid(Father);

cout << fatherTypeName << " == " << childTypeName
     << " -> " << fstEq << endl;
cout << fatherTypeName << " == " << classFatherTypeName
     << " -> " << sndEq << endl;

Como se puede ver en este ejemplo al final sí que valía para algo. Por supuesto para poder darle uso a este operador tiene que estar activado el RTTI, que lo único que hará es que el código ocupe un poco más para almacenar la información relativa a la descripción del tipo. Así de forma sencilla podemos comprobar con una mera igualdad si dos objetos son de la misma clase, o si un objeto es de un tipo determinado o no. Incluso podemos hacer más cosas como obtener una cadena con el nombre identificador del tipo, que para temas del log y de depuración podría ser interesante.

Father * ptr = &child;
cout << "typeid information" << endl;
cout << " Name:   " << typeid(*ptr).name() << endl;
cout << "         " << (long long)typeid(*ptr).name() << endl;
cout << "         " << (long int)typeid(*ptr).name() << endl;
cout << " Raw:    " << typeid(*ptr).raw_name() << endl;
cout << " Before: " << typeid(*ptr).before(typeid(father)) << endl;
cout << " Before: " << typeid(*ptr).before(typeid(child)) << endl;
cout << " Before: " << typeid(*ptr).before(typeid(char)) << endl;
cout << " Before: " << typeid(*ptr).before(typeid(int)) << endl;
cout << " Before: " << typeid(*ptr).before(typeid(float)) << endl;
cout << " Before: " << typeid(*ptr).before(typeid(string)) << endl;
cout << " Before: " << typeid(*ptr).before(typeid(Father)) << endl;
cout << " Hash:   " << typeid(*ptr).hash_code() << endl;

Lo primero que hay que entender es que al aplicar el operador typeid obtendremos un objeto de tipo type_info, que es un tipo de clase que no podemos instanciar, ya que de poder hacerlo alguno se dedicaría a liarla parda. Esta clase nos da algunos métodos y sobrecarga el operador == y el != para poder comprobar la igualdad entre tipos. Sus métodos son:

• const char * name() const; → Nos da el nombre completo del tipo, con los namespace incluidos.
• const char * raw_name() const; → Nos da el nombre del tipo sin traducir al lenguaje.
• size_t hash_code() const; → Devuelve el valor hash del tipo.
• int before(const type_info & rhs) const; → Este método es raro y así de primeras da la sensación intuitiva de servir para comprobar si un tipo hereda de otro, pero es una asunción equivocada. En teoría serviría para saber si un type_info está antes que otro en la memoria, una información que no alcanzo a imaginar para qué podría ser útil, pero ahí está ^_^U

Como se puede ver algunos métodos son un poco esotéricos y tal, y la mayoría de las veces con obtener el descriptor del tipo y de ahí su nombre tendremos más que suficiente para trabajar, pero nunca está de más poder saber un poquito más por si acaso… nunca se sabe cuando la mierda te va a llegar hasta el cuello, jej…

Si queréis leer más, y sabéis inglés (algo inexorablemente necesario), en la MSDN tenéis una entrada sobre typeid y type_info, que siempre se pierde algo con la traducción de la información o algo así xDDD

Uno de los clásicos es el tema de realizar un cast de tipos, en C con simplemente poner (tipo)expresión podemos indicar el tipo final que tiene el resultado de una expresión. Pero esto era así en C, porque básicamente los tipos eran muy sencillos, sin mecanismos dinámicos “oscuros” y desde luego sin ninguna clase de comprobación, para poder asegurar que aquello que se hacía no era una locura. De ahí que clásicos también son todos esos fallos de seguridad en programas hechos en C, porque no hay mecanismos dentro del lenguaje para controlar nada… entre eso y la pereza de los desarrolladores, pasa lo que pasa… jej…

En C++ hay 4 nuevos operadores para poder realizar un cast, que son los siguientes:

• dynamic_cast<tipo>(expresión) → Se utiliza sólo con punteros y referencias a clases, para poder indicar cuál es el tipo del objeto apuntado, comprobando si es válida esa indicación. En caso de no ser válido el cast que se pretende realizar se lanzará una excepción si se trata de una referencia y en el caso de un puntero se devolverá el valor null. Esta es una operación que puede ser útil para cuando en una función recibimos un puntero a una clase genérica y queremos comprobar si es de algún tipo hijo en la jerarquía. En otros lenguajes como C# o AS3, por poner ejemplos de lenguajes modernos, tienen el operador as que realiza la misma operación de casting.
• static_cast<tipo>(expresión) → Se utiliza con cualquier tipo no constante y no tiene ningún mecanismo de comprobación, por lo que si la pifiamos el programa podría acabar teniendo algún fallo de seguridad o dar algún fallo de ejecución y cerrarse el programa.
• const_cast<tipo>(expresión) → Se utiliza para poder quitar o añadir el const al tipo de una expresión o variable. También sirve para quitar o añadir el volatile a un tipo.
  
• reinterpret_cast<tipo>(expresión) → Se utiliza para convertir un tipo de puntero a cualquier otro tipo de puntero, sin ningún tipo de comprobación. También permite convertir un tipo puntero a int y viceversa.

Para poder usar el dynamic_cast es necesario tener activado el RTTI a la hora de compilar, es una opción que normalmente viene activada, pero a veces para optimizar el ejecutable final se puede desactivar. Si usamos el cast dinámico no podremos desactivar esa opción, por lo que hay que pensárselo bien si le estamos dando un uso necesario o no, en caso de querer desactivar el RTTI.

El caso es que todo esto me puse a mirarlo a raíz de una situación a la que me estoy enfrentando, ya que el proyecto del master las entidades están compuestas por componentes, en vez de formar una jerarquía de clases, y entre los componentes se envían mensajes. ¿Qué es lo que pasa con los mensajes? Que estos sí tienen al menos una jerarquía de información, lo que implica hacer casting de tipos padres a tipos hijos. Y estaba probando yo alguna forma semánticamente más natural de expresar ese cast.

#include <iostream>
using namespace std;

template<class T>
class IBastard {
public:
    virtual T * GetPointer() = 0;
    virtual T & GetReference() = 0;
protected:
    IBastard() {}
};

class BastardChild : public IBastard<BastardChild> {
private:
    int _foo;
public:
    BastardChild() { _foo = 42; }
    int GetFoo() { return _foo; }
    virtual BastardChild * GetPointer() { return this; }
    virtual BastardChild & GetReference() { return *this; }
};

int main(int argc, char ** argv) {
    cout << "IBastard template class test..." << endl;
    IBastard<BastardChild> * victim = new BastardChild();
    cout << "Pointer:   " << victim->GetPointer()->GetFoo()
         << endl;
    cout << "Reference: " << victim->GetReference().GetFoo()
         << endl;
    return 0;
}

Mi primera ida de olla fue utilizar una plantilla para intentar obtener el tipo real del objeto actual. Pero aunque queda muy bonito, no deja de ser una auténtica ida de olla, porque entonces ¿qué tipo englobaría a todos los tipos de hijos? Pues dada la naturaleza de las plantillas ninguno, sin evitar tener que meter un cast de por medio, que era justo lo que intentaba evitar. Entonces probé otra opción también bizarra.

#include <iostream>
using namespace std;

class IBastard {
public:
    template<class T> T * GetPointer() {
        return static_cast<T *>(this);
    }
    template<class T> T & GetReference() {
        return static_cast<T &>(*this);
    }
protected:
    IBastard() {}
};

class BastardChild : public IBastard {
private:
    int _foo;
public:
    BastardChild() { _foo = 42; }
    int GetFoo() { return _foo; }
};

int main(int argc, char ** argv) {
    cout << "IBastard template method test..." << endl;
    IBastard * victim = new BastardChild();
    cout << "Pointer:   "
         << victim->GetPointer<BastardChild>()->GetFoo()
         << endl;
    cout << "Reference: "
         << victim->GetReference<BastardChild>().GetFoo()
         << endl;
    return 0;
}

Como se puede ver aquí se hace un static_cast, por lo que realmente no nos lo hemos ahorrado, pero de esta forma podemos llamar a la función como nos dé la gana y poner algo como GetAs, que es a mi juicio una forma más clara de saber qué estás haciendo y usas los operadores de C++ correctamente. La otra opción es acostumbrarse a los operadores y tener que explicárselos a los que sean duchos en el lenguaje. En fin, como decía al principio, una ida de olla tremenda el asunto este.

Así que finalmente, allí estaba yo con 3 de mis 4 compañeros, charlando y maldiciendo nuestro sino… Intentando hacer un poco de auto-reflexión, y del ejercicio de la misma elaboré una lista de mandamientos para futuras experiencias, con la esperanza de que en el futuro no la acabemos cagando tanto. Estos son los puntos que recopilamos:

1. El juego tiene que “funcionar”, no tiene que estar pulido hasta el fallo.
   Esta fue de hecho una recomendación que se nos hizo en el video introductorio al evento. Lo que quiere decir es que la meta es hacer un juego al que se pueda jugar, sin importar el millón de bugs que tenga, o que solo funcione para una determinada resolución, o que solo funcione en un ordenador para unas determinadas circunstancias. Lo importante es que después de 2 días, la gente pueda ver que hay algo, cutre y ortopédico quizás, pero algo a fin de cuentas.
2. El productor deberá ser el encargado de diseñar el juego.
   Si tienes un productor eficiente y competente como nosotros teníamos, por favor, que sea él quien se encargue de diseñar el juego. ¿Por qué? Pues muy sencillo mi querido amigo Watson, siendo el plazo de tiempo tan corto, lo más óptimo es que la persona encargada de asignar las tareas sepa perfectamente de qué trata el juego. Si dicha idea está en su cabeza mejor, porque todos sabemos que la comunicación entre dos personas no es el mejor canal de comunicación existente en el universo.
3. El juego debe tener una sola mecánica central y a lo mejor otra más secundaria.
   Esta quizás parezca exagerada, pero ciertamente cuantas menos mecánicas tenga tu juego antes se podrá terminar de hacer. Es algo lógico y comprensible, pero el entusiasmo “alegre” de mucha gente puede acabar haciendo que olviden una premisa tan básica. El resultado de no tener este mandamiento en cuenta es acabar el concurso sin tener un juego.
4. La explicación de las mecánicas no debe ocupar más de un folio.
   Y si ocupa menos de una página todavía mejor. Cuanto más breve y esquemática pueda ser la explicación más sencilla será de entender por los demás. Ponerse a escribir un documento de diseño “completo” con un montón de cosas que no sirven para entender cómo se tiene que implementar el juego, solo servirá para aturdir al que lo lea, ya que el tiempo es escaso y perder el tiempo en intentar comprender lo escrito por otro es siempre un tema complicado. No es que esté abogando por no usar jamás un documento de diseño al crear videojuegos, para desarrollos largos y grandes es muy necesario, pero cuando no hay tiempo es perderlo gratuitamente y de forma demencial.
5. Dicha explicación debe tender a ser lo más zen o KISS (“Keep It Stupidly Simple” o “Keep It Simple, Stupid”) posible.
   Es una forma cursi de insistir en que hay que tender a la máxima sencillez posible. En serio, la comunicación verbal o escrita es un proceso extraordinariamente costoso cuando tu plazo es escasísimo no, lo siguiente. Por dios, evita enrollarte como una persiana gratuitamente solo porque quieras lucirte como diseñador, lo único que lograrás es que el resto del equipo no se lea el documento porque el estrés y el ansia de la escasez de tiempo les agobia y no conseguirán concentrarse en entender tu “obra maestra”.
6. El menú con tener un fondo, los “créditos” endosados por ahí, el botón de “empezar” y el de “salir”, será más que suficiente.
   Si te da tiempo a poner una imagen explicando cómo se juega también estaría bien, pero si no tienes tiempo ahórratelo. De hecho también te puedes ahorrar el botón de salir, haz el juego en modo ventana y no seas huevón, que así ya tienes implementado el botón de salir. En serio, cuando no tienes tiempo, no necesitas ponerte a crear un menú de la hostia, ni un HUD del copón, ni cualquier chorrada que no sea el juego… Y si tu juego necesita mucha tralla de estas cosas, te estás equivocando de juego para un evento tan corto.
7. No coger la primera idea que se ocurra, darle vueltas hasta que quede claro.
   Puede que no tengas tiempo para hacer mucho y esta parezca una regla que te hará perder tiempo, pero puede ser peor empezar algo que no está claro. Razones para afirmarlo, que luego cada cual tenga su propia interpretación y finalmente hayáis perdido tiempo porque tenéis que tirar lo que habéis hecho en las últimas horas. O que por ejemplo a medida que pasa el tiempo la idea va engordando masivamente hasta el delirio más absoluto y demente.
8. No empezar a desarrollar el juego sin tener claro el diseño final.
   Por la misma razón que lo anterior, hasta que no se tenga el diseño en una hoja claro y comprensible para el resto de los mortales, empezar sería un suicidio potencial. Por ello es importante tender a lo simple y así evitar emplear más tiempo de lo necesario a cualquier cosa que no sea desarrollar el juego.
9. No elijas un género espeso (estrategia, aventura gráfica,  RPG, …)
   En realidad puedes elegirlo, pero te puedes exponer a acabar teniendo una idea demasiado compleja para 48 horas. Recuerda que cuantas menos mecánicas mejor, con lo que por lo general si te puedes olvidar de los géneros mejor, pero si no lo haces evita uno que implique un valle entero de mecánicas de una complejidad enorme cual coloso de Rodas.
10. No uses nunca una tecnología que no conoces bien.
    No tienes tiempo para aprenderla, así que si no la conoces no la uses a no ser que estés completamente desesperado. Usa algo que conoces o al final acabarás dando vueltas a cómo funciona más que a cómo hacer el juego.
11. Recuerda que un evento de 48 horas significa que como mucho tienes 24 reales de trabajo (comer, dormir, ducharse, etcétera… ocupan tiempo).
    No diseñes un juego para estar trabajando 48 horas si solo tienes 24 realmente. Puede que seas un terminator y no necesites dormir, comer, ducharte o lo que sea, pero el resto de los mortales normalmente sí lo necesitamos, así que no dormir al final solo sirve para que al siguiente día en vez de aprovecharlo al final seas un infrahumano poco productivo. Además es muy difícil lograr en un día ser productivo más de 8 horas dándolo todo, por lo que no peques de “alegre” e intentes hacer que te va a llevar más tiempo del que tienes.
12. No mantener discusiones estúpidas, porque el tiempo que discutes es tiempo que no desarrollas.
    Discutir gratuitamente hace que no estés produciendo. Aquí no se trata de hacer el mejor juego del universo, ni el más perfecto, ni el que tiene la mejor tecnología de la galaxia, se trata de terminar algo que funcione mínimamente en el tiempo especificado. Por muy buena que creas que sea tu idea para un problema, si no es simple es que algo falla y si encima te pones a discutir para defenderla estarás saboteando el proyecto solo por orgullo, terquedad y obstinación. Así que por favor, evita perder el tiempo que no tienes por tu estúpido ego, el objetivo no es demostrar que eres el más guay, sino que el juego funcione tras 2 días de desarrollo.

Y eso es todo de momento, a la espera de pegarme otro piñazo en el futuro y ampliar la lista claro. Espero que os pueda ser de utilidad y que si sois novatos, os pueda salvar del desastre total y absoluto en el que me vi envuelto.

P.S.: Término el KISS descubierto gracias a mi compañero de master Gabriel, el chaval tan majo que estaba hablando en la tele que hizo el Evil God, un juego bastante interesante y que a mi era el que más me gustaba.