Estado

Segunda demo jugable

Buenas de nuevo.

Después de otro largo intervalo, he de admitir que “me ha pillado el toro” por trabajar en este proyecto mientras que a la vez he estado haciendo de grafista para Mad Gear Games, que hace poco han lanzado su primer juego en la plataforma Steam Greenlight. Ahora ando realizando el máximo esfuerzo posible para poder terminar el proyecto lo más pronto posible. Por ahora mi intención, es terminarlo para finales de Julio. Si no es posible, al menos tener toda la parte de programación terminada en esas fechas y dedicar el verano a terminar la memoria para entregarlo definitivamente en Septiembre.

Así que lo más seguro es que no escriba en otro periodo largo de tiempo, pero que seguramente la próxima vez que publique algo será para colgar la beta final. Y después de eso intentaré colgar algunas entradas atrasadas mientras termino la documentación y la memoria. Sin embargo, si a pesar de lo dicho no hago las entradas faltantes, no os preocupéis porque lo más probable es que acabe públicandolas, cuando acabe todo, en algún magazine web sobre videojuegos.

Os hablo ahora de la demo actual, esta vez lo implementado es principalmente elementos de la interfaz, usando el sistema UI de Unity, y el sistema de ficheros de guardado y ajustes:

  • Menú principal con botones de nueva partida, cargar partida y salir del juego.
  • Ratón personalizado que cambia encima de los botones y los objetos interactivos.
  • Barra con los nombres de los elementos interactivos dentro de los niveles.
  • Menú de opciones al que se puede acceder dentro del juego (mientras no se esté ejecutando una acción).
  • Botón de mapa en el menú de opciones, en el que aparecerá un mapa (no definitivo) con una localización, si clickamos en él nos transportará al lugar indicado.
  • Botón de ajustes en el menú de opciones, en el que podremos modificar la resolución del juego (en resoluciones 4:3), modo pantalla completa, de ajustes de volumen en el audio (se guardan los cambios aunque todavía no haya música ni sonidos) y se puede cambiar de lenguaje entre español e inglés.
  • Botón de notas en el menú de opciones, aunque aún solo contenta una nota de ejemplo, aquí se iran colocando pistas y recordatorios según el jugador vaya haciendo cosas.
  • Botón de partidas guardadas en el menú de opciones, aquí podremos guardar la partida actual, cargar una partida o borrar las partidas.
  • Botón de salir del juego en el menú de opciones.
  • Ventana modal para verificar según qué acciones en los menú.
  • Implementado sistema de guardado de ficheros de guardado.
  • Implementado sistema de guardado del fichero de ajustes del juego, y estos valores se cargan automáticamente al iniciar nuevamente el juego.
  • Bugfixes  y mejoras varias.

Para poder jugar la demo, tenéis que hacerlo desde la página de GameJolt al igual que la otra vez. Aunque esta vez he deshabilitado la versión web por problemas con el navegador Google Chrome y porque de esta manera no funcionan los sistemas de ficheros para guardar ajustes y partidas. Tenéis ejecutables para Windows de 32 bits y GNU/Linux de 32 bits. En el caso de que alguien con Mac OS X o con SO de 64 quiera otra build, que me avise y la cuelgo también 😉

Click para ir a la página de GameJolt y bajarse la demo.

Al igual que con la demo anterior, si encontráis bugs o tenéis sugerencias, indicarmelas por un comentario a esta entrada, en la entrada de esta demo en GameJolt o en el apartado Issues del repositorio de GitHub.

Respecto al repositorio, ahora mismo no está actualizado, mañana colgaré la nueva versión del proyecto. Pondré aquí un edit con las instrucciones para bajarselo de nuevo cuando esté listo. Aviso de que seguramente haya bastante código sucio que no he podido limpiar o esclarecer debidamente 😦

Edit: Ya están subidos los cambios, al igual que la otra vez,  en la branch demo he subido todo el código usado en la demo, lamento decir que aún no está documentado. Espero poder hacer la documentación a lo largo de este mes.

Página del repositorio de la branch demo.

Desde ahí os lo podréis bajar en un zip, si lo preferís bajar usando una terminal, el comando es el siguiente:

git clone https://github.com/Firenz/1812.git --branch demo

Cómo en la demo anterior, si hay alguien que se baja el repositorio, que me avise si hay algún problema. Intentaré solucionarlos y subirlos al repositorio si ocurriera el caso.

Esto es todo por ahora, ya queda menos para tener implementado todas las funcionalidades. Lo cual me alegra bastante a pesar de que el tema de los puzzles a implementar vaya a sufrir bastante.

Saludos y espero que os guste la segunda demo.

Minientrada

Unity y el software de Control de Versiones

Llevo ya varios días programando una especie de demo del videojuego en mi ordenador. Por ahora no he subido nada a la forja porque me estoy esperando a tener el código más claro, y si lo hago en un futuro próximo, no lo subiré a la rama de desarrollo principal.

Pero eso no quita que ya haya tenido que mirar cómo preparar el proyecto de Unity para ser subido a GitHub, tal y cómo conté en una anterior entrada de este mismo blog.

Dado que voy a trabajar en Windows por no existir ninguna versión de Unity para GNU/Linux y no poseer un MacOSX (no hay dinero para eso), he tenido que buscar software de Control de Versiones basados en la tecnología Git con aplicación para este sistema. Algunos bastante completos tales como SourceTree o la oficial de Git para Windows. Aunque la que voy a usar es la de GitHub For Windows por su simpleza, incluye tanto una versión con interfaz como una por comandos. En mi caso prefiero el de comandos, así voy aprendiendo y memorizando los comandos de Git más comunes a usar y que puedan servirme en futuros proyectos.

Consola de comandos de GitHub For Windows

Consola de comandos de GitHub For Windows

Pero eso no es todo lo que hay que hacer. Normalmente en un proyecto que solo entrañe código y librerías, con excepción de algún archivo de gráficos y de audio, no genera demasiado problemas el subirlo a un repositorio. Pero con Unity la cosa difiere un poco ya que los proyectos de este programa generan archivos auxiliares. Si bien normalmente son inocuos a la hora de subirlos al repositorio como desarrolladora, cuando algún interesado se baje el proyecto y lo ejecute,  puede tener la mala suerte de que no pueda debido a problemas de mal enlazamiento entre los ficheros auxiliares del proyecto porque estos tienen referenciado carpetas de mi ordenador, no del suyo.

Para evitar este problema, tendremos que modificar algunos parámetros del proyecto en Unity.

  1. Para hacer que se muestren los ficheros auxiliares de Unity de cara al software de Control de Versiones:
    Edit->Project Settings->Editor->Version Control Mode = Meta Files
  2. Para que el software de Control de Versiones Git pueda usar bien su diferenciador de código entre distintas versiones de los ficheros:
    Edit->Project Settings->Editor->Asset Serialization Mode = Force Text
  3. Por último y una vez tengamos instalados nuestra aplicación para trabajar con el software de Control de Versiones, en este caso Git, y hayamos creado una copia en nuestro ordenador del repositorio para trabajar, nos saldrá en dicho directorio un fichero de nombre .gitignore . Le hacemos click derecho y elegimos editar con un editor de texto y escribimos los directorios, ficheros, y extensiones de ficheros que queremos evitar que se suban al repositorio. En este caso el mío es el siguiente:
    # =============== #
    # Unity generated #
    # =============== #
    Temp/
    Library/
    # ===================================== #
    # Visual Studio / MonoDevelop generated #
    # ===================================== #
    ExportedObj/
    obj/
    *.svd
    *.userprefs
    /*.csproj
    *.pidb
    *.suo
    /*.sln
    *.user
    *.unityproj
    *.booproj
    # ============ #
    # OS generated #
    # ============ #
    .DS_Store
    .DS_Store?
    ._*
    .Spotlight-V100
    .Trashes
    ehthumbs.db
    /*Thumbs.db

    Cada línea de este fichero es un fichero o (directorio si contiene “/”) a ignorar cada vez que subamos una nueva versión de nuestro trabajo al repositorio, aliviándonos la carga de escrutinizar los ficheros a subir para evitar que se suban también los que no queremos. Como nota final, los asteriscos sirven para indicar que nos da igual el nombre, solo los carácteres que lo acompañan a la hora de filtrar ficheros y directorios y también que si escribimos una línea empezando por “#” es un comentario y por tanto no será leida por el programa.

Con esto ya tendríamos que tener todo listo para subir nuestro proyecto de Unity a un repositorio basado en Git.

Nada más por hoy, y espero que os haya servido la entrada. Por ahora me limitaré a seguir programando la demo para sacarla cuanto antes posible y quizás cuelgue algún video de prueba de lo que voy haciendo estos días.

Repositorio del proyecto

Logo de la forja GitHub

GitHub, la forja elegida para subir el proyecto de 1812: La aventura

Antes de empezar con las entradas para desgranar las partes de un Documento de Diseño, quería escribir sobre el sitio dónde he empezado a subir el proyecto. Dicho sitio es un repositorio, que está dentro de una forja.

¿Pero qué es un repositorio? ¿Y una forja?

Pues para explicároslo tengo que hablar de cómo se trabaja en un proyecto (que suponga un trabajo continuado en el que tuviéramos que realizarle revisiones de cuando en cuando) cuándo hay varios trabajadores a la vez:

Normalmente, cuándo trabajamos solos, nos limitamos a guardar nuestro trabajo en una carpeta dentro de nuestro ordenador, sin subirla a internet. Sin embargo, ¿qué pasa si tienes que trabajar con otros compañeros? Pues al principio, nos limitábamos a enviárnoslo por correo. No obstante, esta opción acababa en desorganización por la lista de correos infinitos por cada cambio minúsculo que hiciera cada uno, luego que si un compañero no recibe el correo con la última revisión del trabajo y trabaja con una antigua, etc. Había que ser muy metódico y organizado para evitar todos estos problemas.

Más tarde, con la llegada de la nube, surgieron aplicaciones como Dropbox, Google Drive y SkyDrive que nos permitían sin esfuerzo tener una carpeta en nuestro ordenador y a la vez compartirla con nuestros compañeros instantáneamente. De esta manera, tu puedes trabajar como si solo trabajases para ti, y a la vez que estos cambios repercutiesen a tus compañeros de forma inmediata. Todos tienen la misma versión a la vez, al menos siempre que estés conectado a internet. Y este es el método usado en la actualidad para trabajar en proyectos sencillos en los que involucren a varias personas trabajando en diferentes partes de un proyecto, sin que una persona pueda trabajar en lo mismo que otra.

Llegados a este punto, tengo que explicaros que si bien todo lo anteriormente comentado se cumple, tenemos unos pequeños problemas a solventar si usamos estas herramientas para proyectos informáticos. Además de que, en proyectos de gran tamaño, o que simplemente tenga que haber más de dos personas, van a ocurrir otros problemas.

Los problemas que pueden surgir

En primer lugar, cuando uno está trabajando en trabajos con miles y miles de líneas de código, realizas una modificación, pruebas si funciona, y si es así sigues programando. ¿Y qué pasa si no funciona? Pues intentas arreglar el fallo (o más conocido como bug en estos ámbitos) pero al veces esto puede ser una loteria: intentar arreglar el fallo puede traer más fallos o que directamente no encuentres cuál parte del código es la que entra en conflicto con la tuya. Ante estas situaciones lo más normal es que quieras volver a una versión previa de todo tu trabajo, pero una vez más ¿y si no puedes porque no existe ningún control de qué has hecho y de cuánto tienes que volver atrás en el código (eso si puedes)?

O por otro lado, dos personas trabajando en el mismo código y una guarda sus modificaciones antes que el otro, el sistema no sabrá cuál es la versión correcta si la del primer compañero o la del último y entrará en conflicto. Si tenemos suerte y el sistema que usan lo permite, este generará dos versiones distintas del mismo fichero, y si no, se perderá lo trabajado por uno de ellos dos.

Ante tales problemas, hace bastante tiempo que surgió una solución para el ámbito de proyectos informáticos: el Control de Versiones. Se crearon diversos sistemas (algunos de los más conocidos son Git, Subversion, Mercurial, CVS… ) que lo que permiten hacer es subir a un servidor (sea en tu disco duro o remoto) llamado repositorio todos los datos del proyecto, en el que cada vez que se modifique uno, se crea un registro en el seguimiento de versiones del proyecto. Y en todo momento podremos acceder a la versión del proyecto que queramos, podemos restaurar una versión previa si algo nos sale mal. Podemos incluso dividir el proyecto en ramificaciones para probar diferentes modificaciones y a la vez mantener el proyecto original. Y si ocurre alguna modificación de un fichero porque trabajen varias personas a la vez en el, en el caso de que sean en una parte de código diferente dentro de ese mismo fichero, los cambios se aplicarán a la versión más reciente de ese fichero. si por alguna casualidad trabajan los dos en el mismo trozo de código, el sistema nos preguntará si queremos juntar las versiones modificadas en una sola, indicándonos dónde se efectuarán los cambios en dicho fichero respecto de nuestra versión.

Explicado todo esto, existen lugares por internet llamadas forjas que no son más que lugares en los que te ofrecen su espacio para que te crees un repositorio, y de esta forma la gente pueda colaborar con tu proyecto sin que tú estés en tu ordenador manteniendo el servidor. Como en todos lados, hay distintos tipos de forjas, las hay tanto gratuitas como de pago, y también que usen distintas tecnologías según el Sistema de Control de Versiones instalado.

La que va a utilizar 1812: La aventura es GitHub, una forja gratuita que usa la tecnología Git para realizar el Control de Versiones. Quizás siendo yo la única programadora en un proyecto de no mucha envergadura no parezca en un principio tener demasiado sentido. Ante esto vuelvo a recordaros que todo el proyecto esta dedicado a enseñar a la gente cómo diseñar un juego y, por lo tanto, todo lo que programe será público y a disposición de todos. Y no solo eso,  me sirve para darme la seguridad de no perder el proyecto en caso de problemas con el ordenador, y de poder controlar con totalidad todas las modificaciones de mi proyecto.

Espero que esta entrada os haya despejado más dudas que generarlas, además de que me veía en la obligación de explicar esto para la gente que lo desconociera. Pues estas herramientas para gestionar los proyectos son muy usadas también en el desarrollo de videojuegos. De hecho, hay estudios que usan sus propios sistemas de Control de Versiones para que se adecuen mejor a sus necesidades.

Por ahora solo está lo que he hecho de documentación, pero a finales de la semana que viene espero sacar al menos una demo jugable para que os llevéis una primera impresión.

Repositorio del proyecto