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.

Hacer videojuegos – Tú también puedes

(Artículo publicado originalmente en Niubie y en el blog de 4Geeks)

“Debemos hacer los juegos que deseemos jugar en este mundo.” — Anna Anthropy

Estamos en un momento genial para aprender a hacer cosas con las computadoras. Este momento no está dado por el poder de procesamiento de ellas, o la cantidad de memoria que les permita almacenar datos, aunque han contribuido en buena medida. Se trata de que las mejores herramientas para desarrollar software que puedes usar en este momento son gratuitas, o con muy bajo costo. Y estas herramientas, tras el debido aprendizaje, te permiten expresar lo que habías imaginado en primer lugar.

Durante años la competencia de los fabricantes de las computadoras ha sido apuntada a las máquinas con cada vez mayor musculatura. De tal nivel ha sido la competencia que la diferencia que solía haber entre generaciones se ha disminuido, por lo que el objetivo se ha movido. Ahora la portabilidad en hardware (y en consecuencia la durabilidad de la batería) y la facilidad de uso en software son más demandadas.

Hay mayor diferencia entre Wolfenstein 3D (1993) y Duke Nukem 3D (1995)…
…que entre Soldier of Fortune (2000) y Call of Duty (2006)

Esto ha sido notorio especialmente en los videojuegos, en los que tradicionalmente la musculatura del hardware y las exigencias del software se han dado la mano para subir la barrera de entrada a un nivel muy alto, dejando por fuera a personas y equipos pequeños interesados en hacer videojuegos y que no disponen de los mismos presupuestos que EA o Activision.

Sí, nosotros los gamers hemos disfrutado de excelentes gráficos y sonido envolvente. Pero eso ha venido con un costo. Las exigencias de los jugadores hace que se eleve el costo de producción de estos recursos. A su vez, los elevados presupuestos de los juegos hace que los inversores (léase publishers) sean precavidos con lo que vayan a producir. El resultado es la proliferación de fórmulas preestablecidas, licencias de películas, continuaciones de las continuaciones, en perjuicio de la innovación, de los juegos que aportan algo nuevo, ya sea visualmente o a través de nuevas mecánicas.

Yo creo que por eso en su momento el Wii tomó a todos por sorpresa. Con una configuración mucho menos potente que sus hermanos de generación logró batir récords de venta. Que el Wii luego haya pasado a segundo plano es otra historia (mi Wii desde hace mucho que acumula polvo), y eso ha sido culpa de Nintendo, pero quedó demostrado que existía un mercado de jugadores aún por descubrir.

El factor que le faltó a Nintendo, que otras empresas como Google y Apple supieron aprovechar, fue abrirse al gigantesco ecosistema de desarrolladores dispuestos a experimentar sobre su plataforma. Ofrecer una plataforma abierta para que cualquier desarrollador pueda hacer un programa para tu plataforma significa que personas como tú o como yo podamos aprender el arte y ciencia de hacer juegos sin pasar por las manos de los tradicionales distribuidores. Para desarrollarle a Nintendo tienes que demostrar una sólida trayectoria de desarrollo, y es sólo después de que eres aceptado que te dan el kit de desarrollo y los manuales. Para desarrollar para Android o iOS sólo necesitas tener el mismo dispositivo que todos usan y comenzar a leer los manuales.

Es cierto, un ecosistema de desarrolladores más grande quiere decir que veremos muchísima más basura, pero también significa que veremos los mejores juegos hechos con las restricciones de hardware impuestas por estos dispositivos. Por mi parte, hace tiempo que dejé de jugar con mi Nintendo DS, y me he encontrado más jugando con mi celular.

Las relativas pocas prestaciones (hasta ahora) de los dispositivos Android y iOS han permitido que nuevos desarrolladores logren mucho con poco presupuesto. Para algunos de ustedes puede ser una afirmación atrevida, pero yo creo que los smartphones han cambiado el terreno para las consolas tradicionales de videojuegos. No estoy diciendo que las consolas vayan a desaparecer, ni mucho menos. Pero les pregunto: si fuesen desarrolladores qué preferirían, ¿desarrollar para una plataforma en la que previamente debes demostrar que eres un desarrollador experimentado, para luego obtener un kit de desarrollo especializado? ¿o preferirías desarrollar para una plataforma en la que sólo basta que obtengas el mismo dispositivo de juego para desarrollar?

Una vez establecido que existe la posibilidad de distribuir lo que puedes hacer, queda por preguntarse: ¿qué juego quisieras ver hecho? si tuvieses las herramientas para hacerlo, ¿no sentirías el impulso de al menos descargarlas y jugar con ellas, sólo para ver lo que puedes hacer? Hacer videojuegos va más allá de ilustrar, hacer arte visual, o incluso programar. Programar es sólo un pequeño componente de todo lo que hace falta para poder completar un juego.

Algunos puristas denuncian que un juego no es un juego si fue hecho con un motor. Como si tuvieses que pasar por los dolores de aprender una herramienta como un rito de maduración. Y no es así, no tiene por qué ser así. Si existen herramientas que faciliten lo que tienes en la mente a un juego en concreto, aprovechemos estas herramientas para impulsarnos, y llegar a hacer juegos nunca antes vistos. Después, si lo que has hecho no te satisface, estará el camino de la programación desde cero para acercarte a esa visión.

Hasta entonces, abogo por ver juegos hechos por gente de todas las partes del mundo, de todas las edades, y de todas las áreas del conocimiento.

Les dejo un listado de aplicaciones gratuitas que pueden utilizar para hacer juegos, incluso de calidad profesional:

Cómo portear una aplicación hecha en Flash Professional para plataformas móviles

Una de las preguntas comunes entre los desarrolladores de Flash Professional es “¿es posible desarrollar para un dispositivo móvil (iOS, Android, BlackBerry PlayBook) utilizando Flash Professional?“. La respuesta corta es “sí”, la respuesta mediana es: “sí, pero hace falta configurar manualmente algunas cosas”. De hecho, con esta misma metodología se puede desarrollar para todas las plataformas móviles. Y la respuesta larga viene a continuación. Sigue leyendo Cómo portear una aplicación hecha en Flash Professional para plataformas móviles

Proponiendo tu idea a un desarrollador: pruebas y tribulaciones

Varias son las veces en las que algún estudiante o gamer entusiasta se acerca a ofrecerme su idea para un videojuego, ya sea porque quiere que se la desarrolle o porque va a representar el negoción que nos va a cambiar la vida a todos. Aunque yo suelo ser muy receptivo ante las ideas que me ofrecen, algunas veces tengo que pararme a explicar que su idea no es interesante. Veamos por qué.

No es un problema de que su idea sea mala ni mucho menos. El problema es que sus fundamentos no han sido siquiera probados y se toman una gran cantidad de suposiciones que no han sido corroboradas. Aunque es cierto que un proyecto de desarrollo de videojuegos debe tener una visión clara de a dónde quiere llegar, al principio es sólo eso, una visión. Entre el inicio y la llegada a esa visión se deben tomar una serie de pasos que finalmente conforman el diseño del juego.

El diseño de un juego no es un documento que uno escribe y se queda inmutable hasta que se distribuye el juego. El diseño es un proceso vivo, altamente dinámico, lleno de pequeños y grandes problemas, en los que las soluciones finales a las que se llegan son producto de un compromiso de todos esos problemas. Quizás ese pequeño detalle que le viste a un juego no fue algo que se le pasó por alto a los diseñadores, sino más bien la mejor solución a la que pudieron llegar. Quizás si hubiesen aumentado o disminuido ese detalle hubiesen alterado fuertemente el resultado del juego.

Los juegos que nos suelen gustar son así porque están completamente orientados a hacernos sentir las estrellas del momento. El ambiente, los controles, hasta la inteligencia artificial, todos están hechos para que nosotros progresemos desde no saber nada sobre el juego hasta ser los reyes que controlan todos y cada uno de los aspectos del juego. Y eso no es casualidad. Como el mago que prepara 700 veces su presentación antes de asombrarnos de principio a fin, el desarrollador de videojuegos tiene que probar y reprobar todo el show que al final el jugador experimentará. Muchas veces durante esa etapa de pruebas los desarrolladores pueden dejar de ver el bosque para concentrarse en los matorrales, lo que puede ser muy bueno si todos esos detalles se suman a emocionar al jugador, o contraproducente si esas cosas al final el jugador no las encuentra.

Así que la próxima vez que te encuentres con un desarrollador, no le vengas de un solo golpe con la próxima idea que va a ser el hit del siglo. Toma una actitud de principiante (la mayoría de los desarrolladores tienen, y deben tener, esta actitud), y haz preguntas. Pregunta qué opina del género que tienes idea, y plantéale tu idea. Muy probablemente comience desde el inicio, un inicio del que tú como jugador no estés consciente: ¿qué motiva al jugador a jugar tu juego?. Pista: no son los cutscenes hermosamente elaborados, ni que se le vean los vellos a los personajes, ni la mejor tecnología 3D que exista en el mercado. Es la conexión emocional que existe entre el jugador, y las acciones que tiene a mano en un momento determinado.

Armando un juego con fisica en Python, Pygame y Pymunk (y II)

En un artículo anterior hablamos de cómo comenzar a utilizar la librería Pymunk y Pygame para hacer simulaciones de movimiento de cuerpos rígidos, utilizando gráficos de líneas sencillos. Nos quedó pendiente hablar sobre los casos en los que necesitamos un poco más de complejidad, cuando queremos utilizar sprites dentro del juego. Luego de hablar sobre lo que tenemos que saber para utilizarlos, hablaremos sobre cómo montar un juego de plataformas utilizando Pymunk.

Jedi Chicken Hell
Fig. 1 - Jedi Chicken Hell, por Javier Gutierrez, Jesús Vasquez y Juan Seijo.

¿Cómo integro Pymunk con los sprites de PyGame?

En PyGame tenemos el concepto de Sprites: elementos que se dibujan en pantalla, que tienen una posición, y una rotación. En Pymunk tenemos dos conceptos: el de Body, que es el centro de gravedad del objeto, y el de Shape, que es la figura que acompaña al centro de gravedad. Para integrar los Sprites con Pymunk, tenemos que echar un poco de cabeza para pensar en las traslaciones y rotaciones de los sprites para que coincidan con los cuerpos.

¿Por qué?, porque tanto Pymunk como Pygame representan dos sistemas de coordenadas, que hay que igualar para que el movimiento se vea correctamente. Por ejemplo, si colocamos una gravedad negativa, digamos -10, y las coordenadas en Pymunk las representamos tal cual como Pygame las utiliza, veremos que los objetos caerán “hacia arriba”. Recordemos que el sistema de coordenadas de Pygame tiene su origen en la esquina superior izquierda de la ventana, con el eje x aumentando hacia su derecha, y el eje hacia abajo, como lo veremos a continuación.

Diagrama de coordenadas de Pygame
Fig. 2 - Sistema de coordenadas de PyGame, con respecto a la ventana que contiene al juego
Coordenadas de Pymunk
Fig. 3 - Sistema de coordenadas de Pymunk. Las coordenadas que se le dan a los Shapes se hacen con respecto al centro de gravedad del cuerpo.

Los Sprites de PyGame le dan al jugador la idea de la forma que tiene el cuerpo visualmente, mientras que los Shapes (las formas) en Pymunk son la representación dentro de la simulación física. Por razones de simplicidad, y esto es lo que suele predominar, se suele ajustar una figura muy simple a un sprite, como un rectángulo. En la figura a continuación se muestra cómo se puede adaptar un Shape de Pymunk (dibujado en negro) a un sprite (dibujado completamente en rojo).

Cómo acomodar un shape de Pymunk con un sprite
Fig. 4 - Se puede hacer un Shape rectangular para acomodar al Sprite (demostrado con la línea negra) o un Shape con una forma más realista. Esto tiene su costo en la simulación.

Por otro lado, en Pymunk tenemos que declarar las coordenadas de un Shape con respecto a su centro de gravedad (ver Figura 3), y el origen de un sprite está en su esquina superior izquierda. Luego, si rotamos con pygame.sprite.rotate vamos a rotar en base a la esquina y no al centro de gravedad. Luego tenemos que mover el centro de rotación hacia el centro de gravedad del sprite.

¿Cómo elaboro un juego de plataformas con Pymunk?

Un juego de plataformas con física 2D realista necesita que sus componentes se comporten como tal. Tendríamos una parte gráfica hecha con Pygame, y el comportamiento del objeto mismo con Pymunk. Damos como ejemplo el juego cuyo screenshot está al inicio de este artículo, Jedi Chicken Hell, el cual tiene algunos elementos físicos incorporados al juego de plataformas, y se puede descargar por este enlace.

En este caso todos los elementos del juego tienen una información gráfica, como el sprite que utilizan y qué transformaciones gráficas emplea, y una información física, que es la que hemos explicado en estos artículos.

Otro ejemplo concreto: un defensor de asteroides Esto es un prototipo de juego de defensa de asteroides. En este juego, los asteroides caen por gravedad y golpean las esquinas, para luego caer por el hueco que está dispuesto debajo. La nave gira hacia la derecha o la izquierda, y está fija en ese punto. De esta manera, cuando los asteroides le golpean, la nave comienza a girar rápidamente, aunque no se sale de su lugar. Puedes descargar el código en Python de este juego aquí. (rar, 7.22MB)

La mayoría del código lo he dejado en los paquetes, para que puedan ser estudiados por los lectores. Espero que les sea de utilidad.

Un modelo de negocios para videojuegos en Venezuela

Foto por Inti

Llega un momento en el que uno debe pensar en cómo conviertes eso que te gusta en un negocio. Conseguir un modelo de negocios no es una tarea sencilla para ningún tipo de emprendimiento. Las complicaciones aumentan para un emprendimiento de videojuegos, que tiene que ver con el entretenimiento, una necesidad no básica, a diferencia de otros tipos de software.

En Venezuela existe el agravante de que la piratería está sumamente extendida. Este tipo de mercado, en el que un producto con mucho volumen de venta es un indicativo de su buena calidad o utilidad, realmente no nos sirve de mucho a los que vivimos de vender software. No es el objetivo de este artículo tratar este problema, que tiene raíces sociales y culturales.

Modelo publicitario

Si nos vamos por la primera solución que nos venga a la cabeza a esta situación, entonces tendríamos que pensar en la publicidad. Al estilo de las versiones gratuitas de Angry Birds, o muchos juegos basados en Flash, el juego se distribuye gratuitamente y nuestra retribución será a través de un sistema de publicidad que contratemos o hagamos de cero. Si tu juego es un éxito, más gente lo jugará y tendrás más ganancias por publicidad,y si se “piratea” el juego, el ingreso será aún mayor, simple, ¿no? Pero esta metodología tiene sus consideraciones que vamos a ver a continuación.

Dejemos de lado de antemano la opción de desarrollar un sistema de publicidad por ser un proyecto que requiere por sí mismo un gran esfuerzo. Si a eso te quieres dedicar, bien podrías sincerarte y decir que no estás haciendo un juego. Dicho esto, sistemas de publicidad para Flash existen desde hace algún tiempo, como Mochi Media o Armor Games. Emplear uno tiene la ventaja de que el sistema ya está hecho, e incluso algunas de ellas tienen sus métodos para promocionar los juegos más populares o rentables. Por otro lado, el gran porcentaje del ingreso por publicidad en estos sistemas se los lleva la empresa, y esto nos deja en un compromiso muy fuerte si quieres independizarte, y es la fuente de poder de muchas de estas plataformas.

Daniel Cook, desarrollador de videojuegos, lo explica muy bien en inglés. Ya sean las plataformas para Flash, o Facebook, o las tiendas de aplicaciones del iPhone, o de Android, o de las consolas populares, existe un ciclo de vida en todas ellas, en las que inicialmente deben ganar popularidad. Para ganar esta popularidad, deben esperar a que aparezca un buen juego en esta plataforma, que sea popular y dé dinero. Cuando sale este juego, se convierte en el Shirley Temple de los desarrolladores: la plataforma promociona el juego hasta la saciedad, haciendo que otros desarrolladores sigan su ejemplo (¡podrías ser tan exitoso como ellos!) y la gran demanda de poner su juego en la plataforma le da a los dueños de la misma un mayor poder de negociación.

Esta foto sólo está para decirte que leas la presentación de Cook. Vale la pena.

La realidad es que estos mercados están muy saturados, por lo que los que se independizan son únicamente los que tienen una popularidad muy grande. Unos pocos puestos debajo del Top 10, y la rentabilidad del juego disminuye exponencialmente. Con esto no quiero decir que no se utilicen las plataformas, después de todo, se puede percibir algún ingreso, pero definitivamente no te dará para comer para el resto de tu vida. Eso, o haces un juego con un timing impresionante.

Una nota aparte: la piratería es posible con los juegos en Flash. Es común en las páginas donde la publicidad es servida fuera del juego, escuchar los casos donde un portal republica el juego en su propia página, con sus propios banners publicitarios. Los desarrolladores toman medidas para evitar la reproducción del juego fuera de dominios aprobados por el mismo.

Advergames

Los advergames tienen un apartado especial. Los advergames son hechos por desarrolladores a petición de agencias publicitarias, que enmarcan el juego dentro de una campaña, por lo que el juego se beneficia del público que se interesa por la misma. La retribución económica suele venir con la publicación del juego, y es una cantidad fija previamente acordada, por lo general sin otros ingresos posteriores.

Screenshot de la página de Maizoritos, con un juego hecho en Venezuela.

En Venezuela ha sido una buena fuente de ingresos para varios desarrolladores. Según Manuel Herrera, desarrollador de videojuegos, el interés por hacer advergames ha aumentado en los últimos 5 años, y casi todas las agencias de publicidad de Caracas tienen proyectos que involucran elaborar advergames. El año pasado en la ceremonia de los premios ANDA, Asociación Nacional De Anunciantes, otorgó por primera vez premios para la categoría de juegos online.

Entre las desventajas que se pueden encontrar al hacer esta clase de juegos es que los tiempos de elaboración de una campaña publicitaria son extremadamente cortos. Jorge Padua, desarrollador de videojuegos, considera que las agencias deben darle una mayor importancia a la elaboración de juegos en comparación con el método tradicional de comerciales en televisión. Debido a la poca importancia dada y a los apretados tiempos, hacer un juego novedoso se percibe exageradamente riesgoso por el tiempo de desarrollo, yéndose por clones de juegos conocidos, o con mecánicas sencillas y probadas. Depende del desarrollador elaborar una propuesta que pueda cumplir con el tiempo que especifique la agencia.

Foto de un tigre, por DrBartje. Tiene cierta relación con el tema.

Comercializando los juegos

Hablemos de aquellos que tienen una idea para un juego que quieren comercializar. O de aquellos que quieren lanzar un juego que involucre propiedad intelectual nueva. O de alguien que ha encontrado la pericia y la utilidad de desarrollar herramientas para hacer juegos. O incluso de personas que ya llevan un aprendizaje como empresarios, y que sienten que deben armar un plan que les permita un ingreso más estable. En Venezuela existen empresas que se ubican en estos grupos.

Screenshots de Gwen The Magic Nanny, por Teravision Games y Grimm, por Hecticus

Los casos de Teravision Games y Hecticus Software me parecen interesantes porque apuestan por el outsourcing de partes específicas de un proyecto (desarrollo o arte) para empresas en el exterior. Ya sea construyendo el software o haciendo trabajo gráfico, esta es una buena manera de tener un ingreso preestablecido en un contrato.

Entre las desventajas que veo, es que se hace necesario elaborar una red de contactos (las empresas no van a llegar de afuera a buscarte), además de depender de la situación de las demás empresas. La situación de crisis como la que ocurrió en 2007 afectó la industria de los videojuegos, con repercusiones en todas las empresas a todos los niveles.

Juan Carlos Ramírez, de Hecticus, propone la especialización de las actividades de la empresa. En el caso de Hecticus, una empresa cuyo fuerte es el desarrollo, se asocia con compañías que se dedican a la parte creativa y del game design.

Por otro otro lado, está la elaboración de herramientas para desarrolladores. Generalmente estas son empresas que ya han tenido experiencia desarrollando juegos, y en medio del proyecto han elaborado herramientas que posteriormente pulen y comercializan como productos. En Venezuela también tenemos eso: The Complot elaboró una herramienta de debugging para XNA llamada Gearset. Fue lanzada la semana pasada, y tiene 15 días de trial.

Screenshots de Gearset, de The Complot

Para las empresas que desean hacer un juego con nueva IP (propiedad intelectual, léase con personajes e historias completamente originales, y no tomadas de una licencia) el camino es bastante cuesta arriba. En esto coinciden Jorge Padua, desarrollador de videojuegos, y Enrique Fuentes, director de Teravision Games. Se suele seguir el modelo de Editor (Publisher, en inglés) – Desarrollador, en el que el desarrollador se encarga de llevar a cabo de elaborar el juego, y el editor de la parte de comercialización, distribución y mercadeo. En muchos casos el editor financia también el desarrollo del juego.

En palabras de Jorge, el problema está en que un desarrollador que no tenga un récord de desarrollo probado tiene que elaborar el juego, o el demo de un juego, por su propia cuenta, lo cual requiere en el mejor de los casos un mínimo de 6 meses de desarrollo. Luego de hacer esto, se pasa a una etapa en la que hay que convencer al editor de financiar el proyecto. Todo esto sin recibir ingreso alguno (porque no se tiene producto alguno para comercializar).

Tanto Jorge como Enrique afirman que hace falta en Venezuela que exista capital de riesgo (o Venture Capital, en inglés) que sea capaz de invertir grandes cantidades de dinero a cambio de parte de las ganancias del proyecto. Enrique pone como ejemplo un país como Canadá y Jorge, a Colombia, países que están haciendo grandes esfuerzos para atraer empresas del sector tecnológico.

Considero que es tarea de todos los venezolanos mejorar las condiciones del país para que veamos esta clase de inversiones.

Más allá del juego como un producto: juegos como servicio

Los juegos como servicio es un área de la industria que todavía se está definiendo, puesto que es algo que se está aplicando desde hace muy poco. La idea principal detrás de este modelo de negocio está en que en vez de vender el juego como un producto único e inalterable una vez lanzado, el juego se actualice a lo largo del tiempo y en respuesta a la reacción de la audiencia que lo juega. Esto no aplica para los juegos que hasta ahora se actualizan solamente para corregir bugs. Esto abarca la actualización de contenido y mecánicas dentro del juego. Puede que el juego necesite o no una conexión constante a Internet.

En un artículo anterior habíamos hablado de juegos que necesitan una conexión a Internet. Por su estructura, el control de acceso reside en el servidor, por lo que se dificulta la tarea de poder acceder al juego sin pagar, y paliando así el problema de la piratería. Sin embargo, un juego como éste es complejo, hará falta un plan de ejecución para todo el ciclo de vida del juego, desde su inicio hasta darle continuidad y frescura a lo largo del tiempo, si es que tiene éxito.

Baboom Games surgió a partir de Teravision Games como una empresa para hacer juegos sociales.

¿Por qué es complejo? Sus implicaciones van más allá de los aspectos meramente técnicos de los que hablamos en ese artículo. Según Enrique Fuentes, se debe pensar en cómo recoge dinero ese juego, lo que se conoce como esquema de monetización. A diferencia de un producto empacado en una caja, la mayoría de los juegos llamados sociales (léase: juegos de Zynga, Playfish, o de Baboom Games) se pueden jugar gratuitamente, obteniendo dinero a través de los micro-pagos.

Además de ello, Enrique considera que el costo de la infraestructura necesaria para escalar el juego en grandes dimensiones puede estar bastante fuera del alcance de desarrolladores noveles.

Finalmente, menciona la importancia de incluir el importante rol del analista. Como se dijo inicialmente en esta sección, los juegos como un servicio necesitan responder ante la audiencia, por lo que se hace necesario la medición de sus actividades. Esto requiere un conocimiento (en estadística, principalmente) y una serie de herramientas para este fin.

Les dejo un video que se asemeja a lo que es el desarrollo de un servicio online: (enlace al video)

El caso de la repatriación

Aquí comenzamos a notar las primeras piedras de tranca ante la venta de un producto o servicio, ya sea por ventas de modelo publicitario u otros. Debido a que la actividad de desarrollo de videojuegos no está muy extendida, no tiene sentido servir solamente al casi inexistente mercado venezolano: se hace necesario vender al exterior también. Pero los venezolanos estamos sujetos desde 2003 a un control de cambios que impide la libre circulación de dólares en el país, una situación que ha afectado hasta a compañías con productos exitosísimos, los cuales ante la incapacidad de repatriar su dinero, toman la decisión de retirarse del mercado. Los desarrolladores de tecnología están en un negocio que les permite ganar dinero en dólares, así que podrían convertir ese ingreso en Bolívares, pero la diferencia cambiaria representa una pérdida de capital y una desventaja ante desarrolladores de otras partes del mundo.

Dolores de cabeza para el venezolano que hay un mundo más allá de Venezuela

Probablemente me arriesgue a que los comentarios se vuelvan un campo de batalla de críticas a CADIVI, pero el hecho es que la cantidad tan absurda de burocracia que hay que atravesar en esta institución previene a pequeños empresarios de poder acceder a la moneda que nos permite nada más y nada menos que comerciar con el resto del mundo.

Bonus: la Ley de Prohibición de Videojuegos y Juguetes Bélicos

Una razón de peso por la que los videojuegos no han despegado en Venezuela ha sido la inseguridad jurídica. Esta inseguridad llegó a su punto máximo cuando en 2009 se aprobó la Ley de Prohibición de Videojuegos y Juguetes Bélicos, sobre la que hemos hablado en este blog desde hace tiempo.

Originalmente cuando escribí este ensayo, no la mencioné, y fue lo primero sobre lo que mis correctores me llamaron la atención. Que por qué no había escrito sobre ella.

Fundación Filantropía

La omisión no fue intencional, aunque tampoco fue por ignorancia sobre el asunto. He estado involucrado como parte de la Fundación Filantropía desde sus inicios, y hemos hecho un duro trabajo para que los videojuegos sean reconocidos como una actividad y un hobby legítimos dentro del país. Hemos conversado con diversas instituciones del país y nos hemos dado cuenta de varias cosas:

  • SENCAMER, la institución encargada de la metrología en el país, y en particular de los códigos arancelarios que identifican los diversos productos que se importan y pasan por aduana, no posee un código arancelario claro para los videojuegos.
  • No existen cifras oficiales en la importación de videojuegos y consolas. Las consolas que se importan oficialmente en el país son catalogadas como “línea marrón”, no muy distinto a un reproductor de DVD. Esto significa que la mayoría de las consolas que están en el país son importadas por particulares.
  • En general, se ignora completamente la actividad de desarrollo de videojuegos. No se considera como algo que se esté haciendo en Venezuela.

Esto no significa que no se pueda hacer nada en el campo de desarrollo de los videojuegos. Cuenta una parábola que dos vendedores de zapatos que van a un país africano, y cada uno telegrafía de vuelta a la empresa. Uno dijo “no hay oportunidad de para vender, nadie tiene zapatos”, y el otro dijo “¡gloriosa oportunidad para vender!, nadie tiene zapatos aún”. Existe aún mucho por hacer, y la motivación está en ver que la actividad de desarrollo de videojuegos sea una actividad factible. La manera de influenciar en el país es dedicándose a desarrollar, y no sólo me refiero a videojuegos, sino a básicamente cualquier tipo de empresa.

Conclusión

En conclusión, no hay camino fácil para emprender con los videojuegos. Sin embargo, existen oportunidades y seguirán aumentando a medida que hayan más desarrolladores y gente demostrando talento. Existen alternativas para desarrollar juegos. Obviamente no las conozco, porque si no ya la estaría aplicando yo y estaría nadando en dinero.

José Rafael Marcano, presidente de Mediatech Games Studio, comenzó operaciones en los años 90, y su producto educativo estrella “Umi”, vendió 200.000 copias hasta el año 2005. Cuenta que la piratería y la diversificación de las plataformas distintas a las PC detuvo esta modalidad de negocio. Ahora está buscando desarrollar para iOS y Android, y cree firmemente en desarrollo de su propia IP, haciendo personajes nuevos y situaciones nuevas, ya que aunque es riesgoso, si el negocio tiene éxito, el éxito es sólo de él y su empresa. También trabaja desde 1995 con el Museo de los Niños, cosa que me parece genial.

Hace falta mucha creatividad y concentración para poder determinar un modelo viable. En el mundo de los negocios casi nadie implementa el modelo que pensaba inicialmente, sino que se lanza una versión inicial, y las sucesivas conversaciones formadas a partir el producto le permiten al emprendedor ir refinando el producto y orientarlo hacia el éxito. Que este ensayo sirva de punto de partida para vuestras conversaciones.

* Agradecimientos a Enrique Fuentes, Manuel Herrera, José Rafael Marcano, Jorge Padua, Jorge Palacios, Julián Rojas, Cristian Caroli, Juan Campa y Juan Carlos Ramírez por el excelente feedback que recibí de ellos al mostrarles un preliminar de este ensayo.

Charla de Google I/O: Programación de juegos con Google Web Toolkit

Google está apostando a HTML5 fuertemente. Veo con buenos ojos todo el esfuerzo que se está haciendo para equiparar las herramientas que se disponen en estas tecnologías abiertas con otras que existen desde hace ya algún tiempo (como Flash), y seguiremos viendo cosas muy interesantes.

En el siguiente video, veremos cómo se puede utilizar Google Web Toolkit, y una nueva librería llamada ForPlay para crear aplicaciones en HTML y JavaScript utilizando el lenguaje Java. El enlace al video está acá y el video lo vean embebido a continuación. También está disponible este resumen escrito de la presentación (PDF).

Construyendo castillos en el aire: cómo no comenzar a hacer tu primer juego

air-castle 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.

Publicada traducción al español del Nivel 9 de Game Design Concepts

El trabajo de traducción al español del excelente curso online gratuito de diseño de juegos Game Design Concepts continúa. Ahora el Nivel 9 sobre Historias y Juegos ha sido publicado y se une a la lista de artículos:

Además de ello, tenemos a varios traductores que se han unido al equipo, encargado cada uno de un artículo. Le doy la bienvenida a: Julián Rojas, Luis Miguel Delgado, Nadia Labeikovsky, Milagro Feijoo y  Guillermo Schiappucci. Yo continúo con el trabajo en otros niveles y editando y coordinando el trabajo del equipo.

Nos hemos conseguido con una interesante discusión en Twitter sobre la traducción de ciertos términos. Por ejemplo, gameplay, ¿se traduce en jugabilidad, o mecánica? Si se traduce en mecánica, ¿cómo queda el término mecánica, dinámica y estética en el marco MDA? Esta es una discusión que continúa, y no hay aún términos establecidos (tal como en la discusión en inglés tampoco los hay). Lo que sí sé es que lo que estamos escribiendo tiene sentido: he escuchado a diseñadores de juegos como César Sánchez, que recientemente lanzó el set básico de su juego de robots Mekawing, hablar de su trabajo, y aunque no tienen educación formal sobre diseño, los términos que emplean son familiares. Creo que esto es algo bueno, y representa una oportunidad a todos los que estamos interesados para establecer un vocabulario común, y seguir difundiendo el diseño de juegos como un campo de estudio.

Estructura de un juego de Facebook: ¿cómo está hecho? ¿cuál es la tecnología detrás?

Ejemplos de juegos sociales
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.