11 años de El Chigüire Literario: el artículo anual

Hace 11 años comencé a escribir sobre videojuegos en Venezuela, en ese entonces como una manera de escribir sobre lo que me gustaba: no solamente escribir sobre juegos, sino escribir sobre desarrollo de juegos.

En ese entonces tuve que hacer una decisión que sabía que iba a tener impacto en el blog para siempre: escribir en inglés para poder contactar a otros desarrolladores alrededor del mundo, o escribir en español para poder contactar a otros desarrolladores en el país (el mío o cualquier otro hispanohablante).

Esta decisión la tomé considerando entre compartir experiencias entre desarrolladores que vivían en otros lados, probablemente en una situación muy distinta a la mía, o compartir entre desarrolladores que vivimos en el mismo espacio geográfico, tal vez con realidades similares. Aún con la capacidad para poder escribir en ambos idiomas, traducir es escribir dos veces. Esto es algo muy difícil y costoso en tiempo, por lo que me fui por una sola opción. Por las conversaciones y las oportunidades que he tenido a lo largo del tiempo, creo que ha sido la decisión correcta.

El blog fue en sus inicios un diario de viaje y un intento de formalizar el pensamiento sobre videojuegos. No solamente se trataba de encontrar o escribir tutoriales: era también sobre poder reseñar juegos, pensar sobre ellos, y tomar lecciones para aplicar en futuros juegos. Pero por mucho que uno piense y analice críticamente a los videojuegos, hacerlos es un asunto completamente diferente. Es un proceso constante, que evoluciona a la par con los juegos que uno hace. Me tomó tiempo mejorar en muchos aspectos la práctica de hacer videojuegos. Y me tomó aún mucho más tiempo tomar en serio mis propios resultados.

A lo largo de estos años, ustedes han tomado interés en mi trabajo, algunos de ustedes han tomado inspiración en él para hacer sus carreras. Esto me alegra inmensamente, y me hace pensar que hacerlo vale la pena. Solo espero que en algún momento tengan la posibilidad de que ustedes puedan hacerlo con su gente, con los nuevos que vendrán más adelante.

Se me hace dificil escribir en en blog. No por falta de cosas que he estado haciendo. Más bien lo contrario: escribir requiere establecer un bloque de tiempo, y es una actividad solitaria. Sin embargo, creo que he podido responder a la mayoría que me ha escrito por mi correo, y mantengo al menos el compromiso personal de continuar escribiendo, aunque no siempre sea a través del blog.

Desde el 8 de enero de 2006 llevo 845 entradas publicadas. Espero aprovechar la oportunidad para tener más. Deseo lo mejor para todos lo que me leen por acá.

10 años de El Chigüire Literario

“Los días son largos, pero las décadas son cortas” — Sam Altman

“«Este es un mundo como otro cualquiera»” — Luis Mateo Díez

El 8 de enero de 2006, hace exactamente 10 años, publiqué un post en un blog de Blogspot donde comencé a hablar sobre videojuegos. A medida que escribo estas palabras, pienso en la frase de Sam Altman. Pienso también en qué son 10 años como medida de tiempo, en lo que estaré viviendo dentro de 10 años, y un balance sobre lo que ha pasado. De eso hablaré hoy.

Diferentes diseños del blog
El blog a lo largo del tiempo

Perspectiva

10 años puede ser una medida de tiempo que pone muchas cosas en perspectiva.

Cuando publiqué por primera vez y hablé de Quake (que para la fecha ya tenía 10 años), no existían los smartphones como los conocemos ahora.

Steam ya existía pero estaba apenas naciendo como plataforma de ventas digitales.

El hardware de las consolas no se parecía tanto al de la PC como ahora y, en consecuencia, los procesos de desarrollo eran muy diferentes entre sí en comparación con hoy en día. Hoy en día algunos fabricantes ofrecen sus kits de desarrollo para mucha más gente, y en consecuencia hay una mayor variedad en videojuegos.

En 2006 estábamos pasando de usar MSN a usar Google Talk. Ninguno de los dos existe actualmente, al menos no en su forma original.

En MSN me gustaba poder extender el nombre que mostraba a mis contactos para poner alguna frase u ocurrencia del momento. En esos días quería hacer un archivo automatizado de las frases que ponía en “mi nick de MSN”. En 2007 ese archivo se materializó en Twitter.

En 10 años co-fundé una empresa que continúa funcionando hoy, me di una segunda oportunidad de estudiar, y estoy actualmente trabajando en la industria del videojuego (más sobre esto más adelante). Nada de esto podía ver yo en 2006.

En 2006 existía una extensa comunidad de blogueros. Ellos fueron los que inicialmente me impulsaron a abrir un blog. Sigo manteniendo contacto con algunos de ellos, y inclusive me casé con alguien de la comunidad y me cambió la vida 🙂 . Sin embargo, la popularidad de los blogs decayó a medida que otras redes sociales tomaron nuestras interacciones.

Hoy

Escribo los siguientes párrafos con el objetivo de poderlos leer más adelante, y poder compararlos, espero, dentro de 10 años.

Actualmente tenemos un mercado móvil que pareciera que se come a sí mismo, con precios que sólo garantizan la supervivencia a los que están en el Top 5.

Tenemos un mercado para navegadores que cambió y que espera a que HTML5 sea una solución fácil de utilizar y que sea multiplataforma.

Las consolas se han abierto poco a poco a más desarrolladores, pero siguen siendo en general tímidos.

Finalmente tenemos un mercado para PC gigantesco, con las descargas digitales casi tan grandes como las ventas físicas, pero ante un estancamiento a nivel de contenido que nos obliga a todos los desarrolladores a replantear muchas cosas que damos por sentado.

El correo electrónico sigue siendo imbatible en la forma de comunicarnos por Internet. Slack ha acumulado muchísima popularidad como un chat y herramienta colaborativa. El streaming se ha popularizado cada vez más y es ahora una forma de transmitir conocimiento a muchas personas.

Nada de esto reemplaza tener una buena conversación y el contacto personal. Es importantísimo conseguir a las personas con la que compartes intereses en tu propia ciudad. Internet facilita este proceso, pero hay que saberlo utilizar para luego poder hablar cara a cara.

Extraño a mis padres y a mi familia, que están más lejos de lo que yo quisiera. Espero verlos muy pronto y más seguido.

Comunidad

En 10 años tuve la oportunidad de conectar con otros desarrolladores, y convencer a muchos más de que tenían en sus manos la posibilidad de crear algo desde cero.

Esta labor y, más importante aún, la curiosidad de ver si se podía hacer un game jam en Venezuela, me llevó a crear el Caracas Game Jam.

Cada enero desde 2009 se han dado cita desarrolladores noveles y experimentados, y todos los eneros termino completamente complacido de la calidad de los juegos que se hacen con los recursos que tienen los caraqueños y demás visitantes de otras ciudades, que se lanzan ese viaje sólo para estar en el evento.

Confieso que cada vez que se termina una edición, me entra un cierto miedo a no poder repetirlo el año siguiente debido al deterioro de las condiciones de vida de mucha gente en el país.

Este miedo se ha incrementado desde que me fui de la ciudad, pero ese miedo ha sido reemplazado por una satisfacción que nadie me puede quitar: la propia comunidad que creció con el Caracas Game Jam se ha encargado de organizar y llevar adelante hasta ahora dos ediciones.

Gracias al blog y al esfuerzo de estudiantes de la Universidad Católica Andrés Bello, di clases. La única vez donde me levantaba con el mayor de los gustos a las 4:45AM un día a la semana para dar clases. Conocí gente maravillosa y trabajadora. Espero haberlos inspirado, así como ellos me han inspirado.

Todo esto va más allá de lo que había esperado o había soñado en 2006 cuando esto comenzó.

Por lo tanto, no me queda más que decirles a todos ustedes, estudiantes, los organizadores y participantes del Caracas Game Jam: gracias. No tengo para ustedes sino el agradecimiento de querer formar parte de esto. Deseo que les dé el impulso para seguir adelante con sus propios emprendimientos.

Arte

Muchas veces esas buenas películas, buenas canciones o buenos juegos que disfrutamos llevan un mensaje implícito de que no vale la pena crear tu propio arte. Lo que consumes está en cierta forma tan bien hecho que no hace falta criticarle, más allá de algunos meros aspectos técnicos o superficiales.

Se piensa que la crítica es decir que algo está mal hecho, y por lo tanto el acto de criticar se convierte en una afrenta. A la afrenta se le responde visceralmente: “si me critican es porque me envidian”, y se pierde una oportunidad fantástica para mejorar.

La crítica comienza cuando después de presenciar algo te preguntas: “¿qué tal si…?”, y cuestionas lo que estás viendo, la idea que hay detrás de ello. Lo que se deja de decir es tan importante como lo que se dice. Otros mundos pueden existir, no limitemos nuestra imaginación a ser un mero reflejo de nuestra vida cotidiana.

Nuestra propia sociedad contribuye a la inaccesibilidad del arte, diciendo (y aquí voy a parafrasear a un querido profesor) que lo que tienes que decir no le interesa a nadie. Buena parte de la sociedad piensa que el arte es un lujo, algo que sólo los ricos pueden hacer y/o pueden pagar.

Pero el arte nos rodea, día a día, cada hora que estamos despiertos. Y podemos participar en ella. Y podemos participar en ella porque es lo que nos permite sentir empatía y que somos más parecidos de lo que aparentamos, aún cuando el mundo de hoy nos obliga a especializarnos. También nos permite desahogarnos, sentir que no somos perfectos, y eso es perfectamente válido.

En 2006 el subtítulo de este blog era “el videojuego es la nueva literatura, el MP3 es cultura”. La literatura la define la RAE, entre otras cosas, como el “arte de la expresión verbal”. ¿Qué se hace con la expresión verbal? Contar historias.

Contar historias es sólo una parte del arte. Hay gente que cuenta emociones, o cuenta impresiones. Pero contar historias es algo que siempre me ha gustado, aunque los juegos me han impulsado hacia analizar sistemas de reglas y ver cómo funcionan.

Contar historias es ofrecerte para que otros se sientan solidarios contigo. Cuando dos o más personas se unen con una idea en común, es cuando adquirimos la capacidad de crear un mundo propio. Entre grupos nos podemos llevar adelante para impulsarnos y tener una vida mejor.

Eso es lo que hace el arte. Y el arte comienza sincerándote con tus gustos.

El ejercicio para 2016 es, entonces, aprender a criticar, y aprender a disfrutar tus gustos.

Lo que viene

El Chigüire Literario para mí representa lo que ocurre cuando uno pone algo de sí para alguien, y encuentras respuesta de parte de ese alguien. Es una interacción que me nutre, y que espero nutra a los que me leen.

Esto no siempre ocurre con todo lo que haces, e incluso pueden haber períodos donde no pasa nada, períodos en los que uno, honestamente, se siente como el culo.

Sin embargo, todo esto pasa y uno trata de encontrarle una explicación, una narrativa. Seas profundamente religioso, o seas obstinadamente ateo, esto ocurre porque somos seres humanos.

Estamos hechos para ver patrones en la vida, y nuestros cerebros desean tanto ver esos patrones que a veces comienzan a ver cosas donde no hay. Esto no es malo, ni es bueno. Simplemente es así. Y mientras más conscientes seamos de eso, creo que seremos capaces de llevar una mejor vida.

En 10 años tuve la oportunidad de comenzar a trabajar en la industria del videojuego. He sido desarrollador de juegos desde cero, y ahora soy desarrollador de algo que es muchísimo más grande que un equipo pequeño, o yo solo.

El repertorio de habilidades técnicas es diferente, y a lo largo de estos años he tenido la oportunidad de aprender una parte de este repertorio.

Pero lo más importante sigue siendo el pensamiento crítico, la capacidad de resolver problemas, los que te vengan, y la capacidad de empatizar con otros y ver su punto de vista.

Ver hacia adelante es muy difícil. Siempre lo ha sido. Uno tiene que ir por la vida con una mezcla de optimismo y ansiedad, y a veces ni siquiera el optimismo. Creo en el agradecimiento como antídoto para esa sensación. A ti, por todo: gracias.

Revisa los posts de años anteriores: 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2008, 2007, 2006.

La Ficción Interactiva y sus playas

elije

Una de mis inspiraciones en todo esto de hacer videojuegos es la serie “Elige tu propia aventura”. Esta serie de libros no se leen de principio a fin, sino que comenzando desde la primera página, el libro te plantea una elección al final de cada segmento (que generalmente se extiende por una sola página). Dependiendo de la elección que hagas, el libro te instruye saltar a una página u otra.

Este formato es uno de los primeros que surgió cuando los videojuegos se popularizaron, y se llama Ficción Interactiva (o Interactive Fiction, en inglés). No hay casi nada nuevo en este formato, tan solo que las herramientas para escribir ficción interactiva se han simplificado muchísimo. El objetivo de este artículo es hacer una introducción al tema y sugerir una herramienta que puedes utilizar para crear tus propias historias.

Hace un par de meses me di la oportunidad de escribir una historia interactiva, se llama La Línea. Era algo que había querido hacer desde hace ya algún tiempo, y había escuchado una herramienta que permitía hacer esto fácilmente, en un formato muy simple de distribuir, páginas en HTML.

Uno podría ciertamente escribir la historia con HTML, pero esto implica concentrarse en los detalles del formato, cuando lo que hace falta realmente es concentrarse en los detalles de la historia que uno quiere contar. Lo ideal es tener una herramienta donde puedes escribir, y sin muchas vueltas poder establecer las partes que quieres que enlacen con otras. Si ya has tenido suficiente práctica con la herramienta, hasta podrías pensar en que quieres establecer algunas condiciones para ofrecer una opción (por ejemplo, digamos que quieres revisar toda una habitación antes de seguir adelante).

Lo bueno es que estas herramientas existen, y voy a listarlas a continuación. Eso sí, una buena práctica antes de comenzar a escribir es revisar y ver qué han hecho otras personas con estas herramientas. Este es un listado de sitios () donde puedes leer buena ficción interactiva:

Para escribir ficción interactiva:

  • Twine, esta es la herramienta que utilicé para La Línea, y hablaré un poco sobre ella más adelante. Tiene una versión que puedes usar en línea, por lo que puedes comenzar ahora mismo, incluso en un dispositivo móvil.
  • inklewriter, de la misma gente de Inkle. Tuve la oportunidad de probar un poco esta herramienta, y me pareció muchísimo más simple de utilizar que Twine, ya que tiene una interfaz mejor lograda para escribir y agregar opciones. Sin embargo, Twine ofrece un poco más de flexibilidad en comparación. Como es una página web, lo puedes utilizar en un dispositivo móvil.
  • Seltani, permite también la participación colectiva para escribir. Permite también un poco de código.
  • Inform, es un sistema de programación hecho para que los jugadores escriban instrucciones para avanzar en la historia.

Un poco sobre Twine

De todas estas opciones sólo he podido probar las dos primeras que mencioné, y en ambas me encontré con herramientas que insisten en salirse de tu camino a lo que es realmente importante: escribir una historia. Una ventaja de Twine es la posibilidad de descargarlo a la computadora y poderlo utilizar completamente fuera de línea, utilizando solamente un navegador moderno.

Para escribir una historia en Twine debes crear pasajes de texto, representados visualmente como recuadros), y luego enlazas los pasajes de texto con hiperenlaces, rodeándolos con doble corchete [[así]], muy al estilo Wikipedia

Lo otro interesante de Twine es la posibilidad de utilizar macros para hacer un mínimo de programación para la historia. Por ejemplo, podrías tener un contador para saber cuántas veces ha leído el jugador un cierto texto, almacenar el nombre de alguien y mostrarlo dentro del texto, mostrar variaciones de un mismo texto para que no se haga monótono. Lo importante del asunto es que no requiere algo por separado, lo puedes escribir ahí mismo junto a tu historia.

Espero que este artículo te anime a escribir historias. Y si tienes alguna hecha, puedes subirla a algún lugar al estilo neocities y enlazarla en los comentarios. ¡Buena suerte!

(†) Este listado fue tomado de un taller corto sobre el tema con Emily Short, síguela en Twitter para buena información sobre ficción interactiva. He aquí otros enlaces interesantes:

¿Por qué el control de versiones es crucial para programar (entre otras cosas)?

Si has tenido que entregar un trabajo escrito, o un proyecto para la universidad, muy probablemente has tenido esto en tu escritorio:

tesis

Es muy importante darse cuenta de que un documento que escribes, ya sea código fuente, documentación, un libro, una tesis, no es solamente el producto que entregas al final. Es también el proceso de pensamiento por el que pasas para poder llegar a ese producto.

Ese proceso muy rara vez es lineal. Muy pocos libros se escriben comenzando desde la introducción, y escribiendo cada capítulo en orden. Muy pocos proyectos de software comienzan con la pantalla de inicio.

El proceso de pensamiento en muchas ocasiones es caótico y desordenado. Pero sobre todas las cosas, los pensamientos son orgánicos, tenemos decenas de pensamientos cada día, pero solo algunos de estos se quedan en la mente. Algunos de estos pensamientos son difíciles de concebir, de hacer crecer, mientras que otros parecieran que crecen más rápido que nuestra misma capacidad de concebirlos.

Cada idea que tenemos es el resultado de ensayar varias posibilidades. No podemos escogerlas todas, hay que tomar decisiones en el camino. Algunas veces es muy conveniente poder ir atrás en el tiempo, y explorar otra posibilidad, lo que lleva la idea por otro camino.

Un control de versiones es un software que facilita este proceso. Es capaz de tomar fotos de un documento y compararlos en el tiempo. En cada comparación podemos ver qué cosas se agregaron, se quitaron o se cambiaron. Es capaz de tomar una de esas fotos y formar una línea de tiempo. Todo lo escrito va para un repositorio, el cual preserva toda esta información.

Pero de todas las funcionalidades, la más importante es tener la capacidad de comunicar y compartir cambios en el documento/código a otras personas que están trabajando sobre el mismo proyecto. En casi todos los sistemas el proceso es similar: cada integrante descarga una copia del proyecto a un “directorio de trabajo”, allí hace los cambios, y luego manda los cambios de vuelta al repositorio. El sistema incorpora los cambios hechos por otros participantes de la manera más transparente posible, pero si no es posible integrar los cambios (por ejemplo, dos personas cambiaron la misma línea de texto), entonces el sistema deja al usuario el trabajo de seleccionar cuáles cambios continúan o se revierten.

No es mi objetivo enseñar específicamente cómo utilizar un control de versiones. Creo que hay recursos en línea que son mucho mejores y están disponibles inmediatamente, y a los que haré referencia al final del artículo.

Si escribo esto, es para animar a aquellos interesados en programar a que aprendan también a manejar un control de versiones. Esto es algo que muchas veces se aprende en una oficina y no en una universidad (donde supuestamente se aprende esta clase de cosas).

Por otro lado, muchos escritores no tienen el conocimiento tecnológico para incorporar un control de versiones en su trabajo (¿instalar un servidor?, ¿cómo guardo mis cosas?). Sin embargo, ver un recurso como GitBook me hace pensar que es posible traer a los escritores las ventajas del control de versiones sin pagar tanta penalidad en el aprendizaje de su manejo. Si eres escritor regular me gustaría saber tus opiniones al respecto.

Si necesitas saber más sobre el control de versiones, el libro Version Control By Example, de Eric Sink, es una de los mejores libros que he leído sobre el tema, e incluye los sistemas más populares. Si tu intención es, además, ser desarrollador profesional de videojuegos, en algún momento te encontrarás con Perforce, el cual es un servidor centralizado, similar a Subversion. Cuenta además con una versión gratuita para un límite de usuarios, lo que te permite probarlo sin costo alguno.

Las herramientas son solamente herramientas

Foto por Lenore Edman
Foto por Lenore Edman

Últimamente he observado en varias comunidades de desarrolladores de videojuegos la tendencia a idealizar las herramientas que utilizamos, quizás hasta el punto de excluir la posibilidad de que existan otros puntos de vista.

Comparamos engines, lenguajes de programación, hasta pipelines completos de desarrollo. No es que esto sea malo, la verdad es que aprender a utilizar alguna de estas herramientas (o conjunto de herramientas) requiere invertir tanto esfuerzo que entiendo la necesidad de sentir que hemos hecho la elección correcta y, por lo tanto, destacar las bondades de la herramienta.

También es cierto que es muy difícil anticipar cómo se va a comportar una herramienta ante un proyecto. No es lo mismo hacer un juguete que algo que sea entregable. La herramienta puede tener limitaciones que no eran conocidas al momento de comenzar, o se comporta lentamente, o la recolección de basura pone el juego lento en momentos al azar.

Pero uno de los vicios, si así lo puedo llamar, es hacer la comparación de las herramientas empleando el material de marketing o los juegos más exitosos del momento. Dado el nivel de muchos desarrolladores noveles, no creo que les sean útiles muchas de las últimas características novedosas de tal o cual herramienta, pues suelen ser cosas que en cada versión van aumentando en complejidad. Son características que multiplican la productividad o los resultados si has hecho el trabajo indicado al momento en que aparecen, pero no agregan beneficios si apenas estás comenzando.

Cada desarrollo es un proceso largo y complejo, conformado por muchos pequeños momentos que se suman y forman algo más grande. Ese material de marketing que vemos está hecho precisamente para eso, para difundir las bondades del engine que se te está vendiendo, muy probablemente sin cubrir tu caso de uso, que suele ser más complejo u oscuro de lo que parece. El juego que estás alabando muy probablemente tuvo que tomar más de un atajo para lograr el resultado que estás viendo. Quizás todo esto sea porque me gustaría ver más juegos hechos, y no tanto “mira qué maravilla [tal característica] de [tal engine]”.

Mi recomendación, si es que quieres seguirla, es que siempre cuestiones lo nuevo que sale. Si has visto un juego hecho con una determinada herramienta, sea cual sea, significa que existe la posibilidad de hacerlo. Por tanto, lánzate a hacer tu juego con esa herramienta que conoces. Verás que esa herramienta que alabas tanto tendrá sus dificultades y sus achaques. Eso es algo bueno, significa que esa herramienta tiene posibilidades de mejoras. Si es un producto hecho en comunidad, significa que puedes ingresar a la comunidad de desarrolladores y participar allí, sugiriendo mejoras, e incluso hacerlas tu mismo y subirlas.

3D Avenue post mortem

nanomites1
A dos años de su publicación, 3D Avenue decidió publicar un postmortem de su juego Nanomites (link del juego en iTunes) en inglés. Así que con su permiso lo traduje al español y lo pueden leer a continuación.

Nanomites fue nuestro primer juego, y sentimos que aprendimos muchísimo de su desarrollo. No solamente fue el primer juego que desarrollamos en 3D Avenue, pero para la mayoría de nosotros, fue el primer juego completo que hayamos desarrollado. Como programador, mi única experiencia fue siguiendo un tutorial para hacer un juego de explotar globos (un Balloon Popper) para el iPhone, y algunos intentos fallidos de hacer mods de Half Life y Quake, en la época que todos los chicos cool lo estaban haciendo. Y digo fallido, pues realmente nunca le dediqué suficiente tiempo. Nuestro artista era el que había tenido más experiencia trabajando en proyectos más grandes de juegos, habiendo trabajado en un par de mods populares de Half Life (Sabaneta 2050 y Front Line Force). Su trabajo con esos mods, sin embargo, fue haciendo cosas en 3D. Nanomites era un proyecto 2D, así que esto también era nuevo para él. Para nuestro diseñador de juegos, era la primera vez que el tomaba las decisiones sobre la dirección del juego, la jugabilidad, la mecánica, la adaptación a las restricciones técnicas, muchas cosas de un documento inicial de diseño de Nanomites que no lograron quedar en el juego, debido a restricciones de tiempo y limitaciones de la experiencia del equipo, y esto juego algo a lo que el diseñador de juegos tuvo que adaptarse y aprender.

Con respecto a las limitaciones de hardware, tengo que mencionar que, aunque el poder que tienen los dispositivos móviles hoy en día es increíble, no está aún donde nos hubiese gustado que estuviese para Nanomites, en especial no para dispositivos viejos como el iPhone 4 y sus generaciones previas. Pero esto fue algo que no sabíamos en ese momento. De hecho, la razón por la que queríamos que Nanomites fuese 2D es porque pensamos que sería más sencillo hacer un juego 2D. Pero después de lidiar con texturas, limitaciones de memoria para archivos grandes de texturas, atlases, sprites, animaciones fotograma por fotograma, ahora sabemos que no es necesariamente más sencillo hacer 2D en vez de 2D. Habían muchas cosas que no sabíamos. La idea original de Nanomites no incluía a los personajes, y era mucho más simple. Se llamaba Nanosplit. Pero cuando nos dedicamos a tiempo completo sobre el juego, en vez de trabajar en “horas posteriores”, es decir, después de nuestros trabajos diurnos, pensamos que podríamos agregar más cosas, así que el documento de diseño creció.

El plan era que nuestro primer juego sería sencillo. Un juego que pudiésemos desarrollar rápidamente, uno que no tomara demasiado tiempo finalizar. La idea detrás de Nanomites era “un juego donde tuvieses que dibujar líneas para separar bolas que rebotan”, SUENA simple, pero después de tres meses de desarrollo, lo único que teníamos era un bonito salvapantallas sin casi ninguna jugabilidad aparte de las “bolas que rebotan”. Durante ese tiempo el equipo se frustró mucho. Uno de nuestros programadores nos dejó a causa de esto. Y no progresó tan rápido como nos hubiese gustado, pero afortunadamente, gracias a la asombrosa comunidad de Unity 3D, pudimos conseguir ayuda en los foros. Así, el primer mite fue finalmente capturado, con las reglas correctas, tres meses después de que el desarrollo comenzó. Si no hubiese sido por la increíble contribución de los foros, Nanomites no hubiese sucedido. Y estamos sumamente agradecidos por su ayuda.

Los siguientes cuatro meses transcurrieron entre pulir el juego, agregar más mites y comportamientos, la mecánica de dibujar la línea (la cual en algún punto tendrá su propio artículo, porque es algo que me han preguntado otros programadores, y tengo que decir que fue bastante complejo), los sonidos, la interfaz, resolver bugs, el tutorial, la música… Tantas cosas que incluye hacer un juego, y no es hasta que lo completas que te das cuenta de la cantidad de trabajo que requiere. Amar lo que hicimos ayudó bastante. Creo que la frustración inicial fue porque lo queríamos tanto, que nos adaptamos y aprendimos. Y es probablemente como el inicio de una relación a largo plazo: vas a pelear, vas a estar en desacuerdo, pero eventualmente, con esperanza, puedes hacer que funcione, y terminar de hacer cosas.

¿Qué estuvo bien?

Logramos de verdad hacer el juego. Para ser honestos, después del primer par de meses de desarrollo, pensamos que no íbamos a ser capaces de lograrlo, no era jugable y no teníamos idea de cómo hacerlo todo, pero persistimos, lo hicimos funcionar y estamos extremadamente orgullosos de cómo resultó.

Aprendimos un montón del desarrollo de Nanomites, cómo planificar mejor, tenemos una mejor idea de lo que significa más pequeño y más simple en términos de proyectos, muchas cosas que hacer y que no hacer en el lado técnico, cómo de verdad hacer juegos (lo cual fue muy emocionante). Aprendimos un montón acerca de nosotros mismos y acerca de cada uno de nosotros, y aunque aún tenemos mucho por aprender, nos sentimos más confiados, tenemos una mejor idea de qué hacer, y lo que tomará para terminarlo.

¿Qué estuvo mal?

Sentimos que el principal problema con Nanomites fue que el desarrollo de la mecánica del juego era demasiado difícil y retador para la experiencia y conocimiento que teníamos, no era definitivamente para principiantes. Durante el desarrollo el proyecto también se volvió muy ambicioso y al final tuvimos que recortar muchas características del mismo. Originalmente (cuando no era ambicioso) habíamos planeado un ciclo de desarrollo de 6 meses, y ya nos acercábamos a los 12 meses cuando salió el juego. Algunas de estas características incluyen modo de aventura, muchos más comportamientos de los mites, y peleas con jefes. Pensamos que la idea sonaba simple, pero eso fue un gran error.

Si estás apenas comenzando, trata de hacer lo más que puedas para saber en qué te estás metiendo del lado técnico, que fue lo principal que nos retrasó. Mas, afortunadamente, al final, lo hicimos funcionar. Para hacer eso, tienes que investigar en las mecánicas que quieres implementar, en todas ellas, antes de escribir la primera línea de código, eso debería ayudar un montón.

También hicimos algunos errores con relación al marketing y la publicación, lo cual resultó en que Nanomites no se desempeñara en las ventas también como hubiésemos querido, pero estamos trabajando en arreglar eso para nuestro próximo título.

¿Qué más estuvo bien?

Nanomites recibió muchas reseñas positivas, y la gente realmente disfrutó el juego. Las puntuaciones topes en los leader boards no son nisiquiera de nosotros, y eso nos hace muy felices. Todo el que lo ha jugado, lo ha disfrutado, y el juego tiene evaluaciones sólidas, tanto en el AppStore como en el Play Store.

¿Qué queda para Nanomites?

Nos gusta Nanomites, los personajes, el juego, y nos encanta que la gente haya disfrutado tanto el juego. Haremos una actualización del juego para soportar algunas resoluciones en algunos dispositivos que han salido desde el que juego se publicó.

Una de las cosas que más nos piden es continuar jugando desde la ola donde moriste, y estamos pensando en formas de permitirlo, así que eso debería llegar en algún momento. Ahora mismo estamos concentrados en Spectrum, así que puede pasar algún tiempo antes de que hagamos más cosas con nanomites, pero no nos vamos a olvidar de él. Ya hemos actualizado el proyecto para usar la última versión de Unity 3D, y hemos arreglado algunos bugs que surgieron a partir de ello, así que viene una actualización. Pero como lo mencioné, nuestro enfoque principal ahora mismo es en Spectrum.

Si tienen alguna pregunta, por favor déjenla en la sección de comentarios. ¡Gracias por leer!

PD: Agregaré algunos bosquejos conceptuales y screenshots del inicio del desarrollo a este artículo en el futuro.

Entrevista en El Universal: “Videojuegos en fuga”

Hoy domingo 4/11 en El Universal salió un reportaje sobre desarrollo de videojuegos en el que entrevista a Flavia Cassani, desarrolladora de My Neighbor The Zombie, cuyo crowdfunding reseñamos hace algunas semanas, y un servidor.

El reportaje en sí esta bastante completo, incluyendo la propuesta de Tabla de Clasificación de Software de Entretenimiento que presentaremos en Gamexpo 2012.

Tanto Saúl González como yo estamos de acuerdo que el periódico debió aclarar que la imagen que acompaña al reportaje es la de Mercenaries 2. Este juego ha levantado controversia en Venezuela por su contenido, y es uno de los principales ejemplos que demostró el comité proponente de la Ley de Prohibición de Videojuegos y Juguetes Bélicos para justificar su contenido.

En El Chigüire Literario tenemos a disposición un amplio archivo gráfico de videojuegos que se han hecho en Venezuela o por venezolanos, de manera que se pueda demostrar de mejores maneras el trabajo que se ha hecho en el país.

El diseño de juegos como una disciplina

(Artículo publicado originalmente en Niubie)

“¡A este juego le falta que el personaje haga esto!” seguramente habrás dicho más de una vez. Si el jugador pudiese encontrarse frente al diseñador del juego cuestionado, seguramente no se cansaría de decir las cosas que él podría mejorar del juego. Y en muchos de esos planteamientos, el diseñador podría defender cada una de sus decisiones.

El diseño de videojuegos es una disciplina poco comprendida, ignorada entre el glamour que tiene el artista visual, y el gran esfuerzo que se lleva el programador en dominar la plataforma tecnológica que emplea. El diseño de juegos es visto como el producto de la serendipia del equipo, como si la suma de las partes por sí sola dará un buen juego. Existe la posición de productor, que se asegura que el proyecto se pueda completar con los recursos que están disponibles, pero el oficio del diseño difiere bastante de estos requerimientos.

En la práctica, el diseñador de juegos es un comunicador, un investigador, y un experimentador. Es una disciplina surgida del gran abismo del entendimiento entre programadores y artistas. Esto aleja el retrato de un diseñador como el emperador que desde el Olimpo decide qué se hace y qué no. Ser un comunicador implica representar el papel de un diplomático, que debe escuchar a todas las partes involucradas, y tomar decisiones en base a eso. Ser un investigador significa que se debe estudiar profundamente acerca del tema sobre el que se está haciendo un videojuego, y ser capaz de acceder a un amplio pozo del conocimiento, a veces compuesto de temas aparentemente disconexos. Ser un experimentador significa que en varias ocasiones el diseñador debe tomar decisiones sobre temas no explorados anteriormente.

Ser diseñador tampoco se trata de ser el “tipo de las ideas”. Precisamente porque el diseñador ha tenido contacto con las habilidades que está delegando, tiene argumentos acerca que las decisiones que pueden funcionar para un juego. Un buen diseñador puede citar las bases con la que está tomando una decisión, y no limitarse a copiar superficialmente una característica de otro juego.

Posicionarse como diseñador en el mundo del desarrollo de los videojuegos es, debido a lo dicho anteriormente, un asunto complicado. Hay diseñadores que provienen de un antecedente artístico, y hay diseñadores que provienen de la ingeniería y la programación. Es importante entender que el diseño de juegos no es una disciplina relacionada con programación, sino con la creación y experimentación de experiencias interactivas. Un juego bien puede ser una actividad realizada con una consola electrónica, o puede ser una actividad realizada entre cuatro personas con lápiz y papel.

Al ser una disciplina relativamente novedosa, no existen manuales definitivos sobre este oficio. De hecho, ni siquiera existe un vocabulario estándar que todos los diseñadores empleen. Es gracioso, pregúntenle a dos diseñadores con experiencia cómo trabajan, y los dos van a responder similarmente, pero con vocablos distintos. Sin embargo, es una disciplina que poco a poco está cobrando vida y está adquiriendo la formalidad necesaria para poder ser estudiada y, más importante aún, enseñada. Así, podremos conversar de diseño de juegos en términos propios, y no diciendo “se parece a X juego, pero diferente”.

La habilidad más importante, quizás, para un diseñador de juegos en formación es la capacidad de poder jugar un juego analíticamente. Se puede identificar a un “tipo de las ideas” porque su experiencia proviene únicamente de jugar, pero es incapaz de explicarse por qué el juego se comporta en cierta forma en diferentes etapas del mismo. El juego analítico implica hacer cosas que un jugador normal no haría sólo para ver el resultado del juego; implica jugar más de una partida, cambiando los parámetros, para conocer el espacio de posibilidades que ofrece el juego. En pocas palabras, un diseñador de juegos deconstruye los juegos hasta sus partes más simples.

Concluyo con algunos enlaces para los que están interesados en aprender más sobre el diseño de juegos:

  • Extra Credits (en inglés): sin duda alguna, la mejor referencia en materia de diseño de juegos. Cada jueves James Portnow y Daniel Floyd nos traen 5 minutos empacados de información valiosa sobre diseño, acompañado de un arte genial que hace divertido verlo.
  • Game Design Concepts: este es un curso gratuito iniciado por un diseñador de juegos, Ian Schreiber. En este curso veremos una introducción formal a todo este tema, con ejercicios de papel, tijeras y lápiz para comprender los conceptos que se estudian. Este curso tiene una traducción al español (en progreso) llevada a cabo por este servidor, y que pueden conseguir en http://gamedesignconcepts.pbworks.com/Spanish.
  • Challenges for Game Designers (libro, en inglés): este libro fue coescrito por Ian Schreiber y por otra maestra del diseño, Brenda Brathwaite (conocida ahora como Brenda Garno). De este libro se toma gran parte del contenido del curso señalado anteriormente.
  • Game Balance Concepts (en inglés): continuación del curso anterior, el cual dedica un verano a hablar sobre cómo balancear el progreso de un juego, de tal manera que todos los jugadores se sientan retados pero al mismo tiempo con una dificultad no extrema.
  • A Theory of Fun for Game Design (en inglés): este libro escrito por Raph Koster devela por qué los juegos nos gustan y por qué nos sentimos impulsados a jugarlos. Una lectura refrescante acompañada de unas ilustraciones muy graciosas.
  • The Art of Game Design, por Jesse Schell (en inglés): este libro fue escrito por un gran diseñador, y es uno de los libros que más se acerca a ser una referencia de vocabulario de diseño de videojuegos. En este libro, Schell plantea el problema del diseño como una serie de “lentes”, en el que los juegos se analizan desde muchas perspectivas.

Mochi descontinúa sus monedas

Leyendo un post de Nitrome en su página en Facebook me entero que Mochi, la empresa de publicidad que he mencionado en mis charlas, va a descontinuar sus Mochi Coins, la manera como la empresa incursionó en el mundo de las microtransacciones. Si no lo saben, Nitrome es uno de mis desarrolladores de juegos favoritos de todos los tiempos, así que les recomiendo ampliamente entrar y jugar sus juegos.

Pues bien, las microtransacciones son la base para los juegos Free 2 Play, en el que el jugador puede comenzar a jugar gratuitamente, y paga para los casos en que quiera ahorrar tiempo, adquirir poderes u obtener contenido extra. El caso del cierre de un negocio intermedio como el que descontinuará Mochi es un suceso perjudicial para un desarrollador, ya que el costo del cambio es alto. No sólo por el costo obvio de desarrollo, sino el hecho de lo que ocurre con las compras que ya tienen los usuarios, cómo migrarlos y el cuidado que eso conlleva.

Haz click en la imagen para ir al post original

En tiempos como estos, en los que los juegos en Facebook han visto su dominio mermado ante los juegos en los móviles, es bueno recordar los riesgos en los que uno como desarrollador incurre cuando selecciona una plataforma.