Más información sobre el proyecto Nautilus

Hace dos años traté de llevar a cabo un proyecto llamado Biblioteca de Demos (BDD) y terminé por dejarlo a medias. Si bien mis conocimientos sobre Godot y la producción audiovisual eran inferiores, todavía hoy no detengo mi aprendizaje. Como dicen:

Cada día estoy mejor que ayer y peor que mañana.

Sin embargo, siento que es el momento de retomar esto. Quiero que este blog sea como una biblioteca digital para los estudiantes de Godot Engine. Ha corrido peligro en muchas ocasiones, pues me veo afectado por tiempo y recursos.

Desarrollar assets para Itch.io fue revelador; quizás se convierta en una palanca capaz de impulsar mi sueño del Nautilus, o mejor dicho, la biblioteca del Nautilus: un lugar con proyectos de código abierto desarrollados en GNU/Linux. Aunque entiendo que si la meta es iniciar un proyecto que reciba ayuda de la comunidad, algunos contribuyentes pueden no compartir el ideal de la libertad informática tanto como para usar GNU/Linux… por lo menos yo seguiré con el buey hasta el final.

Sin más preámbulo, pasaré con la documentación del proyecto.

Descripción del proyecto «Nautilus»

Apartado digital que busca recopilar material para el desarrollo de vídeojuegos con herramientas libres o de código abierto. Dentro de él se guardarán demostraciones de juegos indie, además de recursos gráficos o de sonido que puedan ser de utilidad (esto, por desgracia, no entra en mis posibilidades actualmente y en principio sólo me enfocaré en la parte del código fuente).

Todos los recursos de código fuente en la biblioteca deben estar bajo la licencia GPLv3. Significa que cualquier persona podrá modificar y redistribuir el código según sus necesidades.

Objetivos

1. Poner a disposición de los usuarios suficientes recursos digitales que les permitan una formación para sus proyectos o desenvolvimiento en el desarrollo de vídeojuegos.
2. Traer más Software Libre y dejar una marca que pueda sobrevivir el mayor tiempo posible.
3. Generar un ambiente de comunidad entre los desarrolladores, usuarios o no, de GNU/Linux, y los nuevos aficionados.
4. Promover el uso de las herramientas libres y/o open osurce.

Secciones dentro del Nautilus

Para organizar toda la información, la biblioteca se dividirá en “secciones” y cada una representará algo diferente:

1. Demos: por ahora quizás se trate del pilar más importante. Aquí se guardarán los repositorios de los juegos indie y libres, desarrollados en Godot u otra librería. Para que un demo pueda publicarse en la biblioteca debe cumplir con lo siguiente:
   1. Tiene licencia GPLv3.
   2. Si el proyecto se encuentra en GitHub, cuenta con una versión en GitLab (desde este blog sólo se apuntará a repositorios que provengan de ahí.
   3. Sigue la guía de estilo para GDScript (en caso de estar desarrollado con ese lenguaje).
   4. Tiene una descripción del proyecto (con algunas imágenes también) y una lista ordenada para las mecánicas que incluye.
2. Documentación: esta sección almacena todos los tutoriales escritos y en vídeo que se publiquen para complementar algo del apartado «demos». Cada serie de tutoriales dependerá de un proyecto y sus entradas contarán con la etiqueta del mismo. Generalmente, una entrada debe contener divisiones de contenido, además de las comunes que decida el autor, aquí hay unas obligatorias:
   1. Recursos/conocimientos necesarios.
   2. Cómo colaborar.
   3. Créditos.

Entendemos como “demos” cualquier demostración de una mecánica para la jugabilidad en un vídeojuego.

Cuando un demo disponga de artículos que expliquen paso a paso como hacer algo, o que digan por encima cómo funciona todo, colocarán un enlace hasta ese material en la página del demo, y un enlace a esa demostración en la parte del artículo.

Producir una nueva demostración

1. Preparar un documento de presentación entre tres posibles proyectos.
2. Presentar una encuesta para la participación de la comunidad. El más popular pasará a elaborar un documento de diseño.
3. Se definirá un cronograma de trabajo.
4. Se iniciará el desarrollo hasta la culminación del proyecto.

Después de publicar el proyecto, entraremos en una fase de mantenimiento y pruebas, para continuar con el último pilar: la documentación del mismo. Esto «último» consiste en redactar y preparar tutoriales sobre las mecánicas más interesantes del proyecto.

Esto es todo lo que tengo para decir ahora. Al día de hoy, 10 de febrero, todavía hay un proyecto pendiente por publicar: un top-down con assets de ansimuz. Justo con terminar ese proyecto, procederé con documentos para otros tres.