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.

Anuncios

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

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.

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.

Imagen

Adelanto del Documento de Diseño

Empezando a escribir el GDD

Empezando a escribir el GDD

Como podéis ver en la foto, ya estoy empezando con el Documento de Diseño. O más conocido por su nombre en inglés: Game Document Design (GDD). Este documento, es la base sobre la que construir todo nuestro videojuego cuando nos propongamos hacer uno. Sirve tanto para esclarecer las cosas, como para que cada persona involucrada en el proyecto sepa con exactitud su labor en el videojuego. Sin embargo, no existe ninguna manera concreta de cómo organizar este documento y cuáles son las secciones necesarias. Todo esto depende del proyecto en cuestión, del género, y de las necesidades especificas del videojuego en sí, aunque hay algunas guías con directrices para orientarnos, la mayoría en inglés.

Yo, siguiendo el trabajo de otros compañeros como David Saltares (antiguo miembro de mi Escuela Superior de Ingeniería, el cual trabaja a día de hoy para Sony Entertainment Europe en Reino Unido) , he decidido realizar mi GDD en español y liberarlo con la intención de que le sirva a alguien y , de paso, enriquecer la documentación de habla hispana sobre el desarrollo de videojuegos. Al igual que me serví del GDD del proyecto final de carrera de David, conjuntamente con el artículo de Gamasutra sobre consejos de cómo realizar uno, y de varios GDD de aventuras gráficas tales como las de AI Lowe o del videojuego Resonance. Con todo ello, he conformado mi propia versión de un GDD. Uno más centrado en el desengranar cada paso necesario tanto para una aventura gráfica, pero manteniendo la mayoría de los puntos comunes que hay en los videojuegos en general.

Tal y cómo voy a hacer con la memoria de mi proyecto, el GDD tal y cómo se dijo en la presentación de este blog, será liberado bajo licencia GFDL 1.3. Además de eso, he optado por escribir el documento con el lenguaje LaTeX por su versatilidad a la hora de componer textos, introducir bibliografía, etc. Para ello, estoy empleando la web ShareLaTeX, con la que podemos crear nuestros proyectos (documentos), compartirlos con la gente para que lo vea o modifique y que además incluye un compilador online. Realmente, ShareLaTeX, es una herramienta útil a la hora de escribir documentos más avanzados que con Google Docs. El esfuerzo de aprender lo básico del lenguaje LaTeX, en el que por cierto existe un Wikilibro excelente para ello, es gratamente recompensado con la libertad con la que podemos modificar nuestro documento.

Sin más tardanza, os dejo el enlace de mi GDD en ShareLaTex, aunque los no registrados solo podréis ver el texto en LaTeX y no el PDF que resultaría. Cuando esté terminado, lo subiré tanto como en el repositorio del proyecto, como en el blog para el deleite de todos. Y que, cómo siempre, estoy abierta a sugerencias para la modificación del GDD y para nuevas entradas en el blog.

Enlace al GDD en ShareLaTeX.

 

Más colaboradores

Después de un fin de semana cargante escribiendo en la memoria sobre videojuegos serios y/o educativos (si os interesa puedo transcribirlo a una próxima entrada del blog) , y por lo que se avecina también una semana cargadora. Pues servidora se va esta tarde a una reunión de voluntarios sobre el TEDxBaluarte y mañana a la Pixels & coffee en Sevilla. Por fin he podido hacer un hueco para escribir esta entrada, o más bien no me mortifiquéis si cometo faltas escribiendo que lo hago desde un tren a Cádiz en movimiento.

A lo largo de la semana pasada, gracias una pequeña noticia de Games Tribune de mi proyecto, me contactaron nuevamente más personas sobre el proyecto y de que querían colaborar. De nuevo, muchas gracias a todos los que habéis difundido mi proyecto, creo que no se las merece porque será algo medianamente pequeño comparado a lo que espera la gente.

Así que ahora os presento a los dos nuevos colaboradores:
Daniel Bey, alumno del Grado de Ingeniería Industrial de la misma escuela donde he estudiado yo. A pesar de estar en una carrera relativamente distinta a la mía, también desborda pasión por los videojuegos y quiere empezar sus pinitos con el diseño de videojuegos. Su labor principal será la de escribir el guión en español del juego, y la de ayudarme activamente con el diseño de puzzles de forme que, dentro de lo ilógico que resultará el juego, haya algo de lógica y conexión entre los distintos escenarios y puzzles. Espero que nuestro trabajo conjunto de lugar a algunos puzzles que al menos no aburran al jugador, y que como mucho, se entretenga y se lo pase bien.

Encarnación M. R., estudiante de 5° del Grado de Historia de la Universidad de Cádiz. Que siendo de la misma carrera que nuestro protagonista, me guiará con sus anécdotas para el mejor desarrollo del juego. Además de asesorar que no haya incongruencias históricas a lo largo del proyecto. También de manera secundaria, me ayudará a elaborar la “Gadipedia”, una pequeña base de datos con información histórica del 1812 que podremos consultar dentro del juego.

Y esto por ahora. Según la planificación esta semana empezaré con el Documento de Diseño. Así que lo mismo el viernes hay un adelanto sobre él. Eso o lo comentado antes de los videojuegos serios y/o educativos. O mismamente un breve repaso histórico sobre las aventuras gráficas. Ya me comentáis que preferís, sea por el foro de ZehnGames, por twitter, o comentando esta misma entrada.

Saludos y dar las gracias a mi corrector del móvil por hacer posible esta entrada a pesar de las vibraciones del tren.

Planificación del proyecto

Teniendo en mi haber dos jueguecitos terminados y otro en camino (pero este sin un tiempo límite establecido), el concepto de la planificación no es desconocido para nada por mi. Pero fueron trabajos pequeños con fechas concisas al ser hechas para asignaturas, había unas directrices de planificación de antemano. Básicamente, aunque tuviera una maniobrabilidad con la planificación, los milestones o hitos (los puntos de acabado de una fase del proyecto) eran impuestos por la asignatura. Así se evitaba que se pudieran alargar infinitamente un proyecto, o para evaluar a todos con un mismo calibre por haber hecho similares cosas entre los alumnos.

Esta vez, es mi primer proyecto sola ante el peligro. No hay directrices, no hay nada. Mando yo. Y eso es lo que hace que esta parte pueda ser la que con más seguridad varíe del proyecto. Esto nace de mi inexperiencia en este campo. Usualmente en la industria de los videojuegos, esto lo lleva un Productor, una persona ya experimentada y que suele tener una idea precisa de cuanto suele tardar cada apartado de un videojuego y guía su desarrollo a buen puerto, además de negociar los contratos de su empresa. Esto en estudios pequeños, suele hacerlo una persona con otros cargos más, normalmente el Diseñador (o al menos eso tengo entendido) por ser el que más idea tiene sobre la dirección que debe seguir el proyecto.

En otros estudios más grandes, el Productor trabaja solo de eso y acaba a veces casi siendo una eminencia. Casos de estos son Shigeru Miyamoto, Hideo Kojima, Michel Ancel, etc.

Pero bueno, como toda experiencia, esta se tiene que forjar y ya es hora de afrontarla sin miedo. Haré uso del ojo de buen cubero para calcular cuanto me llevaría en cada cosa aproximadamente. Pero tened por seguro que esta versión preliminar será difícil de llevarla, al menos en el sentido más estricto. Los plazos los he elegido dentro de un marco realista pero sin querer abusar de días. En un principio, mi intención es presentar el proyecto en Julio, y Septiembre a más tardar, si por motivos ajenos al proyecto no puedo terminarlo para la primera fecha.  Pero por si acaso haré la planificación hasta Septiembre.

Aún así, iré haciendo un registro del progreso real, de manera que así pueda compararlo con la planificación estipulada. Cuando acabe el desarrollo del proyecto, compararemos los dos y así se verán dónde se produjeron las inexactitudes que las comentaré en el Post-Mortem al finalizar el proyecto.

La planificación está hecha con Gantter, un planificador de proyectos online que permite establecer tareas y asignárselas a personas generando un Diagrama de Gantt. Es muy sencillo de utilizar, siendo más ligero que otros software de gestión de proyectos más complejos, pero para las necesidades del proyecto es adecuado. Además, permite que los otros colaboradores del proyecto puedan editarlo tal y como ellos consideren apropiado para sus tareas.

En líneas generales el proyecto se divide en:

  • Formación: Todo lo relacionado con aprender historia y las herramientas necesarias para la realización del proyecto.
  • Juego: Análisis, diseño, implementación y pruebas para crear el videojuego.
  • Arte: Todo lo relacionado con gráficos, músicas y texto necesarios para el videojuego.
  • Memoria: Toda la información sobre cómo se ha realizado el proyecto.

 

Podéis acceder al Diagrama de Gantt de forma online aquí.

Nuevas colaboraciones

En los tres días que he promocionado un poco mi proyecto, no me esperaba la difusión y aceptación que ha tenido entre la gente. ¡Muchas gracias, de verdad!

Ha sido relativamente fácil con la ayuda de todos, y ahora me dispongo a presentar a los nuevos colaboradores. Espero que acabemos haciendo buenas migas todos y aprenda algo de la experiencia de trabajar en un equipo multidisciplinar.

Bueno no os hago esperar más y os los presento:

En primer lugar, tenemos a Celia Fermoselle, la grafista y animadora 2D para el videojuego. Ella ya cuenta con experiencia previa en trabajos realizados con pixel art, algunos incluso a nivel profesional (de hecho, ahora mismo realiza encargos personalizados por twitter). Tendremos que hacer un trabajo conjunto desde el principio, pues tendremos que elegir entre las dos un estilo simple y que a la vez nos reconforte, para no sobrecargarnos de trabajo. Como ella vive en Madrid, el trabajo de localización de escenarios, al ser basados en la Cádiz actual, lo tendré que hacer prácticamente yo entero. Realizaré muchas fotografías y esbozos de escenarios, los cuales colgaré en el blog, para guiarla a la hora de realizar un trabajo. Este trabajo usualmente se haría con un equipo artístico con una persona encargada específica para esa tarea, pero al ser reducido, hay que asumir el trabajo de otras áreas.

Luego tenemos a boredBit, un grupo de Málaga que se dedican a componer músicas. Su deseo es poder dedicarse a hacer bandas sonoras de cine y videojuegos. Siempre están buscando algún trabajo que hacer, así que si necesitáis alguna música para vuestros trabajos, ¡contactad con ellos! Realmente este es el campo más desconocido por mí para tener una idea concreta de qué quiero exactamente, pensé en canciones ambientales para no cargar al jugador. Al final, como hay relativamente bastante tiempo hasta cuando sea necesaria la música en el videojuego, decidimos en que ellos compondrían algunos ejemplos y así elegir e irnos aclarando de por dónde van los tiros.

Por último y no menos importante, Laura J. Torres , quien se encargará de la traducción del videojuego al inglés. Para así poner en práctica el sistema que programaré de separar el texto del juego del código, no solo ya en español, sino en otro idioma, y así en cualquier momento poder cambiar el idioma de este sin problemas. Además de ayudarme a mejorar este sistema para, una vez finalizado el proyecto, crear un manual para indicar como editar e incluir nuevas traducciones incluso para personas que desconocen la programación.

Ah, todo el apartado artístico estará bajo licencia CreativeCommons, excepto la traducción de Laura, que será bajo licencia GPLv3 . Hay que respetar que como dueños de sus obras que son, tienen el derecho de decidir cómo licenciarlas. Yo por mi parte también haré uso de la licencia GPLv3 para toda la documentación y el código.

 

Y antes de despedirme de esta entrada, algunas consideraciones.

Me he dado cuenta que la difusión por Twitter, el tener algunos contactos, y el promocionarlo un poco, ha sido vital para encontrar colaboradores tan rápido.

En este caso puedo decir que, a Celia la conocí gracias a alguien que sigo por Twitter y tengo un poco de contacto profesional, Marina.

Laura también era otra persona que seguía por la misma red social, y con la que aún siendo bastante desconocidas la una de la otra, mantenemos un poco de contacto. Lo suficiente como para saber que estudia Traducciones en Sevilla y compartimos algunas aficiones.

Por otro lado, gracias a ZehnGames y sus foros, Indiefence, GamesTribune, y muchos otros más, encontré a boredBit. Con ellos llegué rápidamente a un acuerdo y aceptaron ayudar.

 

Así que mis últimas palabras son:

Aunque sea poco, hay que movilizarse y hacer contactos, sea en redes sociales y foros; pero si consigues un espectro pequeño y luego saber dónde publicar tu información, la ayuda acabará llegando tarde o temprano. Y creedme, antes del inicio de esta semana creía que nadie se fijaría en mi proyecto y pasaría desapercibida.

¡Gracias a todos!