Skip to content
Pular para o conteúdo
Voltar ao Blog
Architectury API - Crie Mods para Qualquer Plataforma

Architectury API - Crie Mods para Qualquer Plataforma

Alexandru Maftei
Alexandru Maftei
@ice
Atualizado
48 visualizações
TL;DR:Architectury API permite que desenvolvedores de mods escrevam código uma vez e o distribuam entre Fabric, Forge e outros carregadores de Minecraft. Saiba como esta biblioteca Java abstrai as diferenças de plataforma e simplifica o desenvolvimento de mods multiplataforma.
🐙 Projeto de código aberto do Minecraft

architectury/architectury-api

Uma API intermediária voltada para facilitar o desenvolvimento de mods multiplataforma.

⭐ 420 stars💻 Java📄 LGPL-3.0
Ver no GitHub ↗

Cansado de escrever mods separados para Fabric e Forge? Architectury API permite que você escreva seu código uma vez e o distribua em vários carregadores sem duplicar metade do seu projeto. É o framework que transforma a criação de mods multiplataforma de uma tarefa frustrante em algo praticamente viável.

O Que Esta API Faz

Architectury API não é apenas outra biblioteca. É uma camada de tradução entre duas formas fundamentalmente diferentes de criar mods para Minecraft.

Imagine o seguinte: você construiu um mod brilhante para Forge. Depois alguém pergunta se funciona no Fabric. Acontece que não, porque Forge e Fabric implementam sistemas principais de forma completamente diferente, e você entrelaçou código específico do carregador em todo o seu projeto. Agora você enfrenta meses de reescrita para fazer o mesmo mod funcionar em outra plataforma.

Esse é o problema exato que Architectury resolve. Mas fornece uma interface unificada para que seu mod possa chamar qualquer carregador em que esteja funcionando sem se preocupar com as diferenças subjacentes. Forge tem código diferente do Fabric? Architectury cuida disso para você. O projeto fornece mais de 90 ganchos de eventos e abstrações para registros, rede e detecção de carregador. Você não está reimplementando toda a paisagem da API, mas sim obtendo uma camada de tradução sensata que fala ambas as linguagens com fluência.


Por Que Desenvolvedores de Mods Desejam Isso

Aqui está a verdade brutal da modagem multiplataforma à moda antiga: você construiria seu mod, testaria, corrigiria bugs, adicionaria recursos... e depois faria tudo de novo para o outro carregador. Cada correção de bug precisava estar em dois lugares. Cada novo recurso significava trabalho duplo. A maioria dos modders simplesmente escolhia uma plataforma e chamava de encerrado.

Com Architectury, você mantém código compartilhado em um módulo comum e guarda código específico de plataforma em pastas separadas. A maioria da sua lógica existe uma vez e funciona em todos os lugares. Isso é genuinamente poderoso ao manter um mod ao longo de meses ou anos. Mas também significa que você não está escolhendo entre comunidades. Alguns jogadores preferem carregadores Fabric (especialmente Quilt), outros ficam com Forge. Confira a lista de servidores em minecraft.how e você verá comunidades multiplayer usando pacotes de mods completamente diferentes, cada uma com suas próprias preferências de carregador. Ao suportar várias plataformas, você está alcançando ambos os públicos em vez de deixar um abandonado.


A Anotação @ExpectPlatform: Como Funciona

O README menciona esta anotação, mas aqui está o que realmente acontece nos bastidores.

Suponha que você precise chamar algo que é implementado de forma diferente no Fabric versus Forge. Talvez renderização de tela, talvez tratamento de eventos, talvez pacotes de rede. Você não pode apenas chamar ambos. Pessoas que tentam isso não sabem em tempo de compilação qual carregador você está executando.

A resposta do Architectury: a anotação @ExpectPlatform. Marque um método com ela, e você está dizendo ao sistema de compilação, "Este método terá implementações diferentes dependendo da plataforma." Seu código compartilhado o chama normalmente. Nos bastidores, o processo de compilação substitui a versão correta para cada carregador. Usuários de Fabric obtêm a implementação Fabric, usuários de Forge obtêm Forge. Limpo.

É elegante porque seu código comum permanece legível enquanto você lida com diferenças de plataforma exatamente onde elas existem, em nenhum outro lugar.


Além de Anotações: Eventos, Rede, Registros

@ExpectPlatform é poderoso, mas Architectury não para por aí.

Sistemas de eventos são enormes. Fabric e Forge têm ambos, mas são arquitetonicamente diferentes. Architectury abstrai ambos para que você registre ouvintes de eventos sem ramificação específica de plataforma. Diferenças de registro de item? Coberto. Rede entre cliente e servidor? Mesmo tratamento. Uma coisa digna de nota: você não precisa usar tudo isso. Architectury é opcional mesmo em um projeto construído com sua cadeia de ferramentas. Você pode usar apenas a configuração de construção e lidar com diferenças você mesmo se quiser. Mas se você já está aqui, por que não usar os ganchos de evento e utilitários que eles já escreveram? Economiza tempo.


O Que Você Precisa para Começar

É aqui que as pessoas ficam confusas.

Architectury API por si só não é suficiente. Você precisa de três peças funcionando juntas. Primeiro é o Plugin Architectury, um plugin Gradle que configura sua estrutura de projeto e diz ao sistema de compilação como equilibrar diferenças de plataforma. Segundo é Architectury Loom, uma bifurcação de Fabric Loom que adiciona capacidades de compilação multiplataforma (pense em decompilação, remapeamento, gerenciamento de ambiente de desenvolvimento). Terceiro é consultar os modelos oficiais no GitHub deles para entender a estrutura de pasta atual e a configuração do Gradle.

O ecossistema parece pesado, mas na verdade é menos sobrecarga do que manter dois projetos de mods separados. Desenvolvimento compartilhado, código compartilhado, testes compartilhados, apenas código específico de plataforma vive separado.


Coisas Comuns Que Confundem Novos Modders

Você não pode simplesmente adicionar Architectury a um mod de plataforma única existente. A maioria dos projetos precisa ser reestruturada usando sua cadeia de ferramentas. Não é impossível, mas também não é trabalho zero.

@ExpectPlatform funciona apenas em métodos estáticos. Essa é uma restrição real se você está acostumado com abordagens baseadas em instâncias. Faz sentido (métodos estáticos são mais fáceis de trocar em tempo de compilação), mas é bom saber de antemão.

Os testes se tornam mais complexos. Você precisa realmente testar ambos os carregadores, idealmente em múltiplas versões do Minecraft. Sua configuração de CI precisa lidar com isso. Modders solo geralmente ignoram testes completos, razão pela qual alguns mods afirmam suportar multiplataforma, mas na verdade funcionam notavelmente melhor em uma plataforma do que na outra.


Você Precisa Disso?

Para um mod experimental rápido, provavelmente não. O desenvolvimento de plataforma única é mais rápido. Mas quando você tem algo real com recursos que não se importam com qual carregador está por baixo, Architectury economiza um tempo enorme.

Se seu mod está profundamente vinculado a recursos específicos de plataforma, ou você está direcionando apenas um carregador, pule isso. Você será mais feliz e mais rápido. O ponto ideal: você tem uma ideia de mod sólida, quer alcançar o público de jogadores mais amplo possível, e não quer manter dois códigos totalmente separados. É quando Architectury ganha seu lugar em sua compilação.


Abordagens Alternativas Vale a Pena Considerar

Quilt Standard Library é outra opção multiplataforma, embora favoreça mais a compatibilidade com Quilt do que o foco mais amplo de múltiplos carregadores do Architectury.

Alguns modders usam anotações de processador ou Mixins para lidar com diferenças de plataforma sem uma abstração dedicada. Mais trabalho, mas você mantém controle máximo. E honestamente, se você está apenas direcionando Forge ou apenas Fabric, você não precisa de Architectury. Use as APIs nativas da sua plataforma e pule a camada de abstração inteiramente. Não há vergonha em desenvolvimento de plataforma única se esse for seu objetivo.


A Verdadeira Proposta de Valor

Se suas ambições de modding se estendem além de um carregador, Architectury é tempo bem gasto. A questão é que o projeto é ativamente mantido, a comunidade é prestativa (seu Discord está vinculado no GitHub), e a solução realmente funciona em escala.

Construir mods multiplataforma sem ele é como gerenciar configurações de DNS separadas manualmente em vez de usar uma ferramenta - tecnicamente possível, mas por quê? O ferramental existe para salvá-lo da complexidade desnecessária. Um ecossistema de modding do Minecraft está florescendo em múltiplos carregadores. Architectury torna a participação nesse ecossistema prática em vez de exaustiva.

Sobre o autor
Alexandru Maftei
Alexandru MafteiRedator-chefe

Lead writer at minecraft.how. Long-time Minecraft player running a small SMP server, testing every build, mod, and seed before writing about it.

Comentários

Nenhum comentário ainda. Seja o primeiro a compartilhar sua opinião!

We use cookies to improve your experience. By continuing to use this site, you agree to our use of cookies. Read our Privacy Policy