Los juegos: Farmville, de Zynga; Pirates Ahoy, de Playfish; y Social City, de Playdom.
En este artículo hablaremos acerca de la estructura tecnológica de los juegos en red, al estilo de los juegos sociales o los MMORPG. El objetivo es disipar las dudas de aquellos que quieran hacer un juego social o un MMORPG como primer proyecto (respuesta corta: no lo hagan), y las de aquellos que ya tienen idea de cómo hacer juegos, pero no saben cómo planificar o cómo formar un equipo para un proyecto de esta naturaleza. En el artículo supondremos que se está haciendo un trabajo de diseño del juego, el proceso que establece las reglas del mismo para los jugadores, y que es en gran parte responsable del alcance de la estructura tecnológica que se vaya a emplear para el juego. Para los conocedores, simplificaré algunos aspectos, pero recuerden que esto es un artículo para principiantes 
.
Un juego de esta naturaleza necesita 3 aplicaciones: cliente, servidor y base de datos. El cliente es el programa que suelen descargar y utilizar los jugadores, el que presenta los visuales y la interfaz para que los jugadores hagan sus acciones. Esas acciones se mandan a través de la red al servidor, el cual es el verdadero encargado de procesar las acciones y aplicar las reglas del juego. La base de datos es donde se guardan los datos de los jugadores, como su información básica, y el estado actual del juego. Las 3 aplicaciones son separadas, y pueden ser llevadas a cabo por distintas personas de un equipo, pero las 3 se complementan entre sí.
Si tomásemos como ejemplo, a Farmville, de Zynga, el cliente es una película SWF (o Flash, para los no entendidos) que muestra a los jugadores el estado de su terreno, a su avatar, y permite hacer click sobre algún terreno o elemento del juego. El servidor es el que dicta cuánto tiempo tarda el terreno en desarrollarse una vez sembrado, y cuánto tiempo tarda la cosecha fresca. Y finalmente en la base de datos se guardan los datos del jugador y del estado de su partida, para todas las veces que el jugador ingrese al juego. El siguiente diagrama resume lo anterior:
El resto del artículo explicará cada uno de estos elementos y dará algunos ejemplos de tecnologías con los que se implementan.
El cliente, o frontend
El cliente es lo que solemos ver como jugadores. Podemos descargarlo para ejecutarlo en la computadora, o jugarlo a través del navegador. En esta parte se implementa la interfaz de los jugadores, se muestran los gráficos, sonidos y mensajes de información que el servidor envía. Al mismo tiempo, el cliente no suele implementar las reglas del juego, sino que de parte del jugador elabora peticiones al servidor de las acciones que hace éste, y muestra la respuesta del servidor.
En el cliente también se implementan algunas reglas (por ejemplo, en Farmville se impide hacer click en un terreno para cosecharlo si la cosecha aún no está lista), pero el equipo desarrollador se suele asegurar de que sea el servidor el que tenga la última palabra. Esto se debe a que en el pasado las aplicaciones clientes han podido ser modificadas por entusiastas y conocedores para saltarse las reglas o aprovechar alguna información extra que provenga del servidor para hacer trampa. El mejor ejemplo de esto es que en la época de popularidad de Counter-Strike, salieron modificaciones que permitían apuntar automáticamente al enemigo o ver su posición detrás de las paredes. El cómo prevenir esto cae muy fuera del alcance de este artículo, y lo expreso sólo para informar.
¿Qué tipo de tecnologías se utilizan para implementar el cliente?
Dependiendo del conocimiento del equipo o de los objetivos del juego. Actualmente se suele caer en tres campos no exclusivos: descargable, en el navegador, y móviles.
Los descargables suelen ser aquellos juegos que tenemos que descargar en su totalidad en nuestra PC o Mac, y luego instalar en la computadora. Hacer un juego descargable tiene la principal desventaja de la distribución (convencer a alguien para que descargue nuestro juego no es fácil), y el coste de tener que hacer implementaciones distintas para cada plataforma (Windows, Mac, Linux) pero ofrece muchísima flexibilidad y libertad para implementar juegos complejos. Ejemplos de descargables: World of Warcraft, Minecraft o Terraria. Se suelen utilizar lenguajes como C++, Java, Python, en conjunto con las librerías que ofrecen las plataformas para implementar la interfaz gráfica. Existen algunos lenguajes que son multi-plataforma, como Python, Java, y Actionscript con AIR, que permiten desarrollar una sola vez y desplegar para cualquier plataforma.
Los que se juegan en el navegador se suelen implementar en una plataforma que se ejecuta en el navegador, descargando previamente una adición que permite su ejecución. Por ejemplo, para jugar juegos en Flash hace falta descargarse el Flash Player para el navegador que utilices, y en el caso de Java, el JRE de Java. También existen juegos que no necesitan esta adición, y el servidor devuelve texto formateado en HTML, que los jugadores leen y en consecuencia hacen click sobre un enlace o botón que esté en el documento (ejemplo, Chore Wars).
Los móviles tienen su apartado especial. Muchos teléfonos celulares disponen de un navegador, por lo que son capaces de jugar juegos en HTML como los que mencionamos anteriormente. Pero también estos celulares disponen de plataformas sobre las que se pueden desarrollar juegos. Al igual que los descargables, hay que bajarlos e instalarlos en el celular, con la diferencia de que hay que tener ciertas consideraciones en su desarrollo (su poder de procesamiento no es el mismo, el teclado entre celulares cambia) y su distribución (el Apple App Store tiene restricciones sobre lo que puedes subir a su tienda, y en general en todos tienes que pagar un precio para subir tu software).
El servidor, o backend
El servidor es otra aplicación que tiene dos tareas: 1) comunicarse con el cliente, 2) validar las reglas del juego. La plataforma sobre la que se hace el servidor no tiene que ser la misma sobre la que se hace el cliente, y por eso se pueden encargar de ambos dos equipos distintos. El servidor es una aplicación que corre constantemente en una máquina esperando peticiones de los clientes. Cuando recibe una petición del cliente, traduce la petición al formato de datos que pueda entender, valida que la petición sea correcta, y devuelve una respuesta.
En ese sentido, el servidor no conoce sobre la interfaz que va a ver el jugador. El servidor no suele saber de qué mensajes mostrar, ni animaciones, sino que suele ser un proyecto bastante separado de ello. Aún así, en otra parte del servidor (o en otra computadora) se suelen guardar los elementos que necesite el cliente para ejecutarse, sobretodo en el caso de clientes que se corren en el navegador que necesitan cargar sus recursos desde la red.
Existe la posibilidad de que fuese tan exitoso de que se considere implementar otros clientes en más de una plataforma. En este caso habría que extender la primera tarea de la aplicación, comunicarse con el cliente, para que sea capaz de hablar con cada tipo de cliente, ya que cada uno tiene maneras distintas de comunicarse.
¿Qué tipo de tecnologías se utilizan para implementar el servidor?
Existen muchos lenguajes de programación sobre los que se pueden escribir aplicaciones pa servidores, y para cada lenguaje existe un servidor.
En el caso del lenguaje Java tenemos una implementación estándar de servidor, que es Tomcat, y varios frameworks sobre los cuales se construyen las aplicaciones, como Struts o Spring. En el caso del lenguaje Python tenemos frameworks como Django o web2py. En el caso de PHP tenemos CakePHP o KumbiaPHP. Existen otros lenguajes capacitados para escribir aplicaciones para servidores como Ruby.
Hago un repaso ligero de todos estos nombres porque es difícil realmente que un servidor para un juego sea un buen primer proyecto para aprender a utilizarlos, por lo que no tiene mucho sentido que te diga cuál plataforma es mejor.
La base de datos
La base de datos permite almacenar, obtener y relacionar información, de tal manera que se puede consultar sobre ella para obtener datos agregados. Cuando hablamos de esto, hablamos de un software de gestión de base de datos, compuesto por un servidor (¡otro!) que guarda la información, y una librería de código que utiliza nuestro servidor para comunicarse con ese servidor de base de datos. Existen varios tipos de bases de datos, pero el más utilizado de todos (y el que implementan las tecnologías más populares) es la base de datos relacional, que emplea tablas donde se ponen registros de los objetos que se guardan, y estas tablas pueden hacer referencia a otras, para poder unir la información y posteriormente poder consultarla.
¿Qué tipo de tecnologías se utilizan para las bases de datos?
Por lo general, nadie implementa un software de base de datos (muy fuera del alcance de un proyecto suficientemente grande como lo es un juego que tratamos en este artículo). El software que se adopta depende de muchos factores, como costo del software, facilidades de administración, informes de desempeño y demás características.
Entre las opciones más populares tenemos MySQL, PostgreSQL, Oracle, sin orden de preferencias. MySQL y PostgreSQL tienen la ventaja de que se dispone de una versión libre descargable, ideal para empresas con poco capital monetario. En mi experiencia, PostgreSQL ha sido más robusto para aguantar un fuerte uso que MySQL, pero la experiencia varía entre los equipos de desarrollo (ej. Facebook utiliza MySQL como base de datos). Oracle es una base de datos comercial, con una licencia de un costo inmanejable para pequeñas empresas, pero es de las más mencionadas en el campo de las bases de datos.
Conclusión
Terminado el paseo por todas los componentes necesarios para implementar un juego social, me queda decir que el objetivo de todo esto no es disuadir a aquellos que estén interesados en hacer un juego de este tipo. Quizás si debo remarcar que entre los novatos existe un gran convencimiento de que un proyecto así se puede llevar a cabo a la primera, además de un convencimiento de que el hecho de que estos proyectos atraigan tanta atención (y dinero) demuestra que no vale la pena hacer otro tipo de proyecto. Cada juego atrae a un distinto tipo de público, y así seguirá siendo (afortunadamente) a medida que las tecnologías pasen. Si no se convencen, revisen este cómic de xkcd.
A un equipo de programadores experimentados que esté interesado en embarcarse en un proyecto así le recomendaría que primero conociera las diversas tecnologías que van a utilizar para implementar el juego. Probablemente unos juegos pequeños que demuestren el uso de cada una.
