Minecraft 1.10: Abandon des ID

Vous connaissez probablement les ID (IDentifiant) dans Minecraft, ce sont des numéros auquel sont associé des éléments. Les ID les plus connu étant bien sur les ID de blocs et objets, mais ce ne sont pas les seuls. Quasiment tous les éléments du jeu ont des ID:

• Les blocs (exemple: 57 = bloc de diamant)
• Les objets (exemple: 264 = un diamant)
• Les mobs (exemple: 90 = cochon)
• Les potions (exemple: 33 = Potion de régénération II)
• Les enchantements (exemple: 33 = Silk Touch)
• Les biomes (exemple: 35 = Savane)
• Les achievements (exemple: 17 = DES DIAMANTS!)
• Les effets de potions (exemple: 14 = Invisibilité)
• etc.

Ce système a été créé par Notch dès l'origine du jeu, pour des raisons de performance: il est en effet beaucoup plus simple pour un ordinateur de manipuler des nombres que du texte ou autres objets plus complexe, c'était donc un choix judicieux fait à l'époque.

Pour que ce système de numérotation fonctionne, il est cependant essentiel que chaque numéro soit unique, il n'est pas possible d'avoir 2 éléments avec le même numéro. Avec le temps, cela a commencé à poser certains problèmes:

• Dans certains cas, le nombre d'élément était limité (je vous explique après pourquoi)
• Et surtout, comment garantir l'unicité des IDs dans les mods ? Chaque moddeur choisi les numéros de son choix, qui risque d'entré en conflit avec d'autres mods, voir pire avec les ID utilisés dans Minecraft dans des versions ultérieures. Par exemple dans Minecraft 1.8 l'ID d'objet 443 n'était pas utilisé, mais dans Minecraft 1.9 il correspond aux ailes (Elytra), comment faire si un moddeur a déjà utilisé cet ID dans son mod ?

Heureusement, chaque catégorie d'éléments dans Minecraft possède sa propre numérotation des ID: dans les exemples cités en début d'article vous verrez ainsi que l'ID 33 est attribué à la potion de régénération II si c'est un ID de potion, et à l'enchantement Silk Touch si c'est un enchantement. Ce même numéro 33 désigne également le bloc Piston, le biome Coline de Taïga Géante, ou encore l'achievement Surpuissant, chaque catégorie est indépendante.

Il y a cependant une exception à cette règle: Les blocs et les objets partagent la même numérotation, et ce partage pose aujourd'hui beaucoup de problème, comme vous allez le constater.

Afin de garantir l'unicité des numéros entre blocs et objets, tout en permettant de les différencier facilement, Notch avez choisit de numéroter les blocs entre 0 et 255, et les objets entre 256 et 511. Une seule exception à cette règle: les disques du jukebox ont (pour une raison que j'ignore) des ID compris entre 2256 et 2267.


La limitation des ID
Le nombre de blocs est donc limité à 256, et il est impossible d'augmenter ce nombre puisque les numéros suivant sont utilisé (256 = pelle en fer, etc). Aujourd'hui, dans la dernière snapshot de la future version 1.9, le numéro le plus grand utilisé est le numéro 212 (glace gelée) (en excluant les blocs de structures qui ont déjà l'ID 255). Cela signifie-t-il qu'il ne reste que 44 blocs possible dans Minecraft, et qu'ensuite le jeu sera saturé ?

Au début, on aurait pu le croire, car le problème est encore pire:
Dans la version Indev (début 2010), Notch ajouté le four. Mais ce bloc a 2 affichages possible: allumé, et éteint. Comment faire ? Notch a tout simplement créer 2 ID de blocs, le 61 pour le four éteint, et le 62 pour le four allumé. Ces 2 ID sont toujours utilisé aujourd'hui. Plus tard il refera la même chose avec le minerai de redstone qui a les ID 73 (éteint) et 74 (allumé).

Heureusement Notch lui même avait déjà commencé à chercher une solution.

Le problème se posa avec l'ajout dans Minecraft de la redstone dans la version Alpha 1.0.1 début juillet 2010.
Le cable redstone peut prendre des formes très différente en fonction de son environnement. S'il est seul, il à une forme de point. S'il a des cables de chaque coté, il a une forme de ligne, il peut aussi monter sur le coté nord, sud, est, ouest, ou aller vers chacune de ces directions, ou une combinaison de tous ces cas la. Faire un bloc pour chaque possibilité aurait nécessité un nombre trop important d'ID (256 pour être précis, soit l'intégralité des ID disponible). Comme faire ?
La solution fut d'ajouté un "sous-ID", un numéro de data qui permet d'avoir plusieurs affichages possibles pour un même bloc. C'est grâce à ces numéros de data qu'on a aujourd'hui des escaliers qui peuvent être orienté dans toutes les directions (nord, sud, est, ouest, haut, bas, en angle, etc.).

Aujourd'hui ces numéros de datas sont aussi utilisés pour augmenter virtuellement le nombre de bloc: Certains blocs sont fixe et ne change jamais (par exemple un bloc de pierre n'a pas besoin de data), Mojang réutilise donc ces numéros de data de ces blocs pour créer des variantes de ces blocs, c'est ainsi que début 2014, dans la version Minecraft Release 1.8, ont été ajouté dans Minecraft les blocs de Granite, Granite poli, Diorite, Diorite Polie, Andésite, Andésite Polie, toutes ces roches ont le même ID (le 1), mais avec un numéro de data différent (de 0 à 6).


Les ID sont donc maintenant illimité ?
Malheureusement non, car si cette solution à permis de limiter la consommation des ID, les ID reste une ressource très limité, on a seulement repoussé l'échéance de la pénurie d'ID. D'autre part, cette solution ne résout aucunement l'autre problème de l'utilisation des ID: comment garantir l'unicité de chaque ID lorsqu'on utilise des mods ?

La solution choisit fut d'associer a chaque élément du jeu un nom, ces nouveaux ID (IDentifiant) ne sont plus des numéros, mais du texte. L'avantage est évidement: vous n'avez plus aucune limitation dans le nombre d'élément possible. De plus le risque de collision entre mod est sérieusement réduit.

C'est ainsi que ces dernières années quasiment tous les systèmes dans Minecraft ont reçu de nouveaux ID sous forme de texte. Ces ID textes vous les connaissez probablement, puisque ce sont les noms que vous devez taper dans les commandes, par exemple dans la commande suivante:
/give @p minecraft:stone 1 3
Ici l'ID du bloc est "minecraft:stone". Dans cette commande le numéro de data (le "3") n'a pas été converti sous forme de texte, mais il devrait l'être prochainement, j'en reparle plus tard.
Actuellement ce système d'ID texte fonctionne en parallèle aux ID numériques qui continuent d'être au coeur du fonctionnement du jeu.

Mais comme a chaque fois, il y a des exceptions, certains éléments n'ont pas encore d'ID sous forme de texte:

• Les enchantements: ils sont encore aujourd'hui désigné par des numéros.

Exemple avec cette commande qui est valide dans la version 1.9 de Minecraft:
/give @p minecraft:iron_sword 1 0 {ench:[{id:16,lvl:2}]}
Ici j'enchante mon épée avec l'enchantement numéro 16 (= Sharpness)

• Les potions: Et pour cause, les ID de potions disparaîtront dans Minecraft 1.9, remplacé par des tags NBT.

NBT: La solution ultime ?
NBT, je n'en ai pas encore parler, pourtant eux aussi permettent d'avoir plusieurs versions d'un même objet ou bloc.
NBT signifie litéralement "Tag de Nommage Binaire". Dit plus simplement, cela permet de créer des tags, nommé (avec un nom sous forme de texte), stoqué en mémoire sous forme binaire (donc rapide à lire pour l'ordinateur, mais en tant que joueur on ne voit jamais cette forme binaire, nous ne connaissons que sa représentation au format JSON, plus facile à lire et écrire pour nous humain).

Si NBT permet de créer des personnalisations potentiellement infinies sur un seul objet, il a cependant un inconveniant: sa structure est lourde, et si tous les blocs du jeu avaient des tags NBT pour l'affichage cela ralentirait considérablement l'affichage du jeu, ces tags ne sont donc pas une solution pour augmenter virtuellement les ID, c'est pourquoi ils ne sont jamais utilisé pour créer des variantes d'un bloc.


Les Block state ?
Les block states, je n'en ai pas encore parlé, c'est la version nommée des anciens numéros data. Pour reprendre notre exemple du bloc de pierre, le bloc de pierre a maintenant un block state nommé "variante" qui peut prendre les valeurs:

• stone
• granite
• smooth_granite
• diorite
• smooth_diorite
• andesite
• smooth_andesite

Ici encore le numéro de data a été remplacé par une valeur texte, plus souple d'utilisation. L'avantage de ces blocs states est qu'il est possible d'avoir plusieurs valeur pour un seul et unique bloc, par exemple un bloc de feuille à 3 block states:

• check_decay (valeur technique)
• decayable (le bloc disparaît-il automatiquement si on coupe le tronc de l'arbre ?, vrai pour les bloc naturel, faux si posé manuellement)
• variant (les différents types de feuilles)

Ce système de block states n'est pas encore utilisé pour l'affichage dans le jeu, mais il devrait à terme remplacer le système de data value (les "sous-ID" de bloc).


Minecraft 1.10: La suppression des ID de blocs et d'objets
Nous sommes donc actuellement dans une période de transition, ou Minecraft fonctionne toujours en interne avec des numéros ID (très rapide, mais limité), mais ou chaque bloc a malgré tout un nom qui le désigne de manière unique. Ce nom est utilisé dans les commandes et il est affiché dans le debug. Est-il maintenant possible de supprimer les ID numérique pour n'utiliser que les ID texte ? Une fois de plus, les choses ne sont pas si simple.

Les Performances:
Le premier problème qui se poserai en abandonnant les ID numérique sera un problème de performance. Lire un nombre pour un ordinateur est très rapide, le processeur est capable de le faire en un seul cycle. Lire un texte est beaucoup plus compliqué, il faut lire chaque caractère un par un, plus a chaque manipulation refaire cette lecture. Au final, on risquerai de réduire drastiquement les performances du jeu si on abandonnait les ID numérique, car cette opération de lecture sera a répéter pour chaque bloc du monde à afficher sur votre écran, et cela plusieurs dizaines de fois par seconde!

Le stockage:
Un autre avantage des ID numérique est leur taille: un nombre se stocke très facilement en mémoire, il ne prend que 2 ou 4 octets dans la majorité des cas. Un texte, avec sa structure, va prendre beaucoup plus de place, plusieurs dizaines d'octet, et cela pour chaque bloc qui compose votre monde (des millions). Le changement d'un système numérique a un système texte ferait gonfler d'un coups la taille de votre map. Ce n'est pas forcement très grave dans le cas d'une partie solo, mais pour les serveurs multijoueurs qui ont déjà des maps de plusieurs dizaines de Go, cela serait ingérable.

La compatibilité:
Autre soucis: actuellement seul les ID de blocs sont enregistré dans les fichiers de sauvegarde de votre monde. Si demain le système change, comment Minecraft arrivera-t-il a relire des numéros, alors qu'il ne comprend que du texte ?


Une transition en douceur
La solution est de garder un système mixte, mais différent d'aujourd'hui.
Actuellement chaque bloc, objet, etc. possède un ID qui lui est définit directement dans le code du jeu. A cela s'ajoute un nom, lui aussi fixe. Demain c'est le nom qui sera son ID principal, et l'ID numérique sera secondaire.

Demain, chaque bloc n'aura qu'un nom de définit dans le code du jeu, aucun ID numérique ne lui sera associé. Lors du lancement d'une partie, une table de conversion sera créer pour votre monde, et a chaque bloc sera associé un numéro. Ce numéro ne sera valable que pour votre monde, il pourra changer d'un monde a l'autre, mais dans une même partie il sera toujours fixe. Ainsi, si vous ajouté un mod, le jeu attribura automatiquement aux blocs du mod des ID numérique disponible, et si vous avez plusieurs mods vous serez sur qu'ils n'auront pas 2 fois le même ID d'attribué. Cette solution permet également de garder le stockage et l'utilisation d'ID numérique par le moteur du jeu, ce qui vous garantie les meilleures performances.

C'est cette solution qui devrait être utilisé dans Minecraft 1.10.


ID composés
Il reste un dernier problème auquel je n'ai pas répondu: Si les risque de collision du nom de blocs entre 2 mods est drastiquement réduit, il n'est pas impossible que 2 mods donnent le même nom à leur bloc. Comment empêcher cela ?
La solution choisit par Mojang n'est pas de leur invention, elle existe depuis longtemps, dans un système que vous utilisez tous les jours: Les emails.

Vous êtes vous déjà demandé pourquoi les emails avez toujours un @ au milieu de l'adresse ? Ce @ est précisément la solution a notre problème de garantir l'unicité des noms.
Il est inconcevable que 2 personnes dans le monde puissent avoir la même adresse email, mais comment empêcher cela ? La solution la plus simple est la centralisation: avoir un organisme central qui gère les noms, et qui garanti leur unicité. C'est le cas que vous retrouverez sur google, twitter, ou même sur minecraft: lorsque vous vous inscrivez, vous ne pourrez pas prendre le même pseudo qu'une autre personne, google, twitter ou mojang vérifiera que personne d'autre n'a déjà ce nom. Mais dans le cas d'une adresse email, qui aurez-pu faire ce control ? C'est du travail, et c'est gratuit, donc il n'y a pas d'argent pour le payer... l'email est ce qu'on appelle un système décentralisé, qui a donc utilisé un autre solution: les adresses composées.
Dans le cas des emails, la partie droite (après le @) est un nom de domaine, dont l'unicité est certifié par les organismes qui attribuent ces domaines (et qui sont payé pour ce travail par la location de ces mêmes domaines, puisqu'un nom de domaine n'est pas gratuit). La partie à gauche du @ (votre nom) est vérifié par le gestionnaire de la boite mail, c'est lui qui garantie cette unicité (lui étant payé par vous). Les 2 parties étant unique, vous êtes sur que votre email est unique.

Mojang a réutilisé exactement ce même procédé pour nommer ses blocs: le "minecraft:" qui se trouve devant le nom du bloc correspond au "domaine", il est attribué de manière fixe pour chaque mod. Ensuite vous pouvez donner le nom que vous voulez à votre bloc, grâce à ce préfixe unique vous êtes sur que cela n'entrera jamais en conflit avec un autre mod. Les élément du jeu ont, vous le savez déjà, le préfixe "minecraft:". Par soucis de simplification, les blocs appartenant au jeu Minecraft vanilla (c'est à dire sans mod), peuvent être écrit sans préfixe, le jeu ajoutant automatiquement le préfixe "minecraft:" dans ce cas là.



Voila, vous savez maintenant tout sur les ID, sur leur fonctionnement, et sur les changements qu'apportera la version 1.10. Vous devriez aussi mieux comprendre maintenant pourquoi ce changement de Minecraft 1.10 sera un cap majeur vers l'API de plugin (plus de collision d'ID) et pour l'avenir de Minecraft (nombre de bloc illimité) :-)