Segundo intento de computer game (burning city iii)

Hemos planteado el juego siguiendo la filosofía de Lean Game Design comentada en la entrada del 24 de septiembre de 2014, esto es, empleando código ya existente así como sonidos y gráficos de fuentes gratuitas. Además nos hemos centrado en un sólo nivel que sea jugable, prescindiendo de momento de pantallas de introducción, otros niveles y detalles que sólo hará falta desarrollar en caso que el juego resulte mínimamente entretenido.

El código lo estamos desarrollando en Python 3.2. con el IDE Ninja 2.3 usando las librerías de Pygame y pyganim, la primera para facilitar el desarrollo de los gráficos interactivos y la segunda para gestionar las animaciones.

Sobre Pyhton ya hemos hablado con anterioridad como un lenguaje de programación que, a mi parecer, da bastante juego por ser un lenguaje orientado a objetos. Para utilizar código ya existente, hemos tirado sobre todo en el que desarrollé en el curso de Python de la Universidad de Rice, en concreto, el que emplee para el desarrollo de RiceRocks, una especie de Asteroids.

Para los gráficos, hemos usado los de acceso libre de Vector Open Stock, de Vecteezy, de  Dryicons,  y Free Vector, y para los sonidos, Sound Bible.

A partir del concepto y empleando estas fuentes de gráficos, hicimos una primera aproximación más detallada que nos dará idea del tamaño de sprites que vamos a usar, el tamaño del lienzo, cuántos assets más nos hacen falta, etc.

Y este es el aspecto deseado:

 

Boceto de la primera pantalla

El tiempo de búsqueda de gráficos fue algo más largo, quizá un par de días pero con toda la información, el tiempo de montaje de la escena no fue más de 6 ó 7 horas.

Ahora hemos pasado a la fase de programación en la que se plantea el problema de dividir el programa en tareas y subtareas y la compartición de información. Para compartir información estamos usando Dropbox, compartiendo una carpeta en la que vamos numerando las versiones por fecha y hora. Hay otros métodos más sofisticados, como el Git y BitBucket para gestionar versiones, pero de momento optamos por el mencionado Dropbox porque es bastante sencillo. 

Para controlar las tareas y subtareas que debe hacer cada uno de nosotros, estamos usando Asana, una aplicación para trabajo en equipo sin usar e-mail que he empleado en proyectos de trabajo reales y funciona bastante bien.

Las tareas en Asana