[Tutoriel] Des Shops compacts et intuitifs

Que ce soit dans une map PVP, une map RPG, ou même une map Aventure en général, les Shops (ou boutiques, si vous préférez) sont des éléments incontournables dans le gameplay d’une map. Ce sont eux qui dictent la cadence d’un jeu, l’équilibrent et renforcent son immersion s’ils sont bien réalisés. Aujourd’hui, nous allons apprendre à créer des Shops simplement et de différentes manières. Un tutoriel signé Calambiel, modérateur forum, également à l’origine du tutoriel expliquant comment cacher des items de façon originale.

Bien le bonjour.

Cela faisait un moment que je ne vous ai pas fait un petit tutoriel, et suite à une demande d’aide concernant les shops, j’ai décidé de vous en présenter plusieurs types avec chacun leurs avantages et leurs inconvénients.

Comme d’habitude l’objectif est d’arriver à un modèle le plus intuitif possible et en utilisant un minimum de redstone ou de blocs de commande à l’état final. Pour les initiés aux commandes, le dernier modèle vous intéressera peut-être. Pour tous les autres, bonne lecture !

Voici les différents modèles qui seront présentés :

• Shops utilisant le scoreboard
• Les villageois et la 1.8
• Shops hybrides utilisant le /stats

Shops utilisant le scoreboard :

Le scoreboard reste le moyen le plus simple de symboliser une monnaie échangeable contre des bonus. Il est d’ailleurs possible de le relier directement à une stat du joueur, comme le nombre de monstres/joueurs qu’il a tué, le nombre de blocs qu’il a miné, etc.

Les principaux avantages de ce modèle sont la simplicité de construction et la flexibilité de fonctionnement. Cependant il n’est pas le système de shops le plus intuitif pour les joueurs et oblige l’affichage du scoreboard, soit en « list » que les joueurs doivent vérifier régulièrement, soit en « sidebar » qui gêne une partie de l’écran.

Il en existe de nombreuses adaptations, mais pour limiter la taille des systèmes nous allons tout simplement passer par un panneau cliquable qui contiendra toutes les commandes nécessaires. Je vous donne ci-dessous une commande où vous n’aurez qu’à remplacer les textes et chiffres par ce qui s’adapte à votre situation.

Commande pour se give le panneau :

Pour plus d’informations sur le JSON utilisé ici pour réaliser les clickEvent allez lire le tutoriel de Mlakuss sur le sujet.

Les shops avec des pancartes sont extrêmement compacts et simples pour un joueur. Cependant ils présentent deux défauts : la limitation à un seul échange par pancarte et la limitation de taille des commandes (ne pouvant dépasser la taille d’un message de joueur en chat). Si votre commande de /give est trop longue (à cause de la présence d’un NBT tag ou autre) vous devrez passer par un /setblock activant un système ou un /scoreboard pour identifier les joueurs réalisant une transaction. Le modèle suivant ne subit cependant pas ces problèmes.

Les villageois et la 1.8 :

Les villageois sont un autre moyen extrêmement utile de réaliser des shops. Ils présentent de nombreux avantages, comme la possibilité de regrouper plusieurs échanges en un seul marchand tout en pouvant vendre des items complexes sans système extérieur. Depuis la 1.8 le fonctionnement des villageois a été sensiblement modifié, c’est pourquoi je me propose de vous l’expliquer avant de passer à la création des shops.

Les différents NBT tags des villageois :

• Profession : définit la texture utilisée par le villageois et son nom dans l’interface s’il ne possède pas de CustomName
• Riches : nombre d’émeraudes échangées avec le villageois, ne sert à rien dans le jeu en survie mais peut toujours être utile si on veut tester des tags
• Career : complémentaire de « Profession » pour définir les échanges proposés par les villageois
• CareerLevel : le « niveau d’échange » du villageois, nous y reviendrons par la suite
• Willing : tag servant à la reproduction dont nous ne nous servirons pas
• Inventory : l’inventaire du villageois, utilisé principalement par les fermiers qui peuvent récolter et replanter de la nourriture
• Offers : les échanges proposés par le villageois

Pour faire très simple, à chaque fois que vous réalisez un échange avec un villageois, son tag CareerLevel va se modifier et s’il est inférieur à la valeur se trouvant dans le tag « Career » alors un nouvel échange sera créé. Plus encore, si le tag atteint 0 il va alors retrouver une valeur de 1 et la « Career » du villageois changera également.

Pour résumer : auparavant un villageois générait une nouvelle offre à chaque fois que l’on utilisait la dernière offre qu’il propose. Désormais il faut réaliser un certain nombre d’échanges jusqu’à ce que le CareerLevel soit inférieur au Career. Pour bloquer l’apparition de nouveaux échanges il vous suffit donc de donner une grande valeur à « CareerLevel » (pas trop grande non plus si vous ne souhaitez pas rencontrer un crash de type « OutOfBounds »).

Passons maintenant à la structure des offres des villageois. Elles sont toutes répertoriées dans le tag « Offers » et possèdent plusieurs composantes :

• buy : le premier item à donner au villageois
• buyB : le second item à donner au villageois
• sell : l’objet vendu par le villageois
• maxUses : le nombre d’utilisations possibles de l’échange
• uses : nombre de fois que l’échange a été réalisé
• rewardExp : activer ou non le don d’xp lorsque l’échange est réalisé (il s’agit d’un true/false et non pas de la quantité d’xp donnée)

Pour ceux qui connaissent la structure des NBT tags, chaque échange est isolé dans des accolades, tous les trades étant regroupés entre crochets et séparés par une virgule. Tous les items demandés ou givés, leurs tags ou leur quantité, sont déclarés comme dans le modèle trouvable ici.

Exemple :
Ici on a deux échanges étant respectivement de la terre contre de l’herbe et deux de charbon + un minerai de fer contre deux lingots de fer

Important : il ne faut pas oublier de préciser le nombre d’item via le tag « Count » et ce même si vous souhaitez le mettre à 1, car il est par défaut à 0. Il est aussi à noter que, pour une raison obscure, Mojang a décidé de placer entre le tag « Offers » et la liste des offres le tag « Recipes » qu’il faut donc bien écrire à chaque fois, bien qu’en soi il ne sert à rien à par rajouter une accolade et un mot avant le crochet.
Si on reprend tout depuis le début et qu’on rajoute tous les tags qui nous intéresse, voici la commande pour summon un villageois invincible avec les deux trades précédents et qui ne donnera pas d’autres échanges.

Invoquer un villageois avec un échange : (il suffit de séparer tous les échanges par une virgule)

Il existe beaucoup de générateurs de villageois en ligne qui peuvent vous aider si vous ne comprenez rien à la syntaxe des NBT tag. Celui-ci est notamment très bien fait, avec une syntaxe très propre ce qui facilite sa compréhension ou modification.

Les villageois ont le grand avantage de fonctionner avec des items et non des scoreboard, ce qui est bien plus représentatif pour un joueur. Cependant ils demandent plus de temps pour réaliser un échange et sont des entités, donc plus difficiles à contrôler. Le dernier modèle que nous allons voir aujourd’hui a pour but de regrouper les avantages des deux modèles précédents.

Shops hybrides utilisant le /stats :

Je vous entends déjà paniquer rien qu’à l’idée d’utiliser cette commande qu’est le /stats mais ne partez pas tout de suite, vous verrez que nous ne pousserons pas son utilisation très loin aujourd’hui. Je ne ferai ici qu’une explication sommaire et concise du /stats pour vous simplifier sa compréhension mais si vous souhaitez en savoir plus allez voir le récent topic de Mlakuss.

De manière très résumée le /stats va vous permettre de transposer la valeur d’un tag dans un scoreboard. Je vous arrête de suite, on ne parle pas ici de l’ensemble des tags mais uniquement de ceux étant générés comme résultats d’une commande regroupés dans le tag « CommandStats » à savoir :

• SuccessCount : prenant une valeur de 1 si la commande a réussi et une valeur de 0 si elle échoue
• AffectedBlocks : le nombre de blocs affectés par une commande type /fill
• AffectedEntities : le nombre d’entités affectées par une commande avec sélecteur
• AffectedItems : le nombre d’items affectés par une commande type /clear
• QueryResult : la valeur ressortie par une commande type /time query daytime ou /worldborder get

Nous nous servirons ici uniquement du tag AffectedItems. Pour relier la valeur du tag et le scoreboard, il faut utiliser une commandes /stats de syntaxe :

Pour récolter un tag d’un bloc :

Pour une entité :

Pour « délier » le score et le tag il vous suffit de remplacer le « set » par « clear ».

L’énorme avantage du /stats est qu’il n’est désormais nécéssaire d’aucune commande pour transposer la valeur du tag dans le scoreboard. A chaque fois que la valeur changera elle sera automatiquement mise à jour dans le scoreboard.

Mais vous vous demandez probablement pourquoi je vous parle de tout cela. Ce que j’appelais un magasin hybride sera en fait un magasin utilisant le scoreboard, mais où les valeurs des objectifs vont être définies par un nombre d’items dans l’inventaire des joueurs, ce qui le rend beaucoup plus intuitif et évite l’affichage du scoreboard tout en restant plus rapide qu’un échange de villageois.

En effet, pour calculer le nombre d’items dans l’inventaire des joueurs, il nous suffira de réaliser une commande /clear retirant…. 0 item où l’AffectedItems ne mesurera pas le nombre d’items retirés mais le nombre d’items portant l’id correspondant.

Avant de pouvoir mesurer le nombre d’items par joueur, il va cependant falloir quelques commandes d’initialisation. Tout d’abord, avant de pouvoir être mis à jour, l’objectif doit posséder une valeur quelconque. Ensuite, pour que chaque joueur ait un score propre, peu importe le nombre de joueurs et sans passer par des blocs de commande propres à chaque joueur, il va nous falloir utiliser un execute.

Voici donc les deux commandes d’initialisation :

Il ne vous reste plus qu’à exécuter un clear en execute pour mettre à jour le scoreboard (j’ai choisi ici d’utiliser les gold nuggets comme monnaie) :

Pour un item simple remplacez la damage value par 0.

La question qui se pose alors est : quelle clock utiliser pour mettre à jour cette valeur assez rapidement ? La réponse est extrêmement simple : aucune, nous allons intégrer la mise à jour directement dans notre shop.

Nous ferons ici aussi un shop via un panneau cliquable, qui reste le plus compact. Nous allons garder le même shop que le premier modèle présenté dans ce tutoriel en changeant les commandes.

Commande pour se giver le panneau cliquable :

Tout comme le premier modèle si votre give est complexe vous devrez passer par un setblock ou un scoreboard.

Attention :
Le /stats étant complétement buggué en 1.8.4, ce type de shop ne marchera pas dans cette version (qui est à éviter de base).

Voilà j’espère que ce tutoriel vous aura plus. Bonne journée et bon Map making !

Image de Une réalisée par GreenLenux.