Meilleures Pratiques

Il y a plusieurs manières de créer un plugin et plusieurs pièges pour un développeur imprudent. Nous décrivons ici les pratiques pour développer un plugin qui feront les plus de SpongeAPI, en fixant des limites raisonnables au profit de la compatibilité. Ces informations pourront changer et être étendues au fur et à mesure que le projet Sponge gagnera en maturité.

Les recommandations pour le développement de plugin

Les recommandations suivantes ont été préparées pour aider les développeurs de plugins Sponge. Ce n’est pas une liste définitive et exhaustive, plutôt une tentative pour détailler les problèmes qui sont susceptibles de se poser durant le développement d’un plugin, et de proposer nos meilleures solutions.

Note

Nous réservons l’utilisation de Sponge pour les travaux officiels de SpongePowered. Merci de ne pas utiliser Sponge à l’intérieur du nom de votre plugin, sauf (1) si votre plugin concerne principalement le bloc de Minecraft « Éponge », ou (2) si votre plugin possède également des versions pour d’autres APIs (auquel cas vous pouvez ajouter « for Sponge » au titre).

API d’économie

La Economy API est utilisée comme point commun à tous les plugins d’économie ainsi qu’aux plugins utilisant ces économies (comme les shops). Vous pouvez en savoir plus sur la Economy API ici, qui détaille tout ce que vous devrez savoir sur cette API.

Packets

Tout ce qui concerne l’interception de packets, ou l’introduction d’objets/blocs/entités/etc.. personnalisés ne sont pas prévus de faire partie de SpongeAPI. Notez que l’utilisation de packets peut être la mauvaise réponse à un problème et qu’il peut y avoir une solution réalisable avec SpongeAPI. Dans certains cas, il peut être possible d’ajouter tout ce qui est nécessaire avec SpongeAPI; autrement, l’alternative est d’utiliser l’API Forge et de créer un Mod à la place.

Utiliser Forge ou les Classes NMS

Nous recommandons de ne pas de travailler du tout avec les classes de base de Forge et de Minecraft, à moins que ce soit pour fournir une compatibilité avec un mod à SpongeAPI. La plupart des utilisations de code NMS (net.minecraft.server) dans les plugins ne finissent pas proprement, rendant les diagnostics difficiles. Maintenir à jour les modifications NMS est également plus difficile que d’utiliser SpongeAPI. Les Mods qui ajoutent à SpongeAPI l’utilisation de code interne devront spécifiquement écrire une API, qui ne repose pas sur le code sous-jacent de Minecraft, pour être utilisable par les plugins Sponge. Cependant, des plugins peuvent être créés pour charger des modules de « compatibilité » pour interagir avec l’implémentation sous-jacente (SpongeForge ou SpongeVanilla).

Les plugins utilisant du code spécifique à une implémentation sont très susceptibles de se casser entre deux versions, et devraient être clairement étiquetés comme tels partout où ils sont hébergés. Ceux-ci devraient plus convenablement être étiquetés comme « Mods ».

Mixins

Les Mixins sont spécialement utilisés pour transformer les classes avant que d’autres mods/plugins démarrent. ForgeModLoader appelle ces mods « Coremods ». SpongeForge est un Coremod et déploie des mixins au démarrage. Les Mixins peuvent être utilisés par les plugins, mais soyez conscient des complexités additionnelles impliquées.

Mods Hybrides

Les plugins Sponge qui exploitent les mixins peuvent également être considérés comme des mods core, selon leur contenu.

Pour utiliser les mixins dans FML, il doit être un coremod. Le jar doit également contenir un plugin Sponge, donc à proprement parler, le conteneur est un « mod hybride ».
Pour utiliser les mixins dans SpongeVanilla, les intentions doivent être déclarées dans le manifest. SpongeVanilla injecte alors les mixins.
Avoir les deux types dans un seul jar est entièrement possible. (En effet, un seul jar peut facilement contenir un tweaker, mod FML, coremod, plugin Bukkit, plugin Sponge, et/ou litemod.)

Certaines définitions peuvent être utiles ici.

Tweak Mod (alias Tweaker): un mod au niveau du sous-système se raccorde directement au jeu en utilisant LaunchWrapper, habituellement utilisé pour des ModSystems (ex : LiteLoader, FML) et les mods autonomes (ex : Optifine). Peut interagir directement avec n’importe quel aspect de l’environnement du jeu. Ne fonctionne généralement plus à chaque version.
Core Mod: dispose presque de l’équivalent du pouvoir d’un Tweak Mod mais doit être amorcé par un ModSystem. Peut interagir avec n’importe quel aspect de l’environnement du jeu directement. Ne fonctionne généralement plus à chaque nouvelle version du jeu.
Mod: interagit avec le jeu seulement via un ModSystem, le mod est exposé aux objets du jeu directement mais va généralement seulement s’attacher au jeu via les hooks fournits par le ModSystem. Se casse généralement à chaque version majeure du jeu (selon les fonctionnalités utilisées). Le terme mod est également utilisé comme un terme générique pour tout ce qui modifie le jeu, mais par souci de clarté, nous allons utiliser cette définition.
Plugin: interagit avec le jeu uniquement via une API, n’interagit pas directement avec les objets du jeu en quelconque façon, s’appuie seulement sur les objets exposés par l’API. Ne fonctionne généralement plus seulement lorsque l’API est révisée (et même pas, parfois).

Il est également important de distinguer le conteneur du contenu. Les problèmes avec la terminologie tendent à survenir parce qu’un jar contenant un mod tend à se référer en tant que « mod ». N’importe quel plugin qui n’est pas entièrement découplé via l’API se met dans la catégorie des Mods. Ce type de « plugin » peut être répandu lorsqu’il existe des lacunes dans une API.

Avantages des Mods Hybrides

Un mod hybride s’appuie sur un composant de plugin qui interagit via l’API, et un mod (ou même coremeod) dans un même package. Il présente les inconvénients d’un mod (ne fonctionne plus à chaque version) mais également la puissance d’un mod (peut interagir directemenet avec le jeu) couplé avec certains des avantages d’un Plugin (accès haut-niveau au jeu, et peut également interagir avec d’autrers plugins en tant que pair).

Le principal avantage de ce système est que la charge de la maintenance est réduite lors de la mise à jour du mod, car toutes les fonctionnalités accédées via l’API sont susceptibles d’être beaucoup plus stables.

Ce type de mod peut être utilisé pour implémenter des plugins qui ont besoin de déborder les capacités de l’API (dans le cas d’un plugin qui a besoin d’exploiter les mixins pour une fonctionnalité particulière); mais il peut également être utilisé pour les mods qui veulent tirer parti des services offerts par l’API (ex : un mod qui veut fournir un support direct pour les permissions ou les canaux de chat).

Contrairrement aux « plugins » qui exploitent les NMS, un mod hybride clarifie sa nature.

Interopérabilité des Plugins

Une explication de comment communiquer avec les autres plugins, à être annoncé.