26 de julio de 2011
El desarrollo de un videojuego, para el que nunca ha hecho antes uno y quiere comenzarlo, es una tarea que parece muy sencilla, o muy complicada. Al no conocer las sutilezas del desarrollo, el novato puede terminar de dos maneras: o desarrollando un conjunto de rutinas muy pequeñas que no lo van a llevar por ningún lado (un “motor”) o tratando de hacer algo que está muy fuera de su alcance (léase MMORPG, Juego de Facebook, etc.). O las dos cosas. (Ilustración por Papasama)
Esta es una situación recurrente debido a que no suele ser notoria la cantidad de esfuerzo que se aplica para un proyecto como lo es un videojuego. Un videojuego es como un acto de magia en varios sentidos: se prepara un acto para sorprender al jugador/espectador, y lo que parece sencillo en la superficie, por debajo ha llevado una gran cantidad de trabajo.
Cuando yo comencé, yo caí en el primer caso: como me gustaban los juegos de aventura estilo LucasArts, decidí hacer un conjunto de rutinas que me permitieran elaborar uno. El proyecto se llamaba FAGE (FAGE is not an Adventure Game Engine) y lo único que tuvo hasta hace algunos años era una página en Sourceforge.net, sin una sola línea de código escrita.
Otros caen en el segundo caso, y terminan también sin escribir mucho código, o sólo lo básico. El alcance del proyecto es tan grande que no saben por dónde atacar, o cómo comenzar, y dejan el proyecto a medias. El castillo en el aire nunca termina de materializarse.
Como en los juegos, hacer videojuegos es una habilidad que tiene que entrenarse desde el principio. Puedes hacer al menos 10 juegos sumamente sencillos. Puede que te parezcan una estupidez, pero muchos de estos juegos son recordados por una razón. Estudia cómo están hechos y podrás ver que los juegos más complejos habrán tomado prestado de éstos y habrán construido sobre ellos.
19 de julio de 2011
*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 :-P .
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.
12 de julio de 2011
En El Chigüire Literario siempre he recomendado a aquellos que están haciendo un juego por primera vez en su vida que desarrollen un juego en 2D. La reacción suele ser adversa: desarrollar un juego en 2D es como volver al pasado, en una época en la que existen los juegos 3D y han adquirido un realismo notable. Supongo que a esta percepción le debemos sumar la visión del juego 2D como el juego vieja escuela (pensemos en MegaMan) donde la sensación de juego es como la de un arcade, en contraste con los juegos en 3D ricos en interacciones físicas que se asemejan a la realidad.
La buena noticia es que esto no se limita solamente al 3D. Se han hecho excelentes librerías para tener simulaciones físicas para el caso 2D que se sientan reales. Una de estas librerías es la ya famosa Box2D, por Eric Catto, utilizada principalmente en el juego Angry Brids. Otra librería muy completa, que es la que reseñaremos en este post, es Chipmunk. Chipmunk es una librería de física de cuerpos rígidos en 2D escrita en C. Para algunos universitarios la mención de “física de cuerpos rígidos” puede causarles dolor en su cuerpo (valga el mal juego de palabras :-P ), pero para fines de este tutorial, lo único que tenemos que comprender son los conceptos que introduce la librería y cómo se deben utilizar para nuestros fines. Al estar escrita la librería en C, significa que hay una gran diversidad de bindings a otros lenguajes de programación, por lo que podemos usar esta librería escribiendo código en el lenguaje de nuestra preferencia.
Como en este sitio nos gusta Python y PyGame, aprovecharemos Pymunk, el binding para Python que tiene Chipmunk. Es tan fácil de instalar como PyGame, por lo que en pocos instantes vas a tener el poder de crear juegos con interacciones físicas realísticas y sin tener que aprender un montón de conceptos antes de comenzar.
¿Qué conceptos?
Para utilizar Pymunk hay que comprender unos conceptos propios de un simulador de cuerpos rigidos. Los 4 principales son:
Space (Espacio) - Todos los fenómenos ocurren dentro de un espacio, que no es más que un sistema de coordenadas. Es tarea del desarrollador que el sistema de coordenadas del espacio corresponda al de la pantalla. Cuando hablemos de Pygame lo explicaremos mejor.
Body (Cuerpo) - Todos los cuerpos dentro de un espacio tienen propiedades físicas. En el caso de 2 dimensiones, tenemos la masa y tenemos la inercia. La masa es la cantidad de materia en el cuerpo, y para Pymunk indica qué tanta fuerza hay que aplicar en centro de gravedad para moverlo. Si han visto alguna materia sobre física de cuerpos unidimensionales, reconocerán que esto es lo mismo. Por otro lado, la inercia representa la cantidad de fuerza que hay que aplicar en el cuerpo para que éste rote sobre su centro de gravedad.
Un cuerpo con muchísima masa será casi inamovible por cualquier fuerza, y un cuerpo con muchísima inercia será muy difícil de hacer girar. Son dos propiedades distintas: un cuerpo puede tener una masa tan grande que no se pueda mover y aún así tener muy poca inercia para girarse (ver el caso de una barra atravesada por un clavo de tal manera que un punto está fijo en la pared pero la barra puede girar libremente).
No hemos hablado de la forma que puede tener el cuerpo. Los cuerpos en Pymunk no tienen esta información, son entes que no pueden existir en el espacio si no vienen acompañados de una forma.
Shape (Forma) - La forma es la figura que adopta el cuerpo. Esta figura puede ser un círculo, un rectángulo o un polígono convexo. En todos los casos la forma tiene un “offset” que es el centro de gravedad del cuerpo. Como la inercia de un cuerpo suele venir dada por la figura, Pymunk tiene métodos para hacer un cálculo aproximado de esa inercia.
Joint (Junta) - Los joints proveen restricciones al movimiento de los cuerpos. Un caso que ya mencionamos es el de la barra fija a la pared mediante un clavo. Otro caso puede ser limitar el ángulo de movimiento de esa barra. Otro caso puede ser conectar dos engranajes. Existe una diversidad de juntas para múltiples necesidades.
¿Cómo nos iniciamos?
Para comenzar, asumiendo que tenemos instalado Python y Pygame, hay que instalar Pymunk. En Windows es tan sencillo como descargar el instalador de la página de descargas, y en Linux se descarga la fuente y se instala con el procedimiento de ejecutar “python setup.py install” en el directorio descomprimido del proyecto. Los scripts que veremos a continuación están basados en el tutorial SlideAndPinJointsExample de la página de Pymunk.
Una vez hecho eso, podemos escribir un pequeño script que nos haga probar que pymunk se puede importar bien.
import sys
import pygame
from pygame.locals import *
from pygame.color import *
import pymunk # Importamos Pymunk
def main():
pygame.init()
screen = pygame.display.set_mode((600, 600))
pygame.display.set_caption("Pymunk test")
clock = pygame.time.Clock()
running = True
pymunk.init_pymunk() # Inicializamos Pymunk
space = pymunk.Space() # Creamos el Space
space.gravity = (0.0, -900.0) # Colocamos gravedad: una fuerza constante en el tiempo
while running:
for event in pygame.event.get():
if event.type == QUIT:
running = False
elif event.type == KEYDOWN and event.key == K_ESCAPE:
running = False
screen.fill(THECOLORS["white"])
space.step(1/50.0) # Hacemos que la simulación corra 1/50.0 de cada segundo
pygame.display.flip()
clock.tick(50) # Como este loop corre 50 veces por segundo, estimamos que este código se comportará aproximadamente en tiempo real.
if __name__ == '__main__': # __name__ solo tiene el valor '__main__' cuando este script se corre directamente y no se importa desde otro lado.
sys.exit(main())
¿Qué relación tiene con PyGame?
Pymunk ofrece una simulación bastante precisa (para nuestros fines) del movimiento de cuerpos rígidos, pero no tiene forma de mostrar eso en pantalla. PyGame en este caso sería el encargado de: 1) hacer la representación en pantalla de la simulación (algo tan sencillo como líneas y puntos, o algo más complicado con sprites), 2) realizar alguna tarea relacionada con el producto de las colisiones entre elementos de Pymunk, como producir sonido o lanzar algún evento, 3) establecer el timer para ejecutar la simulación paso por paso en el tiempo (con el objeto Clock).
Expandiremos el ejemplo anterior colocando un generador de esferas en el loop y dibujándolo con las funciones de Pygame:
import sys
import pygame
from pygame.locals import *
from pygame.color import *
import pymunk
def add_ball(space): # Esta funcion agrega una esfera
mass = 1
radius = 14
inertia = pymunk.moment_for_circle(mass, 0, radius) # Por lo general la inercia se saca por la forma aproximada del cuerpo
body = pymunk.Body(mass, inertia) # Creamos el cuerpo
x = random.randint(120,380)
body.position = x, 550 # Le asignamos una posicion al azar en el eje horizontal
shape = pymunk.Circle(body, radius) # Al cuerpo le asignamos una forma
space.add(body, shape) # Tnato el cuerpo como su forma se agregan al espacio
return shape
def draw_ball(screen, ball): # Esta funcion dibuja la esfera en pantalla
p = int(ball.body.position.x), 600-int(ball.body.position.y)
pygame.draw.circle(screen, THECOLORS["blue"], p, int(ball.radius), 2)
def main():
pygame.init()
screen = pygame.display.set_mode((600, 600))
pygame.display.set_caption("Pymunk test")
clock = pygame.time.Clock()
running = True
pymunk.init_pymunk() # Inicializamos Pymunk
space = pymunk.Space() # Creamos el Space
space.gravity = (0.0, -900.0) # Colocamos gravedad: una fuerza constante en el tiempo
balls = []
ticks_to_next_ball = 10
while running:
for event in pygame.event.get():
if event.type == QUIT:
running = False
elif event.type == KEYDOWN and event.key == K_ESCAPE:
running = False
ticks_to_next_ball -= 1
if ticks_to_next_ball <= 0:
ticks_to_next_ball = 25
ball_shape = add_ball(space)
balls.append(ball_shape)
screen.fill(THECOLORS["white"])
for ball in balls:
draw_ball(screen, ball)
space.step(1/50.0)
pygame.display.flip()
clock.tick(50)
if __name__ == '__main__': # __name__ solo tiene el valor '__main__' cuando este script se corre directamente y no se importa desde otro lado.
sys.exit(main())
Y en el proximo capitulo…
Hasta aca llegamos con el articulo de hoy sobre Pymunk. Los scripts que aparecen en este articulo se pueden descargar aqui. En el siguiente articulo veremos como utilizar los sprites de Pygame para tener una representacion mas fiel a la realidad de nuestras simulaciones, y veremos que debemos emplear en Pymunk para hacer un pequeno juego de plataformas. Por ahora los dejo con lo que haremos en el siguiente articulo.
27 de junio de 2011
Ahora que se nos terminó el primer semestre de 2011 es buen tiempo para revelar lo que ha pasado en estos días.
Tengo un tutorial sobre Pygame y Pymunk con el que me he retrasado por múltiples razones, la principal de ellas es que para escribir un tutorial siempre chequeo mil referencias para asegurarme de que no estoy enseñando barrabasadas. En eso se me va el tiempo, y bueno… suelen surgir cosas que en el camino debo resolver #atenciondepajarito .
Por otro lado, he estado anotando, recolectando y rumiando ideas para juegos. De hecho, una de esas ideas la estoy implementando para ver a dónde va a llegar. Los que viven o han visitado Caracas alguna vez reconocerán algunos elementos en el siguiente screenshot:
Los que no lo conocen, es una representación de las estaciones y trenes del Metro de Caracas. El primer screenshot es el estado más reciente del juego. En algún momento del desarrollo hice un experimento para probar una perspectiva completamente 2D lateral, pero no iba a resultar para el mecanismo de juego que tengo pensado. El juego lo estoy haciendo con la librería Flixel, que está basado en Actionscript 3, y aunque puede ser confuso para los que no han hecho un juego antes, tiene buen poder para los que ya conocen algo de programación.
Tengo otras ideas para juegos que involucran algo de la idiosincracia caraqueña, pero esas ideas las revelaré cuando estén más maduradas :-P .
