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

Bienvenidos a 1812: La aventura

Bienvenidos a 1812: La aventura, un blog centrado en el seguimiento del desarrollo del videojuego con el mismo nombre. Mi intención con ello es, acercarme un poco más al mundo profesional, pues mi pasión es la de desarrollar videojuegos y mi sueño el dedicarme profesionalmente al diseño de videojuegos.

El videojuego del que relataré mis aventuras y desventuras, tal y cómo sugiere su nombre, es sobre la historia del año 1812. Concretamente hablamos de Cádiz en el año 1812, año de la primera Constitución en España. En él, controlaremos a un estudiante del Grado de Historia de la Universidad de Cádiz, en el que recientemente ha suspendido un examen y va al despacho a pedir una revisión para su nota, sin embargo, no logra encontrar al profesor y se embarcará en una aventura para descubrir su paradero, ayudándose de las pistas obtenidas al resolver los puzles que nos encontremos.

¿Habrá sido raptado por una conspiración, se habrá escabullido de arreglar la nota?

1812: La aventura se desarrollará en Unity3D y su código será alojado en un repositorio de GitHub bajo licencia GPLv3, todo debidamente documentado. Pues uno de mis objetivos con este proyecto es la de generar documentos de diseño de videojuegos de mediana complejidad en español de manera libre, y el otro, la de hacer el videojuego como apoyo didáctico en la enseñanza de esa época histórica. Si queréis saber más, tenéis la sección “Sobre el proyecto“, o si quieres cotillear un poco sobre mí, la sección “Sobre la autora“.

Por otro lado, actualmente estoy en búsqueda de colaboración para el proyecto, podéis consultar la sección “Colaboraciones” si os interesa.

Espero que disfrutéis de la aventura de leer el blog,  happy reading!