En esta tercera entrega de esta serie de artículos os hablo de la importancia de la creación de unos bocetos previos de nuestro juego, y de cómo estos se convierten en el juego final. En la segunda parte del artículo os explicamos cómo hemos desarrollado nuestro último juego, Jumping Balls, y os hablo de los problemas que nos fuimos encontrando y de sus soluciones.

Creando un juego para Android (I): Consejos y desafíos

Creando un juego para Android (II): La investigación del mercado

¡¡ Comenzamos !!

Cuando hablamos de bocetos se nos viene a la cabeza un dibujo en un papel hecho con un lápiz. Pero hoy en día el concepto de boceto puede ser otra cosa. Si manejamos mínimamente Photoshop puede ser incluso una maqueta desarrollada en esta aplicación, o si tenemos una tableta para dibujar podemos hacerlo en ella. Es decir, no tenemos por qué usar lápiz y papel, aunque tal vez esto sea lo más rápido.

En nuestro caso, hacemos mucho de programas de diseño, y del papel digital, es decir, dibujar en la propia pantalla. No se trata de ganar un premio de pintura, sino de ser capaces de establecer todas las relaciones entre los elementos con los que el usuario tendrá que interactuar.

Pongamos de ejemplo una pantalla principal, con una serie de botones llevando hacia Facebook, Twitter, Google+, la propia web, la tabla de líderes, el botón para iniciar el juego y el botón para salir del juego, por ejemplo. En nuestro boceto pondremos todos estos botones, más o menos colocados y montados, y con flechas que indiquen hacia qué otras pantallas van, a modo de árbol de navegación.

De hecho, a la hora de explicar a los programadores qué queremos hacer, es mucho más sencillo hacerlo sobre una imagen que sobre un documento de requisitos. Tampoco estamos hablando de crear un Call of Duty, cuya complejidad hace imprescindible el uso de otras tecnologías. Estamos creando un videojuego sencillo, que podamos abordar.

Bosquejar la historia: ¿qué tener en cuenta?

Otros datos que hay que tener en cuenta a la hora de bosquejar la historia son los niveles. Aquí seguramente nos tendremos que apoyar en documento escrito para describir bien los niveles, pero si que podemos bosquejar cada uno de los niveles, imaginando cómo sería el juego.

El siguiente paso será bosquejar las pantallas de juego, y las de salida del juego (nivel completado, juego completado, game over, etc.).

Una vez tengamos el juego estático, tendremos que idear las animaciones que vayamos a introducir en el juego. Las animaciones es lo peor a la hora de transmitir nuestra idea al equipo de desarrollo, porque nosotros tenemos una cosa en mente, y sin querer podemos estar transmitiendo otra, así que todos los esfuerzos que podáis hacer aquí para que todo quede claro serán bienvenidos. Incluso si habéis visto animaciones parecidas en otros juegos, podéis ponerlas de ejemplo. Y ojo, cuando hablo de animaciones, también hablo de efectos especiales.

A partir de este momento es cuando entran los diseñadores a crear el juego, para darles a los programadores todo lo que necesiten.

Es posible que tú seas todo, ideólogo, grafista y programador. Bien, en este caso necesitarás muchos menos documentos. Pero normalmente no es así, así que aprovechad cada letra escrita y cada dibujo dibujado para dejar todo lo más claro posible.

Línea de trabajo a la hora de hacer un juego

  • 1. Idear el juego. Buscar una idea que pueda ser interesante para desarrollar. Ya lo vimos en el artículo anterior.
  • 2. Bosquejamos el juego haciendo las pantallas en pantalla táctil, básicamente. También se va creando un documento de texto que será desarrollado paralelamente a esta fase y la siguiente.
  • 3. Diseñamos el juego acorde con lo anterior, desarrollando todos los sprites, fondos, animaciones, efectos, etc.
  • 4. Los programadores se encargan de montar todo esto. Ellos tienen el documento de texto y todos los recursos.
  • 5. Como paso final se juega al juego y se monta a música y los efectos sonoros que le puedan ir bien.
  • 6. Se depura el juego.
  • 7. Una vez depurado todo, se buscan los sitios donde introducir la publicidad, si fuera necesario.
  • 8. Se lanza el juego.

Como podéis apreciar, los pasos duros, 2, 3 y 4, giran alrededor de la idea del boceto, que vamos modificando a medida que el juego va tomando forma, hasta que el boceto se convierte en un diseño funcional que es el punto de partida de los programadores.

Seguramente la fase 2 y 3 se mezclen, y se hagan varias veces, es decir, que habrá que volver una vez y otra sobre ellas para irlas depurando.

Cuanto más tiempo le dediquemos a estas fases, mejor quedará el juego final, y más tratable será el código de la programación.

Cuando estamos desarrollando de manera indie juegos no podemos permitirnos el lujo de la regla no escrita del mundo de desarrollo de software, que dice que el 80% del tiempo de trabajo de un programador se va en depurar fallos que no han sido tenidos en cuenta antes, o errores que emergen de un mal análisis, y el 20% restante lo dedica a desarrollar código nuevo. Nosotros no podemos soportar esos ratios. Como mínimo, han de invertirse. Y por tanto, para ello sólo se necesita una correcta planificación.

Un ejemplo real: Jumping Balls

Jumping Balls es nuestro último lanzamiento. La idea del juego surge de la apetencia por nuestra parte de querer desarrollar un runner vertical, que ocupe poco espacio y que sea sencillo de controlar, es decir, que no tenga más que dos botones, por así decirlo.

Hay muchos juegos de tipo runner vertical. Nosotros hemos optado por desarrollar unos gráficos super sencillos, porque queríamos darle protagonismo al propio juego. El jugador controla, pues, una bola. Y pulsando en la pantalla la bola sale rebotada en tres vías. Si pulsas debajo de la bola, rebotará hacia arriba, si pulsas a la derecha de la bola, sale rebotada a la izquierda, y si pulsas a la izquierda de la bola, sale rebotada a la derecha.

Os animo a probarlo. Si os hacéis con los controles, engancha. Eso sí, no es sencillo.

Así que esa fue la idea. Una vez nos ponemos a bosquejarla nos preguntamos cómo hacer el efecto de movimiento vertical. Normalmente lo que se mueve es el fondo. Nosotros hemos prescindido de fondo, y lo que movemos son los laterales, de arriba a abajo. Y jugamos con esos laterales dándoles colores aleatoriamente. Además, para hacer el juego más interesante establecemos un sistema de puntos. Si la bola rebota contra un lateral de su color, suma puntos. Si rebota contra un lateral de otro color, resta puntos.

¿Qué más añadir? Pues enemigos. Pero la bola no disparará. Es un juego de habilidad, así que hay que esquivarlos. Por tanto hay que añadir enemigos poco y a poco. Al principio los ponemos estáticos. Cuando jugamos las primeras betas del juego decidimos que debía de haber enemigos móviles, porque en otro caso se hacía muy sencillo.

¿Qué más elementos hay que añadir? Las típicas estrellas y las típicas monedas, que nos ayudarán a confeccionar las misiones, 23 en total en su primera versión, que se deben de completar para terminar el juego.

Pero todavía quedaba un nuevo elemento. Las veces que la bola rebota en las paredes. Con este, ya tenemos 4 elementos para confeccionar los diferentes niveles: Sumar puntos, recolectar estrellas, recolectar monedas, y con un máximo de toques en las paredes.

Lo siguiente era definir cuándo la bola «moría». La bola muere al caer por la parte inferior de la pantalla o salirse por la parte superior un número determinado de veces (3 cuando se escribe este documento). También cuando choca un número determinado de veces contra los enemigos.

Una vez hecho esto, se probó de nuevo el juego, y decidimos bajar la complejidad de los niveles iniciales, para que estos niveles sirvan al jugador de «entrenamiento».

FX, efectos especiales del juego

Después de esto, hay que ponerle los FX, los efectos especiales al juego. Ya sea de sonidos como de gráficos (explosiones y demás). Y lo último es una música que le vaya bien al juego. Proporcionalmente, esta tarea fue la que llevó más tiempo. Al final compramos dos bandas sonoras, y una la usamos para el menú y la otra para el propio juego. Encontrar las bandas sonoras nos llevó dos días de una persona dedicada a escuchar músicas. Os aseguro que se te pone la cabeza como un bombo, pero si no disponéis de un compositor en el equipo, esta es la mejor opción.

Pero las depuraciones no terminan nunca. Después de jugar varias partidas le dimos una vuelta de tuerca a la idea. Creamos un poder para la bola: El escudo, o casco. Cuando la bola lo tiene, los golpes contra las paredes y los enemigos le hacen menos daño. Y además el cogerlo supone sumar puntos.

Además, introdujimos este nuevo elemento en las características de los niveles, en forma de «logra esto sin coger ningún escudo».

También depuramos un poco el interface, y pusimos el botón volver y el de pausa del juego, que en las imágenes que veis arriba estaban colocados en la parte inferior, en la parte superior, y así evitamos los clics indeseados.

La última depuración fue el nombre

Al final se quedó con Jumping Balls, porque siendo esa la primera opción se descartó para llamar al juego «Balls Jump», pero es que realmente eso no significa nada, y volvimos a Jumping Balls, aunque ya hay varios con ese nombre, pero da igual, porque este nombre define o se acerca a la idea de lo que el usuario se encontrará dentro.

Esta es la historia de la creación de Jumping Balls. Espero que os haya gustado este artículo, y que descarguéis el juego. Y lo genial sería que pudierais ayudarnos en la distribución del juego, que es lo más complejo para nosotros, y si ponéis un link en vuestro Facebook o en vuestro Google+, pues sería simplemente genial. Y si además nos podéis dar las 5 estrellas y un +1 dentro de la ficha del juego, pues estupendo.

Termino diciendo que para la gente que piense que este artículo es publicidad encubierta, decirles que no es así. No hay nada encubierto. Yo escribo para El Androide Libre, pero siempre desde mi perspectiva, con mis experiencias, y obviamente hablo de los juegos que hacemos en mi empresa. No puedo hablar de cómo se hizo Candy Crush, pero sí de cómo se hizo Jumping Balls.

Además, escribir este artículo de 7 páginas de Word, ha llevado más de una semana de depuraciones. Es decir, que no es precisamente publicitario. Quiero ofrecer buenos artículos, que ayuden a gente que como a mí, se han visto sin información sobre el mundo del desarrollo de videojuegos, al menos en español y de calidad, y quiero ayudar a echar luz sobre esto. Y tengo que deciros estas palabras porque en otro de nuestros artículos hubo una opinión de alguien al que no le parecía bien que enlazásemos hacia nuestra web. Creo que eso está fuera de lugar, porque sólo de ver las extensiones de nuestros artículos el lector se da cuenta de que los artículos no son anuncios publicitarios, y que los hacemos con mimo y dedicación.

Personalmente os digo que cuando te has tirado una semana escribiendo, borrando, volviendo a escribir, y volviendo a borrar, este tipo de opiniones me dejan pensando que hay gente que nunca se conformará con nada. Pero bueno, por el otro lado tenemos la gente a la que sí le gusta lo que escribimos, y a la que le resulta útil. Se ve en las veces que se comparte el artículo o en los correos que me llegan preguntando por cosas que he escrito.

Game Maker, el programa utilizado para el desarrollo

Para terminar este artículo os tengo que decir que Jumping Balls está desarrollado con Game Maker, y el equipo de desarrollo ha sido un jefe de proyecto que ha generado la idea inicial, un analista que ha desarrollado el documento de carga del proyecto, una compra de recursos como sonidos e imágenes y un diseñador gráfico que ha modificado parte de esas imágenes que hemos utilizado, un programador y un jefe de programadores (como me gusta llamar a la persona que controla únicamente el equipo de desarrollo, y que además es también programador). Y por fin, hemos utilizado 3 beta tester, es decir, 3 personas que se han dedicado a probar el juego añadiendo ideas nuevas que le han aportado más frescura.

Algunos de estos roles han sido desempeñados por la misma persona. En total, en este proyecto han trabajado 5 personas diferentes, sin contar con las personas externas que han desarrollado imágenes, música y efectos especiales de sonido.

El tiempo de desarrollo desde la idea inicial hasta la versión final subida en Google Play ha sido de un mes, y la mayoría del tiempo ha sido para cambiar cosas y depurar.

Espero que os haya gustado el artículo.

¡ Hasta la próxima !

Ramón Egido es CEO de Syncrom España Solutions, empresa española que comercializa juegos para Android desde http://www.SyncromEntertainment.com. Su página de juegos en Google Play es https://play.google.com/store/apps/developer?id=SYNCROM%20ENTERTAINMENT. Sus juegos son principalmente juegos educativos y de entretenimiento para niños, aunque han comenzado a desarrollar juegos para más adultos, como Conquistando la Isla Pirata, El Arquero y Acertijos y Adivinanzas.