“He estado en la industria 8 años y estoy completamente de acuerdo. Hacer un juego es la parte fácil, hacerlo exitoso es mucho más difícil.” (“Been in the industry for 8 years and I fully agree with you. Making a game is actually the easy part, making it successful is far more difficult.” tomado de esta conversación).  No es que me molesten las opiniones de las personas que no saben de lo que están hablando. Toda opinión tiene potencialmente pertinencia o algo de realidad, así sea accidentalmente sin que su dueño sepa por qué. Pero hay ciertas opiniones que me parecen tan equivocadas que no me puedo quedar callado. Y particularmente aquéllas que se refieren a decir cuál parte del trabajo es fácil. En lo que a mi concierne, no hay parte fácil. Todo es difícil. O todo es fácil, depende de lo pesimista/optimista que seamos. En este caso, el error inclusive es tratar de separar en segmentos dos elementos que no se pueden separar. Hacer el juego y hacer que sea exitoso no son dos objetivos diferentes: uno condiciona al otro. O uno está atado al otro. Se puede justificar diciendo que el mercadeo puede fallar, que el mensaje no llegó a la audiencia correcta. Yo creo que un juego exitoso lo es tenga o no un buen mercadeo, o sea visible o no. Nadie encuentra accidentalmente Flappy Bird escondido en Steam y se pregunta porque nadie lo conoce. Claro este es un buen ejemplo en varios niveles: Flappy Bird de hecho pasó desapercibido varios meses. Pero eventualmente llegó a la cúspide. Lo que pasó después fue otra historia.

Por eso los perfeccionistas (incluyéndome) se quedan en un ciclo infinito agregando y modificando características. La recomendación número uno en la lista de un item en el negocio de desarrollar juegos es “publica el maldito juego” pero justamente no hay nada que pueda matar más fácilmente un video juego que publicarlo antes de tiempo (¿Warhammer Online?). ¿Quieres destruir tu juego? Porque así es como se destruye un juego: publícalo inacabado y ni la más formidable campaña de mercadeo lo hará superar una recepción negativa.

En general no es fácil. Es como cuando “la gente” me mira con sospecha porque digo que trabajo freelancer: “¿ conque ahora te das la gran vida, verdad?” me dicen en la creencia de que freelancer es sinónimo de trabajar en pantuflas un par de horas al día. Hoy estoy levantando desde las 3:30 a.m. Ya he pasado horas hablando con clientes y trabajando 3 proyectos, incluyendo psyblast. No hay trabajo fácil, todos los trabajos son difíciles, cualquiera sea su modalidad. Así que si no sabes de lo que estás hablando, sí, cierra el pico. La gente llegará inclusive a creer que eres inteligente.

La respuesta rápida es C++, aunque la pregunta es inválida, porque si quieres hacer un juego no deberías estar programando ningún motor, sino utilizar cualquiera de los framework disponibles. La pregunta es el título de este largo artículo, que me tomé la molestia de leer. Para mi sorpresa la conclusión es que es mejor C porque C++ es muy lento para compilar, y que interrumpe el ciclo de Observar un bug -> Detener el juego -> Corregir -> Compilar -> Probar el juego -> Repetir si necesario (el autor insiste que la conclusión es algo más complicado que eso. Sí, siempre es más complicado)

Además al parecer en la experiencia del autor C++ es lento, genera tantos crashes (caídas del juego) como C y por alguna razón necesita tener control del manejo de la memoria. Minimizar el uso de librerías adicionales por alguna razón es una meta adicional.

Mi experiencia me indica exactamente ir en dirección contraria:

• C++ es más rápido que C porque me permite desarrollar más rápido. En relación al tiempo de ejecución la diferencia es indistinguible porque mi audiencia son jugadores experimentados quienes al menos tienen un i3 y una tarjeta gráfica decente.
• Como C++ me permite escribir código más robusto C++ genera definitivamente menos crashes que C (aunque si eres un programador medianamente competente como lo tienes que ser para poder ser un programador de juegos, tu juego no debería tener crashes . Por favor.)
• Yo no quiero saber nada de manejo de memoria. De hecho yo voy en dirección contraria, yo estoy eliminando cualquier “malloc” o “new Object” de mi código base. Todo debe ser manejado con std::string() o en el singleton de la clase con un único “new Object” universal cuando no hay más alternativa.
• Minimizar el uso de librerías adicionales es ciertamente una meta. Se puede hacer con C++ . C++ no obliga esto, quizás con más razón C te obliga a esto.

En cuanto al camino de un programador, debería ser algo así como C -> C++ -> C <-> C++ -> C++ (aunque como yo empecé en los 80’s el mio fue C -> C++ -> C++) Si conocemos ambos lo suficiente y hemos iterado una y otra vez con 1,2, 20 juegos, descubriremos que debemos dejar de preocuparnos y abrazar a C++ con ternura y confianza. Inténtalo. Tú puedes.

Si usted leyó cómo programar en C en 2016 (versión en español), ya salió una crítica que lo analiza punto por punto. El detalle es que yo no pasé de la primera regla:

• La primera regla de C es no escribir en C si puedes evitarlo (The first rule of C is don’t write C if you can avoid it)

En los comentarios de Hackernews aparece como justificación de esta regla “¿Por qué alguien en el planeta Tierra voluntariamente haría código en un lenguaje donde la gente puede debatir algo tan simple como el tipo a utilizar para los números enteros?”. Pero la verdad es que no hace falta, mi directorio de C tiene 150+ aplicaciones y soluciones en C que simplemente usan “int”, sólo hay 2 ó 3 que usan cosas como “unsigned int”, “short”, “unsigned long long int”, y en general, como en cualquier lenguaje, no hacen falta cosas sofisticadas para resolver problemas, el K&R (el libro básico de C) incluye la forma canonica de hacer las cosas y eso fue suficiente en 1980 así como en 2016.

El resto de las reglas aplican a soluciones bien específicas que muy probablemente no encontraremos en nuestro día a día. Y otras son simplemente equivocaciones, por ejemplo “hello” es un char[] no un char *.

Así que en lo que a mi concierne la primera regla de C es deja de preocuparte y sé feliz programando en C.

No mercy!

La lista infinita de psyblast en este momento luce así (la lista simplemente, porque ni siquiera quiero ponerle un nombre. Cualquier nombre tendría una connotación optimista, así que el remoquete de “infinita” le sienta muy bien)

• (D) Dialog
  Move cam so it points to the npc after clicking.
• (D) Load raw texts
• (D) Parsing
• (D) Displaying
• (P) Conversation flow
• (P) Happiness

Still ahead

• » New levels + update current levels
• » Code / Extend python generator

Lo cual me lleva nuevas ejecuciones:

• python como scripting language: un gran »no vas«
• Nada de armaduras, ropa y calzado. Duro de eliminar pero eso quedará para 2.0. La idea es agregar en el generador de personajes el color de la vestimenta y alguna selección básica de estilo pero nada más.
• De esta forma en el generador de personajes queda sexo, raza, clase y estilo de ropaje.