Burdjia

Categoría Piopio, 3 entrada(s)

Feed Rss, Atom

Comienza Ludum Dare #33

De nuevo no he avisado con tiempo, pero aquí estoy para subsanarlo.

Hoy comienza un nuevo Ludum Dare en el que voy a participar.  Para separar las cosas en nuestro nuevo modelo de negocio, esta vez la información sobre la evolución del concurso se dará a través del blog de El Saloncito del Cómic y la cuenta de Piopio Juegos en Twitter.

De todas formas, más adelante publicaré (espero) el post mortem aquí, como he hecho en otras ocasiones.

Ludum Dare 29 - Beneath the Surface post mortem

Como ya pasó antes, debido a diversas razones vuelvo a llegar tarde al anuncio de un importante evento: Ludum Dare.  Sin embargo, a diferencia del anterior, esta vez sí he podido participar.  A continuación, un pequeño post mortem del concurso y el proyecto, con una semana o así de retraso.

Preparación

La verdad es que no hubo ninguna.  También había normas globales y normas específicas, pero no quise adelantarme porque tampoco tenía muchas cosas que probar, no como en el anterior PGD Challenge.

Planificación

Con un plazo de entrega de 48 horas no hay mucho tiempo para planificar, la verdad, pero algo se hizo la mañana del sábado.

El tema del concurso fue Beneath the Surface.  Nada más enterarme tuve la idea de hacer una nueva versión de un viejo juego de Spectrum, cuyo nombre no recuerdo, en el que manejas un pequeño submarino dentro de un barco buscando el tesoro.  Aunque estuve buscando otras ideas, esta es la única que cuajó, así que seguí adelante.

Un fallo que tuve aquí es que asumí que iba a escribirlo todo, sin reutilizar nada (salvo Allegro.pas), hasta que caí en la cuenta de que el motor del juego de demostración de Allegro.pas podría considerarse como un middleware.  Eso me hizo perder algo de tiempo, pero tampoco fue tan malo.

Desarrollo

Me persigue un pulpo. Y yo buscando sombrero.

El desarrollo fue muy bien, a pesar de alguna metedura de pata.

Al tema de reutilizar el motor del juego de demostración de Allegro.pas hay que añadir que tuve que re-escribir el generador de mapas dos veces.  La razón, que comencé a partir de un ejemplo de generación de laberintos que usaba una estructura muy diferente a la que había preparado yo.  Eso sí, al menos me sirvió para tener muy claro un par de métodos para generar mapas aleatorios.

Una curiosidad: Hay dos tipos de habitantes en el barco, los pulpos y los peces de colores.  Aunque parezca que se mueven de formas muy diferentes, la verdad es que ambos usan un método muy similar.  Es más, primero escribí el método de los peces, y cuando empecé con los pulpos copié ese mismo método, le cambié la velocidad e hice que cuando decidiera cambiar de dirección persiguiera al jugador.  El resultado me ha sorprendido mucho.

Finalmente, para los gráficos, tomé como base la paleta de colores del MSX, y los realicé como si fueran para este sistema.  De hecho podría utilizarse sin problemas en él, porque no hay conflicto entre los atributos de color... salvo en un pequeño detalle:  El pebetero de la vela tiene un pequeño saliente que sí crearía un pequeño problema.

Los sonidos se generan al vuelo.

Conclusión

Aunque no tiene todos los elementos que hubiera deseado, he terminado el juego y he podido poner a prueba algunas herramientas que he desarrollado últimamente, así que estoy muy satisfecho con el resultado.

La verdad es que el juego se merece una revisión y un pulido para dejarlo en condiciones, pero tendrá que esperar.  Entre otras cosas, tengo que preparar un apartado donde poder poner todos los prototipos desarrollados en los concursos para tenerlos ordenados y disponibles, que ya van siendo unos cuantos.  Por ahora os podéis descargar este juego, compilado para Windows y con el código fuente completo incluido, desde aquí.

Evaluación Momen 3D

Hace ya como un mes que terminó el 2nd PGD Challenge (perdón por no avisar) y creo que va siendo hora de hacer una evaluación de mi proyecto Momen3D.  No será, esta, una exposición rigurosa, pero espero que sí suficiente.

Preparación

Como en otros concursos de este tipo, este tiene dos tipos de normas:  las globales y las específicas.

Las normas globales son conocidas en todo momento y aluden a conceptos como, por ejemplo, la extensión o tamaño del juego, los lenguajes de programación y herramientas que pueden usarse, los plazos del concurso, etc.

Las normas específicas, sin embargo, son conocidas únicamente el mismo día en el que comienza el concurso.  Esto se hace así para evitar que haya concursantes que jueguen con ventaja.  Estas normas suelen referirse a temas de estilo y técnica, y suelen limitar el tipo de juego que puede realizarse.

Puesto que me mi intención era usar este concurso para poner a prueba la nueva versión que estoy realizando de Allegro.pas, decidí jugármela y comencé a diseñar y desarrollar un pequeño motor 3D una semana antes de que comenzara el concurso.  La jugada me salió bien, porque no suponía una ventaja demasiado grande (otros participantes usaron motores existentes) y las normas específicas no echaron por tierra mis esfuerzos.

Planificación

De las cuatro semanas de plazo para realizar el juego, utilicé casi toda la primera semana en realizar una planificación.  Escribí guiones, hice diagramas de diferente tipo (flujos, transiciones de estado, clases...) y jugué con ellos bastante hasta tener algo interesante y que me viera capaz de realizar en unas tres semanas.

Decidí rescatar un viejo proyecto que presenté incompleto a un speedhack.  Se trataba de un matamarcianos en tres dimensiones bastante simple, y al final lo actualicé para que fuera más similar a "Wing Commander" o "Rogue Squadron".  La norma específica establecía como requisito la necesidad de hacer un viaje, de forma que hubiera diferentes escenarios que obligaran al jugador, de alguna forma, a cambiar de forma de juego.  En un juego como el que elegí esto sería muy fácil pudiendo ofrecer batallas espaciales o planetarias, con o sin niebla, creando laberintos con el propio escenario...

Finalmente decidí arriesgarme de nuevo y decidí no hacerme cargo yo de los gráficos y pedí ayuda en un par de foros, entrando en contacto con Rubén Deig, que se ofreció a realizar los modelos que necesitase.  Gracias a la planificación previa no me fue difícil describir lo que necesitaba, y Rubén lo entendió a la perfección como veréis más adelante.

Desarrollo

El desarrollo tuvo varios altibajos, en parte debido a la presión de tener una "fecha de entrega" tan limitada.  La parte que más problemas me dio fue el propio motor.  Evidentemente, un motor realizado en apenas una semana no puede ser muy sofisticado y alguna de las características que tuve que añadir (por ejemplo, el mapa de alturas que representa el terreno en las misiones planetarias) dieron más problemas de lo deseado.

Aun así, el trabajar a base de objetivos concretos ha sido de lo más provechoso, algo que ya comprobé en el anterior PGD Challenge, aunque en ocasiones los fallos de diseño del motor me obligaran a volver al motor en varias ocasiones, añadiendo parches para salir del paso.

Una de las cosas de las que me siento más orgulloso es del sistema que ideé para definir las misiones.  Definí una especie de lenguaje de programación que permitía indicar en un archivo de texto, y de forma muy simple, los elementos del escenario, los enemigos, los objetivos a cumplir, la descripción que aparece en la pantalla de selección de misión y la relación con las misiones anteriores y posteriores.  A pesar de su sencillez permite definir misiones lo suficientemente variadas entre sí.

Conclusión

Estoy bastante satisfecho con el resultado.  Además, la gente que ha visto los vídeos (los tenéis en este hilo de PGD) y alguno que lo ha probado (ya avisaré cuando esté disponible para todos) me han dicho muy buenas críticas.  El motor necesita una refactorización severa, pero a rasgos generales es un buen motor, con una estructura flexible.

En definitiva, creo que ha sido un éxito personal.