3ª Jornada (normas)

Hola a todos. Espero que esteis ultimando detalles para la entrega de la Jornada 2. Mientras vais cerrando bugs, voy a explicaros las bases de la 3ª Jornada.

Introducción

Ya tenemos claro como funciona un bucle del juego, podemos dibujar cositas con StdPijo. ¿Y si incrementamos un poco la intensidad?l


Vamos a hacer un Matamarcianos … con StdPijo


En concreto, buscamos algo similar a los shooters de los años 80-90: R-Type, Silkworm, Gradius,  Xenon 2, Axelay. Os pongo unos videos de youtube para que os hagais una idea y os inspireis 🙂

El objetivo de esta jornada es que aprendais a dibujar sprites, hacer animaciones sencillas como scrollers e introducir lógica más complicada al juego como los cálculos de colisiones y el movimiento de las entidades.
Requisitos del Juego

Esta vez, teneis mucha más capacidad creativa, pero queremos fijar ciertas características comunes
  • El área total de la pantalla de juego no debe exceder de 24 filas por 80 columnas. Esto es el tamaño de un terminal estándar.
  • Los controles del serán FIJOS y serán los siquientes
    • W – Arriba
    • A – Izquierda
    • S – Abajo
    • D – Derecha
    • Espacio – Aceptar/Adelante/Disparo
    • ESC – Salir/Atrás
    • Si poneis controles adicionales: bombas, powerup, que conste en el menú principal del juego
  • El juego usará como mínimo dos planos de scroll: Uno para el fondo y otro para la nave los enemigos y los disparos.
  • Estos planos de scroll se moverán a distintas velocidades.
  • El juego simulará como mínimo 4 entidades
    • La nave controlada por el jugador
    • Los disparos de la nave
    • Como mínimo, dos clases distintas de enemigos, con distinto comportamiento
  • Podeis añadir tantas entidades extras como querais: disparos enemigos, disparos cargados, powerups,  bombas que fulminan todo en la pantalla, final bosses …. sed creativos !
  • La nave del jugador se podrá mover por toda la pantalla libremente
  • La nave del jugador y los enemigos estarán formados  por sprites de 2×2 caracteres como mínimo. Nada de naves y  enemigos formados por un simple caracter
    • Ejempos de naves sencillas ASCII:  |=O=| <- Tie fighter en vista vertical. Dadle al coco, no es muy difícil.
  • Condiciones de derrota
    • Si un enemigo o disparo enemigo tocan a la nave, debe perder una vida o energía
    • El número de vidas o energía lo podeis poner a discrección
  • Los disparos si que podrán ser de 1×1 si así lo deseais
  • No es necesario que el juego tenga niveles separados pero la dificultad debe subir progresivamente
    • Eso sí … un juego con distintos niveles de fondo y final boss quedará muy resultón
  • No se permite la E/S bloqueante salvo para leer algún nombre largo por pantalla
  • No se permite sonido, menos la típica campanita del terminal (Carácter ‘\a’ )
Entrega

  • Se enviarán las entregas y evaluaciones a ligabitheroes@byterealms.com
  • Las entregas van en formato .tar.gz y deben incluir obligatoriamente los siguientes contenidos
    • Código fuente del juego
    • Archivo Makefile para compilar el juego
    • README Con el autor y una breve descripción del juego, así como las notas oportunas que se quieran explicar
    • COPYING Con una copia de la licencia GPL v3 en inglés
    • No se permiten ejecutables del juego, la entrega es estrictamente en código fuente
  • Recordad que la plataforma de evaluación es el Ubuntu de los Laboratorios EPS, que os podeis bajar y usar sin instalarlo en vuestro PC:
  • En la sección “Ejemplo de Uso” os podeis bajar un archivo de ejemplo, que podeis usar de base para vuestra entrega.
  • Las entregas que no cumplan los requisitos serán automáticamente descalificadas
Fechas

  • Entrega: Hasta el Viernes 22 de Julio de 2011 a las 23:59 pm
  • Se enviarán las entregas para su evaluación al día siguiente, el 23 de Julio.
  • Evaluación: Hasta el Viernes 26 de Julio de 2011 a las 23:59 pm
  • Se publicarán  las evaluaciones y puntuaciones el Martes 27 de Julio de 2011
Ejemplo de uso de StdPijo

Algunos Consejos

  • Entidades = Objetos. En este juego os empezarán a servir los conceptos de la programación a orientada objetos.
  • Os aconsejo dotar a las entidades de una velocidad y actualizar la posición basada en la velocidad y el transcurso del tiempo de juego
    • Con este sistema desacoplais la velocidad del juego de la velocidad del procesador
  • Si sois de la escuela antigua podeis usar structs + funciones. De hecho, los motores 3D actuales están evolucionando más hacia una filosofía orientada a datos que a objetos.  Esto permite trabajar de manera más eficiente con procesadores multicore.
  • Si almacenais las entidades del juego en vectores, no metais todas las entidades en el mismo saco. Es más comodo separarlas por tipo básico (enemigos, disparos, nave, explosión)
  • Podeis consultar vuestras dudas concretas de diseño, pero que se note que al menos habeis buscado en Google, pardiez.

Estamos ansiosos de ver vuestros progresos. Happy Hacking !

Comments Closed