Javi Agenjo at UPF

Después de todas las horas invertidas en el desarrollo del juego es importante que el resultado final demuestre realmente todo ese trabajo y no se venga abajo por no haber cuidado la entrega final.

Es por eso que hay varios factores a tener en cuenta para la entrega:

• Aseguraos de que no teneis ninguna ruta absoluta de los assets hardcoded en el código, sino que todas son relativas al root de la aplicación que es donde está el ejecutable.
• Windows: Teneis que entregar una carpeta que contenga el ejecutable del juego (compilado en Release, está en la carpeta Release), con las DLLs que useis (SDL,Glew, Bass) y la carpeta con los Assets, para que baste hacer dobleclick para jugar.
• OSX: Generar el ejecutable seguir la siguiente guia:

Product -> Archive = Compila la app, luego Share… para guardarla en una carpeta. Recordad que eso solo exporta el ejecutable. Cread una carpeta y meter dentro el ejecutable, las librerias (dylib) y la carpeta con los assets. Probad de ejecutar el ejecutable desde la consola (si haces doble click no funciona). Podeis crear un bundle si quereis, para más info sobre el bundle mirar este tutorial

• Probadlo en varios ordenadores antes de entregarlo, si es en windows probadlo en PCs donde no esté instalado el Visual Studio, si os dá un error extraño al ejecutar es porque necesitais tener instalado el Visual C++ 2008 Runtime.

Sobre el juego en sí, basta haber jugado a cualquier juego del mercado para saber qué se espera de un juego al jugarlo:

• Fase de carga: que nunca de sensación de haberse colgado. Para ello durante las fases de carga de los assets hay que asegurarse de que se vea algo en pantalla donde ponga “cargando…”.
• Intro: que al jugador se le muestre una imagen o texto que explique el contexto del juego, para que sepa de qué trata y el proposito de sus acciones. Algo tan sencillo aporta personalidad.
• Tutorial: que exista algun lugar donde el jugador pueda informarse de las teclas necesarias y acciones de las que dispone, ya sea un tutorial, una pantalla de ayuda o una imagen con el mapa del teclado.
• Gameplay: que durante el juego el jugador pueda percibir facilmente cuales son sus objetivos y medir si los está completando (mostrando la puntuación, el numero de enemigos restantes, etc)
• Victoria: que una vez completado el proposito de la fase del juego el jugador obtenga algun tipo de feedback visual que le informe de ello, un cartel que diga “Has ganado!” y si le puede mostrar ademas su puntuación, mejor.
• Derrota: que si el jugador se queda sin vidas o sin energia le salga un texto que le diga “Game over” y su puntuación.
• Retry: que una vez finalizada una fase (ya sea por victoria o por muerte) el jugador pueda volver a jugar o salir del juego.

Además es importante reforzar la entrega con algun tipo de documento que explique un poco las funcionalidades que tiene el juego, esto hará más facil la tarea de evaluación y evitará que el evaluador omita alguna de las funcionalidades.

No hace falta que sea un documento muy extenso, basta que sea algo facil de leer y donde se explique claramente el trabajo realizado.

No olvideis adjuntar un README.txt con los nombres de los participantes del grupo, correo electronico y NIA

Una vez tengais la “Release Candidate” de vuestro juego, comprimidlo y subidlo a algun servidor de la red (podeis usar dropbox, rapidshare, etc) y enviadnos el link.

Si por cualquier cosa generais algun video ingame y lo subís a internet añadir la url del video en el documento, o hacedmela llegar, así podré mostrarlo a los alumnos del curso siguiente.