
Architectury API: Escribe mods para Minecraft en cualquier p
architectury/architectury-api
Una API intermediaria destinada a facilitar el desarrollo de mods multiplataforma.
Ver en GitHub ↗¿Cansado de escribir mods separados para Fabric y Forge? Architectury API te permite escribir tu código una sola vez e implementarlo en múltiples cargadores sin duplicar la mitad de tu proyecto. Es el marco de trabajo que transforma el desarrollo multiplatforma de mods de una tarea frustrante a algo realmente práctico.
Qué hace esta API
Architectury API no es solo otra biblioteca. Es una capa de traducción entre dos formas fundamentalmente diferentes de hacer mods para Minecraft.
Imagínalo así: Has construido un mod brillante para Forge. Luego alguien pregunta si funciona en Fabric. Resulta que no, porque Forge y Fabric implementan sistemas básicos de formas completamente diferentes, y has entrelazado código específico del cargador en todo tu proyecto. Ahora te enfrentas a meses de reescrituras para que el mismo mod funcione en otra plataforma.
Ese es exactamente el problema que Architectury resuelve. Pero proporciona una interfaz unificada para que tu mod pueda llamar a cualquier cargador en el que esté ejecutándose sin importarle las diferencias subyacentes. ¿Forge tiene código diferente que Fabric? Architectury lo maneja por ti. El proyecto proporciona más de 90 hooks de eventos y abstracciones para registros, redes y detección de cargadores. No estás reimplementando todo el panorama de APIs, sino obteniendo una capa de traducción sensata que habla ambos idiomas con fluidez.
Por qué los desarrolladores de mods quieren esto
Aquí está la cruda verdad del desarrollo multiplatforma de la vieja escuela: construirías tu mod, lo probarías, corregirías errores, añadirías características... y luego lo harías todo de nuevo para el otro cargador. Cada corrección de errores necesitaba llegar a dos lugares. Cada nueva función significaba el doble de trabajo. La mayoría de los modders simplemente elegían una plataforma y ya.
Con Architectury, mantienes código compartido en un módulo común y colocas contenido específico de la plataforma en carpetas separadas. La mayoría de tu lógica existe una sola vez y funciona en todas partes. Eso es genuinamente poderoso cuando estás manteniendo un mod durante meses o años. Pero también significa que no estás eligiendo entre comunidades. Algunos jugadores prefieren cargadores Fabric, especialmente Quilt, otros se adhieren a Forge. Consulta la lista de servidores en minecraft.how y verás comunidades multijugador usando modpacks completamente diferentes, cada una con sus propias preferencias de cargador. Al apoyar múltiples plataformas, llegas a ambas audiencias en lugar de dejar una varada.
La anotación @ExpectPlatform: Cómo funciona
El README menciona esta anotación, pero aquí está lo que realmente sucede bajo el capó.
Supongamos que necesitas llamar a algo que se implementa de manera diferente en Fabric versus Forge. Tal vez renderizado de pantalla, tal vez manejo de eventos, tal vez paquetes de red. No puedes simplemente llamar a ambos. Quienes lo intentan no saben en tiempo de compilación qué cargador estás usando.
La respuesta de Architectury: la anotación @ExpectPlatform. Marca un método con ella, y le estás diciendo al sistema de compilación, "Este método tendrá diferentes implementaciones dependiendo de la plataforma." Tu código compartido lo llama normalmente. Detrás de escenas, el proceso de compilación intercambia la versión correcta para cada cargador. Los usuarios de Fabric obtienen la implementación de Fabric, los usuarios de Forge obtienen Forge. Limpio.
Es elegante porque tu código común sigue siendo legible mientras manejas las diferencias de plataforma exactamente donde existen, en ningún otro lugar.
Más allá de anotaciones: Eventos, redes, registros
@ExpectPlatform es poderoso, pero Architectury no se detiene allí.
Los sistemas de eventos son enormes. Tanto Fabric como Forge tienen los suyos, pero son arquitectónicamente diferentes. Architectury abstrae ambos para que registres escuchadores de eventos sin ramificación específica de plataforma. ¿Diferencias en el registro de elementos? Cubierto. ¿Redes entre cliente y servidor? El mismo tratamiento. Una cosa que vale la pena señalar: no tienes que usar todo esto. Architectury es opcional incluso en un proyecto construido con su cadena de herramientas. Puedes usar solo la configuración de compilación y manejar las diferencias tú mismo si quieres. Pero si ya estás aquí, ¿por qué no usar los hooks de eventos y utilidades que ya han escrito? Ahorra tiempo.
Lo que necesitas para empezar
Aquí es donde la gente se confunde.
Architectury API por sí solo no es suficiente. Necesitas tres piezas trabajando juntas. Primero está el complemento Architectury, un complemento Gradle que configura la estructura de tu proyecto y le dice al sistema de compilación cómo malabarear con las diferencias de plataforma. Segundo es Architectury Loom, una bifurcación de Fabric Loom que agrega capacidades de compilación multiplataforma, piensa en descompilación, remapeo, gestión del entorno de desarrollo. Tercero es mirar las plantillas oficiales en su GitHub para entender la estructura real de carpetas y la configuración de Gradle.
El ecosistema suena pesado, pero es realmente menos sobrecarga que mantener dos proyectos de mods separados. Desarrollo compartido, código compartido, pruebas compartidas, solo el código específico de la plataforma vive aparte.
Cosas comunes que deslizan a los nuevos modders
No puedes simplemente añadir Architectury a un mod existente de una sola plataforma. Necesitarás reestructurar tu proyecto usando su cadena de herramientas. No es imposible, pero tampoco es trabajo cero.
@ExpectPlatform solo funciona con métodos estáticos. Esa es una restricción real si estás acostumbrado a enfoques basados en instancias. Tiene sentido, los métodos estáticos son más fáciles de intercambiar en tiempo de compilación, pero es bueno saberlo de antemano.
Las pruebas se vuelven más complejas. Necesitas realmente probar ambos cargadores, idealmente en múltiples versiones de Minecraft. Tu configuración de CI necesita manejar esto. Los modders en solitario a menudo omiten las pruebas completas, por lo que algunos mods afirman soporte multiplataforma pero en realidad funcionan notablemente mejor en una plataforma que en la otra.
¿Lo necesitas?
Para un mod experimental rápido, probablemente no. El desarrollo de una sola plataforma es más rápido. Pero una vez que tienes algo real con características que no les importa qué cargador las ejecute, Architectury te ahorra muchísimo tiempo.
Si tu mod está profundamente ligado a características específicas de plataforma, o solo estás apuntando a un cargador, sáltalo. Serás más feliz y rápido. El punto dulce: tienes una idea de mod sólida, quieres llegar a la base de jugadores más amplia posible, y no quieres mantener dos bases de código completamente separadas. Ese es cuando Architectury se gana su lugar en tu compilación.
Enfoques alternativos que vale la pena considerar
Quilt Standard Library es otra opción multiplataforma, aunque se inclina más hacia la compatibilidad con Quilt que el enfoque multi-cargador más amplio de Architectury.
Algunos modders usan anotaciones de procesador o Mixins para manejar diferencias de plataforma sin una abstracción dedicada. Más trabajo, pero mantienes control máximo. Y honestamente, si solo estás apuntando a Forge o solo a Fabric, no necesitas Architectury en absoluto. Usa las APIs nativas de tu plataforma y salta la capa de abstracción por completo. No hay vergüenza en el desarrollo de una sola plataforma si ese es tu objetivo.
La verdadera propuesta de valor
Si tus ambiciones de modding se extienden más allá de un cargador, Architectury es tiempo bien invertido. Lo importante es que el proyecto se mantiene activamente, la comunidad es útil, su Discord está vinculado en GitHub, y la solución realmente funciona a escala.
Construir mods multiplataforma sin él es como gestionar configuraciones DNS separadas manualmente en lugar de usar una herramienta - técnicamente posible, pero ¿por qué? Las herramientas existen para salvarte de la complejidad innecesaria. Un ecosistema de modding de Minecraft prospera en múltiples cargadores. Architectury hace que participar en ese ecosistema sea práctico en lugar de agotador.
Lead writer at minecraft.how. Long-time Minecraft player running a small SMP server, testing every build, mod, and seed before writing about it.
Preguntas Frecuentes
¿Por qué es útil Architectury API para los desarrolladores de mods de Minecraft?
¿Cómo funciona la anotación @ExpectPlatform en Architectury API?
¿Qué se necesita para empezar a usar Architectury API?
Comentarios
Aún no hay comentarios. ¡Sé el primero en compartir tu opinión!


