Proyecto 1: Cats

El primer proyecto de este curso está pensado para romper el hielo con el lenguaje Python y la librería PyGame. Debido a que estaremos haciendo juegos a un nivel muy bajo, es decir, sin contar con librerías de interfaces o similares, este primer proyecto presenta un juego simple, que ya presenta un diseño bien conocido, y del cual no deberían desviarse mucho.

El proyecto se debe hacer entre 2 personas, máximo 3 dado el caso de que el número de estudiantes es impar. Este curso presenta un nivel de dificultad suficiente para aquellos que desean pasar la materia. Sin embargo, para aquellos que desean conocer más sobre el desarrollo de videojuegos, o que hayan tenido alguna experiencia desarrollándolos, es posible reestructurar el proyecto para aumentar el nivel.

El proyecto se entrega con código fuente y una presentación el día de la entrega. La semana siguiente a la entrega del proyecto se debe entregar un informe de desarrollo (postmórtem) del juego, que será explicado más adelante en este enunciado.

El objetivo del proyecto es que puedan aprender a usar Python y PyGame, y al mismo tiempo elaborar un videojuego básico. La fecha de entrega de este proyecto es el 18 de abril de 2012, día en el que se hará una presentación ante el salón del juego. El mismo día 18 de abril se entregará un informe de máximo 2 páginas en el que se hará un postmórtem del juego, reflexionando sobre el proceso de desarrollo del mismo. (Ejemplo de un postmortem)

El resto de este enunciado explicará el mecanismo de ambos juegos, las restricciones gráficas, el desarrollo del posmortem y el proceso de entrega.

Cats

Cats es un juego hecho por Ferry Halim para Orisinal en 2003. Se puede jugar en la siguiente dirección: http://www.ferryhalim.com/orisinal/g3/cats.htm

El objetivo del juego es hacer la mayor cantidad de puntos. Para ello, se pasa el cursor encima de los gatos para que hagan lo mismo que el líder (el líder es seleccionado cada cierto tiempo remarcando con gris su camino), y en el momento entre selección de líderes puede que no haya uno. Es recomendable jugar algunas partidas del juego para tener una idea.

Reglas de inicio

Se disponen 6 gatos verticalmente equidistantes, con posiciones horizontales al azar, con una dirección escogida al azar, y con uno de los dos estados posibles al azar (sentado o caminando). Los gatos caminan siempre en la misma dirección durante toda la partida. Cuando un gato alcanza el extremo de la pantalla, sale por el lado contrario.

Reglas de progreso

Cada cierto tiempo se escoge a un gato líder, señalando su camino con color gris. La posición del gato líder se mantiene todo el tiempo mientras sea líder. Ejemplo: si el gato está caminando al momento de ser elegido como líder, el gato continuará caminando hasta que deje de serlo.

El resto de los gatos puede cambiar su posición al azar en el tiempo que lo desee.

El jugador puede cambiar el estado de los gatos no-líderes pasando el cursor del mouse por encima. El estado cambia una sola vez cada vez que el cursor pasa por encima.

El jugador gana puntos cuando todos los gatos están haciendo lo mismo que el líder. La cantidad de puntos se suma por cada unidad de tiempo en el que los gatos están todos en el mismo estado. El jugador llena también una barra de tiempo con capacidad fija, que se reduce cuando los gatos no están todos en el mismo estado, o cuando no hay líder seleccionado.

Reglas de resolución

El juego termina cuando la barra de tiempo se agota.

Interfaz

El juego debe implementar una pantalla inicial que muestre el título del juego, los créditos de las personas involucradas en el desarrollo e instrucciones de uso (el juego solamente emplea el mouse sin hacer click, aunque se puede hacer clic para pasar de la pantalla de inicio a la pantalla de juego). La tecla ESCAPE cierra el juego.

La partida debe mostrar la cantidad de puntos acumulada en la partida, la barra de tiempo y cuando el jugador está ganando puntos (mostrar en letras grandes el puntaje creciendo).

Gráficos

El juego debe tener una resolución de 600x500 pixeles.

El estudiante cuenta con una librería de gráficos descargable para poder desarrollar el juego sin atención a la parte gráfica, aunque es libre de usar gráficos alternativos si así lo prefiere.

Sonido

El estudiante puede generar los sonidos del juego a partir del programa sfxr, de DrPetter: http://www.drpetter.se/project_sfxr.html

Post-mortem

El post-mortem es un procedimiento usual en el desarrollo profesional de videojuegos. En un post-mortem describe a grandes rasgos la envergadura del proyecto (ej. número de líneas de código, o de clases, o tamaño en MB del proyecto) y se listan todas las cosas que fueron bien en el desarrollo (ej. el diseño caló bien la primera vez, ya conocíamos la tecnología, no hubo sorpresas desarrollando, no hubo cambios de diseño, tuvimos una buena relación con el publisher y cumplimos los tiempos, elegimos un buen control de versiones, etc.) y todas las cosas que fueron mal, o que pudieron ir mejor (nos dedicamos demasiado tiempo a hacer gráficos, nos concentramos demasiado en la historia y echamos a perder la jugabilidad, no probamos lo suficiente, nuestro publisher nos recortó el presupuesto a última hora, se quemó el repositorio de código, etc.).

La idea del post-mortem es reflexionar acerca del proceso de desarrollo, para mejorar lo malo en los siguientes proyectos. Por ello, debe estar plasmado en un informe corto, de 1 página, o máximo 2 si hay mucho de qué hablar. El informe no debe tener portada, solamente un encabezado como el de este proyecto, fechado, con los integrantes del proyecto, y el contenido a continuación.

Evaluación

El proyecto se evaluará en base a los objetivos propuestos por el equipo y los objetivos que hayan logrado implementar efectivamente. Esto quiere decir que es preferible implementar un juego funcional, aunque los gráficos no sean los finales o apropiados, que se haya planeado hacer un juego gigantesco, y no se tenga siquiera un prototipo funcional.

Copia

Aunque la conversación entre equipos para enriquecer los juegos es completamente bienvenida y alentada, la copia textual de juegos entre equipos no está permitida. Cualquier caso de copia detectada ameritará una nota de cero uno (01) en el proyecto para todos los involucrados y se aplicarán las sanciones que permita el reglamento de la UCAB.

¿Preguntas?

Todas las preguntas se harán a mi correo ciro.duran@gmail.com y se responderán públicamente en la página del curso en http://www.ciroduran.com/disenajuegos. Los próximos días de clase se dedicará un tiempo para atender los proyectos de cada grupo.