Ya hemos creado nuestro proyecto de Fabric, pero ¿qué son todas estas carpetas y todos estos archivos nuevos? ¿Cómo funciona nuestro build.gradle? Vamos a verlo hoy mismo.
Diferenciación entre cliente y servidor
Hemos de empezar a separar dos programas diferentes, que son el cliente de Minecraft y el servidor de Minecraft. Es cierto que ambos comparten mucho código, como por ejemplo los ítems, los bloques, pero otras cosas, como por ejemplo la renderización del juego, solo es necesaria en el cliente, con lo cual el servidor no lo tiene. ¿Eso qué significa? Que si ejecutamos código de nuestro mod que llama a la renderización de Minecraft en el servidor, el servidor fallará.
Fabric nos ayuda a diferenciar nuestro código del cliente, del servidor y del que es común, el que correrá en ambos programas. Esto lo veremos adelante cómo se realiza, simplemente tener esta separación de programas en mente.
Diferenciación de Threads
Aparte de la diferenciación entre cliente y servidor, Minecraft corre tareas en diferentes hilos o threads. ¿Qué significa? Que si queremos manipular una cosa de cliente o servidor que corre en otro thread del principal, tendremos que adaptar nuestro código para correr esa modificación dentro de ese thread. Por ejemplo, la generación del mundo va en un thread aparte que el principal, con lo cual si queremos modificar la generación del mundo tendremos que estar al tanto de usar el thread correcto. Otro ejemplo podría ser la renderización. El código de Minecraft que se encarga de renderizar va en otro thread aparte del principal, con lo cual si queremos modificar la renderización del juego nos hemos de acordar de utilizar el render thread.
Módulos
Primero de todo, vamos a fijarnos en las nuevas carpetas. Vamos a ver que tenemos un proyecto de Gradle con múltiples módulos, uno que es el client y otro que es el main. Se sobreentiende por los nombres, la carpeta client
será código que solo correrá en el cliente y el main es código para ambos. Aquí podríamos añadir otro módulo únicamente dedicado al servidor, pero por norma general esto no hace falta.
Resources
Si nos seguimos adentrando en las carpetas, encontraremos la carpeta Resources. Esta se encuentra tanto en el módulo Client como en el Main, pero en el Main tiene más peso. Aquí guardaremos toda la información que incluirá el mod, como especificaciones de ítems, de bloques, especificaciones del mod y de los mixins...
fabric.mod.json
El archivo fabric.mod.json
contendrá toda la información sobre nuestro mod, esto incluye un id, un nombre, una descripción, una url, incluso autores, dependencias, versión de minecraft, muchas cosas. Podéis encontrar más información en la web oficial.
Aquí hemos de empezar a cambiar cosas. Hemos de empezar por cambiar el ID, luego opcionalmente podemos cambiar el nombre, descripción, autores, web... lo que os apetezca. Y por último, los entry points. En los entry points especificaremos nuestras clases principales tanto para el módulo de main como para el módulo de cliente.
También podemos refactorizar con IntellIj.
Podemos eliminar los archivos de Mixin, ya que por ahora no los usaremos.
assets
En la carpeta Assets es donde se guardarán todos los recursos de nuestro mod, como texturas o declaraciones. Lo que habríamos de hacer ahora es cambiar la carpeta ModID que tenemos como placeholder al ID que le hemos puesto en nuestro mod en archivo de antes.
Gradle
Ahora vamos a analizar un poco todo el tema de Gradle.
build.gradle
Si entramos a nuestro build.gradle
, veremos cómo estamos utilizando un plugin llamado Fabric Loom. Este plugin, como hemos visto antes, nos añade las tareas de runClient
, runServer
, bueno, todas las que están debajo del nombre de Fabric.
También, como vemos, nos añade un bloque de configuración llamado Loom, donde por ahora cambiaremos el modID por el ID que hemos puesto antes.
Y en las dependencias veremos cómo hay dependencias de Minecraft, de mappings y nuevas tareas como modimplementation
. Luego también veremos cómo funcionan includes y temas de estos, pero más adelante.
gradle.properties
Si entramos a nuestro Gradle.properties
veremos un montón de variables declaradas con diferentes valores, en este caso versiones de Minecraft, versiones de los mappings e incluso la versión de nuestro mod. Aquí hemos de ajustar el Maven Group y el Archives Base Name.
Código inicial
Una vez conocemos un poco nuestro proyecto, vamos a ver el código que se nos ha generado automáticamente en nuestro archivo CursoFabricMod
y CursoFabricModClient
.
En este veremos que es una clase que implementa ModInitializer
. Esta es la clase de entrada de nuestro mod, ya sea servidor o cliente. Para empezar vemos un simple logger que usaremos para poner mensajes en consola y aquí sería ideal que cambiáramos el modid
.
Luego abajo tenemos el método onInitialize
. Este es el primer método que se corre al cargar el mod. Cogemos el mensaje que hemos visto en el primer episodio donde cargaba el plugin. Es ese que sale ahí. Aquí sería ideal registrar todas las cosas que incluye nuestro mod.
Luego podemos analizar nuestro archivo CursoFabricModClient
, que por aquí será donde entrará el mod de cliente. Cuando el mod cargue en el cliente, primero entrará por el archivo principal, el CursoFabricMod
, y luego el CursoFabricModClient
.
Si nos fijamos, éste implementa clientModInitializer
y tiene un método onInitializeClient
que es donde registraremos todas las cosas relacionadas con el cliente que no se registran en común, como por ejemplo, temas de renderización.