Remake parcial de Saboteur

[nacho]

Hay quien me había preguntado si no iba a avanzar el Exploding Fist. La respuesta es un "durante unos días no". Y uno de los motivos es que estamos haciendo otro remake parcial en clase.

Esta vez se trata de un Saboteur. Doy por sentado que no se va a terminar, porque le dedicaremos sólo 4 clases de 100 minutos cada una, menos de 7 horas en total, pero lo estoy usando como forma de que mis alumnos trabajen en un proyecto conjunto de un cierto tamaño, y que aprendan a usar herramientas de control de versiones como Subversion (SVN) y repositorios software como SourceForge o (en nuestro caso) Google Code.

En una sesión anterior a esos 4 días de programación hicimos una "tormenta de ideas" para proponer cosas que debería hacer el juego, y a partir de ahí hicimos un primer diagrama de clases, que nos permitiera repartir el trabajo.

Así, durante la primera de esas 4 sesiones, una pareja de alumnos se dedicó a crear una estructura que pudiera representar una habitación como las del Saboteur original, otra pareja a crear un personaje que se moviera a los lados y se agachara usando las imágenes originales, otra pareja a crear una lógica inicial de juego (comprobar teclas, dibujar pantalla, etc), y así sucesivamente.

En sólo dos sesiones ya tenemos una habitación con aparencia razonable, un personaje que se mueve a los lados, se agacha y sube y baja (todavía no exactamente en las escaleras), un enemigo y un perro que se mueven de lado a lado, un panel inferior con una barra que representa la cantidad de energía restante, etc.

Faltan cosas como los disparos del enemigo y los objetos que lanza el personaje principal, el control de colisiones y alguna habitación más, que deberían quedar hechos en la sesión de mañana jueves 21 de mayo. El viernes 22 sería la última sesión que le dedicáramos, para detalles como recoger objetos de las habitaciones, para que los enemigos estén situados en ciertas habitaciones y para completar lo que haya quedado sin terminar hasta entonces.

El mapa no será (por supuesto) tan grande como el original. Quedarán sin hacer (además de lo que no dé tiempo) cosas como el llegar en barca, los trenes subterráneos, posiblemente también el helicóptero final, etc. Además, faltarán otros muchos pequeños detalles, como las "cámaras que disparan", los objetos que se ven delante del personaje, etc. Así que quedará trabajo para si a alguien le apetece trastear con los fuentes para ampliar funcionalidades, de modo que se acerque cada vez más al original.

A cambio, incluirá alguna funcionalidad extra, como la posibilidad de escoger entre los gráficos originales o un juego de imágenes alternativas con algo más de resolución, así como la posibilidad de guardar la tabla de records y quizá la de guardar una partida.

¿Quereis que dé más detalles de cómo lo vamos haciendo y de dónde se puede ojear y/o descargar el fuente? (C# y Sdl.net como biblioteca gráfica, probado sólo en Windows)

[Mode 2]

Por supuesto, Nacho.

Muchas gracias!!

[BatJoss]

Soy de la misma opinión. Así me entero de paso que es eso del C#

[nacho]

Pues vamos allá...

En primer lugar, hoy toca hablar de "¿por qué C#?" Mañana (si me es posible) hablaré del diseño que hicimos, y en días posteriores de cómo lo fuimos implementando.

El motivo de usar C# es que queríamos un lenguaje para nuestros alumnos que fuera razonablemente fácil de entender(son novatos), portable (al menos entre Windows y Linux), con herramientas de generación de entornos visuales ("ventanitas", que usarán en segundo curso) y que permitiera acceder de forma sencilla a bases de datos (porque las verán también con detalle en segundo).

Después de descartar Delphi/Pascal que está claramente en desuso, Visual Basic que a ninguno nos mataba de ilusión, y C, que puede ser muy críptico para principiantes y terriblemente incómodo para crear entornos visuales, los candidatos que parecían más razonables fueron: C++, como alternativa potente pero compleja, Java como alternativa más lenta pero portable, y C# como punto intermedio, con velocidad cercana a la de Java, pero con entornos como Visual Studio que permiten crear entornos visuales en muy poco tiempo.

Se hizo una votación y ganó (por poco) C#. Para mí ha supuesto más de un quebradero de cabeza, porque hacer jueguecitos y aplicaciones con gráficos es una buena forma de aprender, y motivadora para veinteañeros ... pero claro... en Java hay buenas posibilidades gráficas incorporadas, para C++ hay muchas bibliotecas gráficas para elegir (destacando SDL y Allegro), pero en C# la situación es un poco más complicada. Aun así, usando Tao.Sdl como biblioteca gráfica, hemos conseguido cosas razonablemente decentes.

(Seguirá...)

[nacho]

Vamos con la fase de diseño. Hicimos sólo dos documentos de los muchos que se pueden (¿deben?) hacer.

En primer lugar, les puse 30 segundos de una partida real en el juego, porque son tan jovencillos que muchos de ellos ni lo conocían. A partir de esos 30 segundos de juego hicimos una "tormenta de ideas", apuntando lo que se nos ocurriera que deberíamos tener en cuenta para el juego, con la intención de refinarlo más adelante. Surgieron ideas como:

-----

- Personaje: se puede mover: andar, agachar, dar patadas, subir y bajar escaleras, recoger cosas, lanzar cosas. Muere si se queda sin energía. Recupera energía cuando descansa.

- Quizá deba tener comportamiento distinto en el agua (nadar).

- Debe poder recoger objetos (dejando el que se lleve).

- Debe tener una animación cuando anda.

- Perro: te sigue si estás cerca; se mueve de lado a lado si no estás cerca.

- Malo: te ignora si no estás cerca; te persigue, dispara o ataca si estás cerca.

- ¿Se debería crear una superclase "enemigo", que englobe perro y "malo"?

- Varios tipos de disparos: del malo, del personaje (lanzar objeto), del techo ("cámaras").

- ¿Cómo será la lógica de la lucha?

- Necesario control de colisiones entre enemigos y personaje (y quizá para recoger objetos, etc).

- Puntuación y tabla de mejores puntuaciones.

- Contador de tiempo límite.

- Varias habitaciones -> mapa. Necesario controlar cómo se comunican las habitaciones (dónde está la salida y a qué punto de qué habitación me lleva).

- Escaleras en las habitaciones, que el personaje puede subir (trepar) y bajar.

- Troncos que se comportan como escaleras (en el muelle inicial)

- Escalones, por los que el personaje sube y baja (sin necesidad de pulsar ninguna tecla especial, simplemente desplazándose hacia el lado).

- Objetos ocultos, que se ven al pasar cerca.

- Distintos niveles de "profundidad" (hay objetos que se ven por delante del personaje).

- Panel de información con:

# Barra que muestra cantidad de energía restante

# Visor de objetos cercanos

# Visor de objeto que se lleva

# Contador de tiempo

# Puntos actuales

- Pantalla de bienvenida

- Animación antes de comenzar el juego (llega en barca).

- Menú con tabla de records

- Distintos niveles de dificultad

- ¿Cuando se ganar la partida? Encontrar helicóptero.

---------

A partir de aquí llegaron los recortes presupuestarios: no implementaríamos por ahora la escena de la barca, ni la del helicóptero, ni los distintos niveles de dificultad, ni las cámaras de techo, ni los objetos que se ven por delante del personaje.

Así, existiría un menú capaz de mostrar la tabla de records y las opciones, o de lanzar el juego. A su vez, el juego contendría un personaje capaz de moverse, un plano con varias habitaciones intercomunicadas, y en cada habitación podría haber enemigo(s), perro(s) y/o objeto(s) con los que interactuar.

Adjunto un primer diagrama de clases en el que aparece todo esto, junto con algún detalle que no se llegó a implementar (por ejemplo, en un principio pensamos en un objeto "salida", que comunicara una habitación con otra, saliendo desde cualquier punto y llegando a cualquier punto, pero al final optamos por la variante sencilla de que si en un extremo de la habitación no hay pared, entonces ese extremo comunica con la habitación contigua).

(Seguirá pronto con lo que hicimos para la primera "entrega"...)

[nacho]

Sigamos...

A partir de este diagrama de clases generamos el código fuente de las clases vacías (algo que permiten herramientas como ArgoUML, BoUML, DIA con Dia2Code, etc), las amplié un poco para que compilara y mostrara una pantalla de juego vacía, y repartimos trabajo:

- Dos personas se encargaron de ir completando la clase "Menu", para que mostrara la pantalla de presentación, y luego opciones para entrar al juego o ver los créditos.

- Otras dos personas se encargaron de la clase "Juego", creando una primera versión del "bucle de juego", que dibujara elementos en pantalla, comprobara pulsación de teclas, etc.

- Otras tres se encargaron de crear una primera habitación por la que se moviera el personaje, a partir de un "mapa de tiles".

- Otras dos tomaron el personaje, para que comenzara a responder a las órdenes de "moverse a la derecha" y a la izquierda, así como a la de agacharse, mostrando varias imágenes de forma alternativa.

- Otras dos comenzaron el esqueleto de la clase "ObjetoRecogible", que representaría a objetos como el shuriken, los ladrillos, las piedras, etc., que el usuario puede recoger y lanzar. También crearon un primer esqueleto para la clase "Disparo" (del enemigo).

- Otras 3 comenzaron la estructura básica para el panel de información y la tabla de records.

Así, en apenas unos 90 minutos reales conseguimos una primera entrega, todavía no jugable, pero con una apariencia que recordaba al saboteur original.

Esta entrega corresponde a la versión 0.03 de la página de descargas del proyecto:

http://code.google.com/p/remake-saboteur/downloads/list

Si alguien quiere probarlo, deberá descargar también las DLLs de esa misma página. También se puede cotillear la pinta que tiene la última versión de los fuentes, que están en:

http://code.google.com/p/remake-saboteu ... teurRemake

(Seguiremos informando...)

[Mode 2]

Nacho me atrae muchísimo el juego pero el C# me echa un poco para atrás. Me cuesta pasar de C a C++ así que a C# que ni siquiera lo conozco ...

¿Algún manual recomendado?

[nacho]

C# es más fácil que C++, y muy similar a Java. Tienes enlaces a varios cursos (entre ellos, los apuntes que he ido creando durante este curso para mis alumnos) en:

http://www.nachocabanes.com/csharp/index.php#cursos

[LexSparrow]

Incluso es bueno ver tu diagrama de clases para aquellos que estén aprendiendo UML. Con los ejemplos que vienen en los típicos libros de Rumbaugh, Jacobs & cia se ve todo muy aséptico. Pero viendo un ejemplo UML aplicado directamente a algo como un juego, cualquier alumno seguro que pilla mucho mejor lo de los casos de uso y los distintos diagramas.

Muy buen esfuerzo, y gracias por compartirlo con la comunidad.

[nacho]

Incluso es bueno ver tu diagrama de clases para aquellos que estén aprendiendo UML. Con los ejemplos que vienen en los típicos libros de Rumbaugh, Jacobs & cia se ve todo muy aséptico. Pero viendo un ejemplo UML aplicado directamente a algo como un juego, cualquier alumno seguro que pilla mucho mejor lo de los casos de uso y los distintos diagramas.

Sí, de eso se trata. Eso sí, como éste es un "proyecto relámpago", en éste no hay diagramas de casos de uso, ni de secuencia, ni ningún otro correspondiente a las fases de análisis y diseño, salvo el diagrama de clases, que tenía como principal intención (en este caso) ayudar en el reparto de trabajo. Todo ese tipo de diagramas corresponden a la asignatura de "Análisis", y no quería un proyecto interdisciplinar, sino un proyecto rápido que permitiera desarrollar en grupo de forma simultánea, para que se encontraran con cierto tipo de problemas que hasta ahora no habían tenido.

Muy buen esfuerzo, y gracias por compartirlo con la comunidad.

Nada, un placer.

[nacho]

Vamos con la segunda versión.

En este segundo día de trabajo se pretendía: ampliar las funcionalidades de la primera versión, corregir alguno de los errores que ya había en la primera, y además, que los alumnos cambiaran de trabajo comparado con la primera entrega, de modo que tuvieran que ampliar y/o corregir fuentes que no habían creado ellos.

Las tareas que nos propusimos para esta entrega fueron:

- Que apareciera un enemigo, capaz de moverse a derecha e izquierda (aprovechando al estructura que ya se había creado para el personaje principal).

- Añadir un perro, que también se moviera de lado a lado.

- Que el personaje pudiera subir y bajar (aunque todavía no lo hiciera exactamente en las escaleras).

- Que la habitación informara de si se podía subir o bajar en la posición actual (para poderlo aplicar cuando el personaje intente hacerlo).

- Que la tabla de records permita saber un cierto record (nombre y valor de la puntuación más alta, por ejemplo), o añadir uno nuevo.

- Que el panel de información mostrara energía en forma de barra (en la primera entrega sólo era una cifra numérica).

- Añadir una pantalla de "créditos" donde quedara constancia de los desarrolladores que estaban participando.

- Diseñar un sistema para comunicar las habitaciones (¿"puerta" en ciertas coordenadas, que lleva a ciertas coordenadas de otra habitación? ¿o simplemente pasar a la habitación adyacente si se llega al extremo de la actual y no hay pared? Optamos por la segunda, menos versátil pero muy sencilla de implementar).


En la página de descargas del proyecto, esta entrega equivale a la versión 0.04:

http://code.google.com/p/remake-saboteur/downloads/list

[nacho]

Después de más de dos semanas sin aparecer por el foro por el exceso de trabajo de final de curso, vuelvo a estar vivo.

Voy a comentar lo que hicimos para la tercera jornada de trabajo en el Saboteur:

Pretendíamos que ya fuera "un poco jugable", permitiendo que:

- Control de colisiones entre perro y personaje, y entre objeto lanzado y enemigo
- Se disminuya energía del personaje si le roza el perro.
- Se mate al enemigo si el objeto lanzado lo alcanza, y aumente la cantidad de puntos.
- El "objeto recogible" tenga dos imágenes: una grande, que se muestra en el menú, y una pequeña, para cuando el personaje lo lanza en la pantalla de juego. También deberá tener un nombre, que se pueda mostrar en el menú.
- Se acabe la partida si se acaba la energía.
- El juego cuente tiempo.
- Se pueda introducir un record si la puntuación es suficientemente alta.
- Se pueda pasar de una habitación a otra adyacente (incluyendo primer plano, con 4 habitaciones, en 2 alturas).
- El personaje pueda recoger, cambiar y lanzar objetos.
- El menú muestre records un apartado de "opciones" para elegir diferentes
series de imágenes ("clásica" o "moderna").

Como suele ocurrir, no todo quedó completado. Por ejemplo, introducir el nombre para los records es algo incómodo de hacer con SDL, y el mapa de habitaciones interconectadas todavía no funcionaba correctamente al terminar los 100 minutos de esta sesión (más por las comprobaciones de escaleras y obstáculos que por el mapa de habitaciones en sí).

Si alguien quiere ver más detalles del fuente, esto equivale a la versión 0.06 de la página del proyecto:

http://code.google.com/p/remake-saboteur/downloads/list

[nacho]

La cuarta versión (y última realizada por los alumnos) pretendía corregir algunas de las carencias, y aportar alguna ampliación (muy pocas).

Entre las tareas para terminar estaban que:

- Se controlen colisiones entre objeto lanzado y enemigo,
y entre disparo perro y personaje
- Se mate al enemigo si el objeto lanzado lo alcanza, y aumente la cantidad de puntos.
- Cuando se lance un objeto, se pierda (deje de aparecer como objeto que aún lleva el personaje).
- Se acabe la partida si se acaba la energía.
- Se pueda introducir un record si la puntuación es suficientemente alta.
- Se pueda pasar de una habitación a otra adyacente (primer plano, con 4 habitaciones).

Y las cosas que aún no se habían hecho:

- Los enemigos, perros y objetos que contenga una habitación se lean del fichero de configuración, en vez de estar prefijados en código.
- El panel muestre los objetos cercanos, si los hay.
- El personaje pueda recoger objetos de la habitación y cambiar objetos que ya lleva por otros de la habitación.
- El menú muestre records un apartado de "opciones" para elegir diferentes
series de imágenes ("clásica" o "moderna"), un apartado de "cargar/guardar".
- Los records se guarden automáticamente tras cada partida y se recuperen de fichero al entrar al juego.
- Se pueda grabar/cargar la partida actual.

Como era de esperar, no todo quedó terminado, aunque la mayoría de cosas quedaron a poca distancia de ser utilizables. Esto corresponde a la versión 0.08 en la página del proyecto:

http://code.google.com/p/remake-saboteur/downloads/list

Si tengo un respiro en verano (eso espero), querría darle un empujón para terminar las cosas que han quedado a medias, y ampliarlo un poco para añadir alguna de las funcionalidades que aún no están incluidas.

El problema es que es posible que hasta agosto sólo tenga ratos cortos y no cunda para un proyecto "grande" como éste o como otro par de ellos que tengo parados por falta de ratos "suficientemente grandes".

La última versión de los fuentes se podrá cotillear en la página de la "rama" principal del proyecto:

http://code.google.com/p/remake-saboteu ... teurRemake

Cuando que haga cambios suficientemente grandes, crearé un nuevo fichero ZIP para descarga en la página del proyecto, y avisaré aquí.

[Mode 2]

Muchas gracias Nacho!!