Desarrollando un videojuego sencillo (Parte I – Introducción)

Durante mi carrera profesional, he tenido la fortuna de ir probando varias de las distintas vertientes que tiene el campo de las TI. Empecé como técnico de hardware, de ahí pasé a administrador de sistemas y, finalmente, llevo casi cuatro años desarrollando software, con la suerte de haber podido trabajar en proyectos de diversa naturaleza. Durante todo este tiempo, además, he ido complementando mi formación con proyectos personales, especialmente en el área de los Sistemas Operativos. Pero, a pesar de ello, sigo teniendo una espinita clavada: desarrollar un videojuego desde cero. Así pues, he decidido ponerme manos a la obra y, de paso, contar mi experiencia en este blog.

Definiendo el proyecto

En primera instancia, mi intención es hacer un videojuego de plataformas, al estilo de clásicos como Super Mario Bros. y Mega Man (guardando las distancias, obviamente). Pero, a su vez, mi objetivo es que la plataforma principal del juego sean los móviles y tabletas. Esto me lleva al primer dilema: si bien dichas plataformas tienen potencia de sobra para mover un videojuego de este tipo, los controles basados en pantallas táctiles no permiten una interacción precisa y rápida, y ésta es imprescindible para tener una experiencia de juego fluída.

Por lo tanto, es necesario adaptar el planteamiento inicial a un modelo que ofrezca una experiencia similar, pero que no requiera tanta precisión en los controles. De las posibilidades que encajan en esta definición, la que más me atrae es hacer algo similar al sistema del juego Toki Tori. En lugar del esquema tradicional, en el que controlamos directamente todas las acciones del personaje, en este modelo marcamos la ubicación a la que queremos mover el personaje, y mientras éste se desplaza podemos llevar a cabo acciones secundarias (saltar, disparar…) tocando en un menú. Adicionalmente, este sistema nos permite limitar el número de acciones de un determinado tipo que podemos llevar a cabo, lo cual hace que el juego se acerque más al género de puzzle, más apto para las plataformas móviles.

Delimitando el proyecto

Uno de los errores más habituales a la hora de emprender un nuevo proyecto, es el exceso de ambición. Con más frecuencia de la nos gustaría reconocer, ésta nos lleva a ignorar las limitaciones impuestas por los recursos que disponemos (en desarrollo de software, el recurso principal es el tiempo), para marcar objetivos irrealizables que a menudo podrían compararse con intentar rehacer el túnel de Somport con una cucharilla. Ésta es una fuente permanente de frustración para un programador, y una de las principales causas de los miles de proyectos húerfanos que pululan por la red (y yo también tengo unos cuántos de estos en mi haber).

Es por ello que es fundamental estimar previamente los recursos que vamos a poder destinar, y dimensionar el proyecto de forma acorde. En mi caso, sólo dispongo de unas pocas horas a la semana de mi tiempo libre, por lo que debo ser extremadamente pragmático a la hora de definir lo que quiero hacer. Por ello, me voy a imponer las siguientes restricciones:

  • El motor del juego será 2D, basado exclusivamente en el pintado de sprites en la pantalla, usando las librerías base de la plataforma.
  • El mapa de cada nivel ha de caber en la pantalla. Nada de desplazamientos ni cámaras flotantes.
  • Aunque la física realista está muy de moda, toda la física del juego será simulada.
  • Todo el arte gráfico debe estar ya creado. Por fortuna, hace poco el usuario Kenney de OpenGameArt liberó unos gráficos muy, muy jugosos (Platformer Art Deluxe).

Estas limitaciones no garantizan que vaya a terminar el proyecto con éxito, pero al menos minimizan el riesgo de que me queme prematuramente, al posibilitar que cada vez que termine una sesión de trabajo, el avance sea visualmente perceptible. No hay proyecto más frustrante que el que parece no progresar nunca.

¿Con o sin prototipo?

Desde que empecé a desarrollar software de forma profesional, tomé la costumbre de hacer un prototipo previo al desarrollo principal, especialmente si se trata de un área de trabajo nueva para mí. Más adelante, la lectura de The Pragmatic Programmer: From Journeyman to Master confirmó que hacer prototipos es algo común en muchos equipos de desarrollo, e incluso un requisito ineludible para algunos.

A grandes rasgos, un prototipo es un desarrollo de software, en un lenguaje de alto nivel y sin mucho orden, partiendo de una idea general de lo que se quiere hacer. Dicho desarrollo permite afrontar anticipadamente algunos de los retos que te vas a encontrar en el proyecto, minimizando (aunque no anulando por completo) el riesgo de que el diseño del producto final sufra algún defecto crítico que bloquee el desarrollo.

Por otra parte, para un programador (o, al menos, para mí), hacer prototipos es divertido. Te permite centrarte en las cuestiones fundamentales del desarrollo, y ver rápido los resultados de tu trabajo.

Siendo ésta la primera vez que hago un videojuego, y teniendo en cuenta lo costoso que es depurar sobre Android, parece natural hacer un pequeño prototipo que implemente las funcionalidades básicas. Para ello, voy a emplear Python y PyGame, un excelente framework que te abstrae de las tareas gráficas de bajo nivel, para poder centrarte en la mecánica del juego.

Adicionalmente, no está de más contar con un buen libro que te introduzca en la materia. En este caso, voy a emplear el excelente Making Games with Python & PyGame, que se puede comprar en Amazon o leer online gratuitamente.

Continuará…

Y hasta aquí las cuestiones filosóficas de este proyecto. A partir del próximo artículo, empezamos a meter las manos en harina con el prototipo.

Puedes continuar leyendo la segunda parte: Desarrollando un videojuego sencillo (Parte II – Bucle principal y mapa del nivel)

Leave a Reply

Your email address will not be published. Required fields are marked *