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.

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 →

Diseñando un juego #2: controles y mecánicas básicas

Después de un tiempo sin escribir, ya tocaba volver a realizar otra entrada para el blog. Desde la entrada anterior me he estado dedicando a terminar de elaborar el primer puzzle del juego (con su correspondiente documentación) además de parte del segundo, por lo que lo más lógico sería hablar de eso en esta entrada. Sin embargo, aún no me considero con los conocimientos suficientes para hablar sobre cómo hay que hacer los puzzles de una manera básica, teniendo en cuenta que, para mí, también es la primera vez que los elaboro. Por ello, prefiero relegar esa entrada para más adelante, contando mi experiencia al término de realizarlos y sobre los pasos que seguí para conseguirlo, sean los mejores o no.

Así pues, voy a dedicar esta entrada a los elementos que he ido enseñando en los vídeos, que son los controles y mecánicas en un juego. Esto lo comentamos brevemente en la entrada que escribí sobre lo básico para empezar a diseñar un videojuego y que, ciertamente, el argumento y la ambientación (en el caso de que la haya) pueden ser relevantes para que un jugador disfrute con nuestro juego. No obstante, el núcleo y la principal fuente de diversión de nuestro juego siempre serán las mecánicas de juego acompañados de un diseño de niveles que le proporcionen un reto superable al jugador. En otras palabras, el cómo lo jugamos.

Aunque hay que hacer el inciso de que es igualmente importante el diseño de niveles, en el que usando las mecánicas diseñadas hay que crear un reto, el cual siempre ofrece un desafío más difícil o complejo que el anterior, para así lograr mantener el interés del jugador. Además de muchas más cosas a tener en cuenta, que procederé a escribir más adelante en otra entrada.

De la misma forma, un juego que goce de unos gráficos exquisitos y de un argumento espléndido puede inspirar aversión hacia el usuario si sus controles y mecánicas son complejas, tediosas o han sido mal diseñadas. Sin embargo, si esas mecánicas son fácilmente asimilables e incluso adictivas, unidas a un diseño capaz de mantener la atención del jugador por el reto que ofrece, dará igual todo lo anterior. Y si no, que se lo digan a los juegos clásicos que han acabado en la cultura popular (Tetris, Pacman, Space Invaders…) o incluso juegos más actuales que técnicamente carecen de gráficos (VVVVV) o historia (Counter Strike, Worms).

Centrándonos en el tema, una vez que tengamos una ligera idea de sobre qué queremos hacer el juego, debemos preguntarnos:

¿De cuáles acciones dispondrá el jugador para interactuar con el entorno que le ofrece el juego? Estas pueden ser tan básicas como caminar o saltar, o ser cada vez más complejas como disparar diferente según las armas de que disponga, lanzar conjuros que realicen diferentes cosas, etc. Todo esto sin olvidarnos de posibles acciones necesarias para poder interactuar con los menús disponibles en el juego.
¿Qué realizan dichas acciones? Puede parecer un poco obvio el comentar que hace cada acción, pero realmente es necesario para tener claro qué hace la acción paso a paso, y de cómo afectan a otros elementos o al mismo jugador. Así evitamos interpretaciones erróneas de las acciones por otros miembros del equipo que desarrollen el juego.
¿Cuándo se podrán realizar dichas acciones? No siempre tendremos las mismas acciones para todos los elementos disponibles en el juego ni todas las acciones se pueden hacer bajo las mismas condiciones. Por ejemplo, si un personaje está agachado para evitar que lo detecten, no podrá correr, o si está en mitad de un salto, no podrá saltar otra vez. O lo mismo un objeto del juego, no se puede coger pero si examinar.
¿Cómo se pueden ejecutar las acciones? Para ello, es necesario saber de qué tipo de controles vamos a poder usar, dependiendo de la plataforma a la que estará destinada el juego sea un smartphone o tablet, consola u ordenador. Según nuestra plataforma elegida dispondremos de trazos y toques en una pantalla táctil, joysticks, botones, o teclas y ratón. Una vez elegida la plataforma y sabiendo de los controles disponibles, tendremos que ir asignandole a estos una acción a realizar, o incluso que si ejecutamos una serie de controles de una forma en concreto, también se haga. Pero cuidado, no es cuestión de asignar de forma aleatoria los controles y ya está, hay que tener en cuenta que estos se tienen que poder realizar de manera cómoda con los controles disponibles. Por ejemplo, en el caso de usar un mando, dispondremos las acciones que más se vayan a utilizar, en los botones más accesibles en el mando, y si se requiere de una combinación de botones para realizar otra acción, que estos dos botones sean fáciles de pulsar a la vez.

Cómo veis, a pesar de ser un tema relativamente sencillo, hay que pensarlo concienzudamente porque es con lo único que el jugador va a poder usar para comunicarse con el juego. Y si esta comunicación falla, todo lo demás se va desmoronando conforme el jugador se va frustrando por su impotencia. ¿Os imagináis jugar con las manos atadas y que os pidan pulsar tres botones a la vez para poder saltar en un juego? Pues esa es la idea a evitar.

Una vez más, espero que os haya gustado mi breve (pero larga) visión sobre cómo diseñar acciones para nuestro juego. Y si tenéis algún comentario, objeción o mejora, no dudéis en comentármelo por aquí o por las redes sociales.

Hasta la próxima entrada.

Vídeo de muestra #2: Prueba de coger objetos y usar el inventario

Después de otra semana entera programando, por fin os traigo un nuevo vídeo sobre cómo va el proyecto. Ya queda menos para la demo pero aún quedan unas cuantas cosas por hacer antes de lanzarla.

Tengo que admitir que esperaba que programar el inventario y los objetos del inventario solo me iba a ocupar un par de días. Que equivocada estaba. He tenido que aprender por el camino el uso de delegar eventos, los listener de eventos, objetos (tanto del inventario como del escenario) que realizan acciones distintas según sea el estado del otro con el que interactúan, y alguna que otra cosa más. Y un par de reajustes en el control de estados para la situación especial que supone usar un objeto del inventario en el escenario.

Las funcionalidades que he programado para este vídeo son:

Inventario que se abre y se cierra al hacer click izquierdo sobre la barra superior de este, y que a su vez también lo hagan los objetos del inventario. Para lograr este efecto con los objetos del inventario, lo que he hecho es que sean hijos del gameobject del inventario. Así si este se mueve, también lo harán los gameobject de los objetos del inventario anidados en él.
Añadir un objeto al inventario si interactuamos con un objeto del escenario que se puede coger con click derecho.
Función de examinar un objeto del inventario para obtener una descripción más detallada de él al hacer click izquierdo sobre él.
Al realizar click derecho sobre un objeto del inventario, lo arrastraremos con el ratón hasta que volvamos a hacer click derecho con él, de ser así, volverá al inventario y en el caso de haberse sido usado encima de un objeto del escenario con el que puede interactuar, realizará la acción pertinente.
Durante la interacción entre el objeto del escenario y el del inventario, la acción a realizar dependerá del estado actual de dichos objetos. Y en algunos casos incluso se borrará el objeto del inventario después de su utilización.

Si bien ya tengo las mecánicas de interacción en el escenario totalmente implementadas, aún quedar hacer algunos arreglos. Lo siguiente será el sistema de automatización de escenas en cuanto ocurran ciertas cosas en el escenario y un sistema de guardado de variables para cuando se cambie de escenario, de manera que si salimos de un escenario y volvemos a entrar, todo siga estando tal y cómo lo dejamos. Una vez implementados estos, podré centrarme en sistemas más internos como el de pathfinding y la localización de los textos.

Una vez más, espero que os haya gustado el vídeo y gracias a todo por la difusión del proyecto.

Normas de estilo para el código

Después de unas semanas dedicadas a la familia, toca entrada por fin. Aunque por ahora me limitaré a entradas cortas sobre temas específicos y un poco más centrados en el código, pues ahora toca retomar y acabar con algunos temas pendientes tales como terminar la demo, finalizar los retoques del documento de puzzles y actualizar el documento de diseño con los pequeños cambios que van surgiendo con el desarrollo.

De estas entradas de carácter corto, en esta en concreto trataremos algo que muchos novatos programadores se olvidan, o que ni siquiera saben que existe: las normas de estilo (en inglés se suele denominar como coding guidelines).

Tal como os puse en situación con la entrada del control de versiones en los proyectos y de cómo era necesario no sólo para tener una copia controlada del proyecto, sino en el caso de varios programadores a la vez, este es otro de los elementos necesarios en el caso de que varios programadores trabajen a la vez y tengan que leer los códigos de otros. O simplemente para que el código sea más fácil de leer para otras personas una vez publicado.

Y esto es un problema que se adquiere por aprender a programar sin tener estos factores de que tu código no solo lo tienes que entender tú, también tiene que ser comprensible para todos los demás.

Esto es algo muy importante, pues si varios programadores escriben el código cada uno siguiendo sus propias normas, llegará un punto en el que si otra persona no entiende que es lo que está haciendo el otro, ralentizando el ritmo del grupo (has de dedicar un tiempo a comprender qué quería hacer el otro programador con el código que lees) y creando confusión y/o diversidad de opiniones sobre como debería haberse escrito X código. Todo ese tiempo perdido se podría haber empleado en seguir trabajando en el proyecto, y lo que es peor, no será una situación que se dé de manera excepcional, sino que se dará de manera habitual.

Si dichos programadores llegasen a un acuerdo de cómo escribir el código de forma que los dos lo escribiesen de la misma forma, lograrían un código uniforme y fácilmente legible, evitando esta situación.

Algunos casos prácticos simples son tabular siempre con cuatro espacios los códigos anidados, poner saltos de línea en los bloques de código if/else sin importar su longitud, poner nombres explicativos a las funciones y variables usando la notación CamelCase sin importar lo largos que sean estos.

Muchas empresas y organizaciones ya proporcionan sus propias normas de estilo, algunas prácticamente a nivel de estándar internacional, para que lo tomen en cuenta los programadores profesionales para que a la hora de embarcarse en proyectos sea de la envergadura que sea, tengan en cuenta estas facilidades sin tener que crearse sus propias normas.

Algunas de las normas más conocidas son la de Google para C++, la de Microsoft para C#, o unas de las más completas que puede aplicarse en la gran mayoría de los lenguajes es de la PHP creada por PHP The Right Way.

Lamentablemente de Unity no hay ninguna convención que esté más o menos estandarizada, así que para 1812: La aventura he decidido adoptar algunas normas de estilo que están más o menos aceptadas. El formato que he elegido es el presente en la página de Unity Gems, que os la recomiendo visitar pues contiene artículos variados y muy útiles sobre Unity.

Y hasta aquí esta entrada, si conocéis más normas de estilo que consideráis que debería mencionar aquí, no dudéis en comunicármelo y las pondré.

Espero, como siempre, que esta entrada os haya servido y que los novatos os vayáis dando cuenta de los muchos detalles que hay que tener en cuenta a la hora de empezar un videojuego, para que al menos tengáis unas garantías sino de éxito al realizar el juego, pero al menos amenizaros el trabajo lo más posible.

Vídeo de muestra #1: Prueba de animaciones e interacciones básicas

Después de pegarme una paliza esta semana programando para la demo y, por consiguiente, también para el juego (pues el código se reutilizará), aquí os traigo una muestra de lo que he hecho esta semana.

La verdad es que para ser la primera vez que programo un juego con cierta complejidad, me ha gustado el que haya sido capaz de aprender a manejar algunas funcionalidades y código para luego aplicarlas a mis scripts de control del personaje en el corto plazo de una semana.

Las funcionalidades que he programado para este vídeo son:

Control de animaciones por máquina de estados en script y que este modifique los valores necesarios para que Mecanim (la máquina de estados que aparece en el vídeo) cambie a las animaciones correspondientes.
Función de ir a un sitio (sin sistema de navegación aún, sólo camino directo) o examinar con click izquierdo si le damos a un objeto interaccionable, en ese caso el personaje irá hasta dicho objeto y hablará para comentar lo que ve.
Función de interactuar con los objetos interaccionables con click derecho. Dependiendo del tipo de objeto interaccionable hará una cosa u otra, en el caso del vídeo la puerta solo es un objeto examinable y la ventana es un objeto con mecanismo (abrir y cerrar).
Diálogos que cambien según la información que nos dé el objeto.

Falta por implementar aún muchas cosas. Por ahora lo siguiente a implementar será el sistema de inventario, seguido del control de escenas en el caso de escenas automatizadas o que ocurra un evento y modifique el escenario. Más tarde me dedicaré a los sistemas de navegación para que el personaje se mueva por rutas en el escenario y el de localización de textos.

Todo lo que se muestra en el vídeo ya está disponible en el repositorio de GitHub, pero no aconsejo aún a la gente que ojee el código pues aún no he comentado el código para su documentación con Doxygen, estoy esperandome a terminar la demo para ello.

Espero que os haya gustado el vídeo, y con suerte para el final de esta semana o principios de la siguiente tenga otro vídeo con el que deleitaros.

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

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.

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
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
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.

Diseñando un juego : Tengo una idea

Ya puestos a comenzar a destripar las partes más importantes de un GDD (Game Design Document o Documento de Diseño en español, recordemos), ¿qué mejor sitio que empezar por dónde comienza todo? Tal cómo indica el título de la entrada, hablo de las ideas de las que todos los juegos nacen. Tener una idea es muy sencillo, solo falta darte un paseo, ver una película, dormir, tomarse una ducha, mientras estamos haciendo nuestras necesidades… Cualquier cosa o momento que te inspire, divierta o transmita algo. A gusto de cada uno es el cómo obtener dicha idea. Pero, ¿cuántas veces hemos escuchado (o leído en los foros) a alguien decir que tiene una idea buenísima (normalmente un The Legend of Final Fantasy) y que necesita a un equipo que le haga el juego? Todos hemos caído alguna vez en esto, yo inclusive. Y es que, ay amigos, esto es porque a muchos de nosotros aún nos cuesta entender que una idea por buena que sea, necesita ser trabajada.

Al igual que se tratase de una planta, la idea de un juego es la semilla de la que nace todo juego, pero para que esta tenga frutos hay que cuidarla y desarrollarla.

Entonces, ¿que hay que hacer cuando tienes una idea?

Pues dependiendo de lo avanzada o difusa que tengamos la idea, se puede optar por hacer un pequeña lluvia de ideas, de forma que fluyan mejoras que avancen la idea o cambios (¡o incluso encontrar una idea mejor aún!). Y ojo, tener una idea con relación a una historia o mundo esta bien, pero recordad que un juego no es (ni siquiera en un JRPG) sólo su historia, sino también sus mecánicas, así que vendría bien (o mejor que una historia) pensar en cómo queremos que se juegue nuestro juego.

Una vez tengamos una idea más o menos consolidada, tristemente tenemos que bajar a tierra. Todo siempre es bonito en la cabeza tal y cómo imaginamos, pero otra cosa es lo que nuestras manos o mentes puedan hacer con ello.

Porque, en primer lugar, hay que plantearse la difícil pregunta de: «¿Puedo yo con mis habilidades hacer dicho juego con mi idea?» Y NO vale en dicha pregunta el que me lo haga otro. Si es así, felicidades. Eres un hacha diseñando videojuegos, porque lo normal es que prácticamente nunca, y menos si no tenemos un estudio profesional con varias (o cientos) de personas profesionales, puedas hacer tu grandísimo videojuego de tu grandísima idea decentemente. Básicamente, es mejor tener una idea pequeña y sencilla que veamos factible de ser capaces de realizar en videojuego que una idea grande para un videojuego grande que no podamos realizar y acabemos abandonando nuestro proyecto por la frustración que supone el no poder desarrollarlo tal y cómo queriamos. Y, con suerte, con la experiencia que ganemos podremos irnos permitiendo realizar ideas cada vez más grandes y mejores. Palabra de una persona que ha pasado por esto y de la frustración acabó estudiando Informática para desarrollar videojuegos.

Cuando ya tengamos una idea que se amolde a nuestras capacidades, podremos ir desarrollando aspectos del juego a partir de nuestra idea. Los principal que deberíamos preguntarnos cuando empezamos con la base de nuestro juego son las siguientes cuestiones:

¿Qué queremos, un juego en 2D o en 3D?
Y una vez elegida las dimensiones del juego, ¿qué estilo artístico queremos?
¿ De qué género o mezcla de género queremos que sea el juego? Pues influirán en las mecánicas.
¿Qué tipo de ambientación tendrá? Pues varía dependiendo de si quieres uno de fantasía o de ciencia ficción.
¿Qué tipo de público queremos que juegue nuestro juego? ¿Uno de temática juvenil, adulta o para todos los públicos?

Si hemos podido responder a estas preguntas, ¡enhorabuena! Ya has dado el primer paso en cuanto al diseño de videojuegos.

Espero que os haya gustado esta entrada, básica pero necesaria. En un futuro hablaré de otros elementos más específicos a tratar en cuanto al diseño, pero con lo de hoy ya tenemos lo básico para que nuestro proyecto pueda empezar a marchar.

Repositorio del proyecto

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

Finalizado el Documento de Diseño

Han sido unas semanas duras, no solo por el hecho de escribir semejante cantidad de páginas casi de una vez, si no por otros hechos. La mayoría no son relevantes para este blog de seguimiento del proyecto, pero al menos comentaré uno de los principales motivos de mi retraso: iré a la Gamelab y a la Indie Burguer Developer Awards en Barcelona del 26 al 28 de este mes. Ha sido un enorme jaleo el organizar el viaje, sobretodo por la parte económica para que no se disparara demasiado, pero finalmente ha salido todo bien. Todo gracias a los compañeros de Videoshock que me han invitado a estos eventos, y a los que finalmente podré desvirtualizarlos a ellos y a otros muchos más que se animen a saludarme.

También decir que espero que no ocurran atrasos tan grandes como este para las próximas partes de desarrollo del proyecto. Pues escribir un documento de diseño, o GDD (Game Design Document) para abreviar, tal y como el que he hecho desde 0, a pesar de contar con la guía de los otros documentos comentados en la anterior entrada, ha supuesto un enorme esfuerzo.

Sin más dilación, aquí tenéis el GDD de 1812: La aventura, del cual os comentaré algunas cosas que tendréis que tener en cuenta a la hora de leerlo:

Enlace al documento de diseño

Una vez le hayáis dado un vistazo, os habréis dado cuenta de la gran cantidad de páginas que componen este GDD. Son 53 páginas a día de la publicación de esta entrada, y seguramente en un futuro aumentará en bastantes más.

¿A qué es debido esto si estamos hablando de un juego que va a durar entre 30 y 45 minutos? Pues a que gran parte de este documento no es sólo para mí, quiero dejarlo como guía (o biblia por el tamaño) para las futuras personas que quieras realizar un GDD. Por ello me he tomado la molestia de organizarlo en tantas secciones, y en cada la mayoría de estas, explicar en qué consiste cada capítulo y sección. Logrando destripar la mayoría de las partes que debería contener la mayoría de los videojuegos. Así, cualquier persona que quiera aprender sobre cómo realizar un GDD, sepa en todo lo que tiene que pensar a la hora de realizar el suyo propio. De hecho, futuras entradas en este blog serán para desglosar distintas partes (al menos las más importantes o a las que hay que hacer una mención especial) que componen este GDD.

Pues, seamos sinceros, un diseñador de videojuegos profesional no hubiera malgastado tanto tiempo en describir todas las secciones, algunas incluso que ni son pertinentes para 1812: La aventura. Lo que uno de verdad hubiera hecho en mi opinión (y espero que alguno de verdad me lo corrobore o me desmienta) es escribir directamente lo que necesita el videojuego, descartando las demás secciones o presuponiendo otras. E incluso ni hubiera escrito tanto texto en las partes que si hubieran necesitado escribir, si no, simplemente, realizar dibujos y esquemas con los que sus compañeros hubieran entendido rápidamente las mecánicas y el diseño a seguir en el juego.

Diseño de las estancias del castillo de Unepic, hecho en un cuaderno.

Como veis, en la vida profesional, el GDD se adapta al diseñador y a sus limitaciones, pero en mi caso he optado a una versión más académica con todo lo que he considerado oportuno de incluir para un videojuego genérico, además de explicar cada sección.

Cómo último punto a comentar sobre el GDD, decir que no está completo y faltan varios elementos. Esto es porque, un GDD avanza a la vez que el proyecto, es lo que se llama un documento vivo en el que los desarrolladores del proyecto tendrán que revisar casi todos los días si existe una versión nueva, y si esta versión influye en su área de trabajo.

Y esto es todo por ahora, espero que os haya agradado mi trabajo y espero, de verdad, que sirva de inspiración para otros futuros diseñadores de videojuegos.