Estado

Primera demo jugable

Buenas a todos, después de bastante tiempo os traigo por fin la primera demo. Se han implementado prácticamente todas las mecánicas para empezar a hacer el juego propiamente dicho, exceptuando el pathfinding, los diversos menú del juego y algunas pequeñas mejorías necesarias para mejorar la experiencia.

Sigue leyendo

Anuncios
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