Configurer les évolutions d'un Pokémon

Pokémon Studio permet de donner autant d'évolutions que voulu à un Pokémon, chacune protégée par son propre jeu de conditions. Ce guide parcourt l'éditeur d'évolutions, liste toutes les conditions disponibles, et explique les deux règles qui déterminent quelle évolution se déclenche réellement : les conditions se combinent en ET au sein d'une évolution, et le moteur retient la première évolution de la liste dont toutes les conditions passent.

Ouvrir l'éditeur d'évolutions

Les évolutions ne forment pas un onglet à part. On ouvre Base de données > Pokémon, on sélectionne son Pokémon, et on repère le bloc Évolution sur sa fiche. Un clic dessus ouvre l'éditeur d'évolutions.

Deux caractéristiques de cet éditeur méritent d'être connues avant d'y toucher.

Il édite une forme à la fois. La forme affichée sur la fiche du Pokémon est celle dont on édite les évolutions : un Pokémon à plusieurs formes possède donc une liste d'évolutions par forme.

Il affiche une évolution par page. Dès qu'un Pokémon en possède plusieurs, des flèches apparaissent en haut de l'éditeur pour naviguer entre elles, numérotées #1 - <nom de la cible>, #2 - ... et ainsi de suite. Ce numéro est la position dans la liste, et comme la suite de ce guide le montre, il n'a rien de cosmétique.

Choisir la cible

Évolue en désigne le Pokémon produit par cette évolution. Le champ est obligatoire : tant qu'il est vide, le bouton Nouvelle évolution reste désactivé et on ne peut pas ajouter de seconde évolution.

Forme n'apparaît que si le Pokémon ciblé possède plusieurs formes. On n'y touche que pour faire évoluer vers une forme alternative précise.

Pour ajouter une autre évolution au même Pokémon, on utilise Nouvelle évolution dans le panneau Évolution supplémentaire. Supprimer cette évolution retire celle actuellement affichée.

Ajouter des conditions

Ajouter une condition ajoute une carte de condition à l'évolution courante. Chaque carte porte une seule condition : un type choisi dans la liste déroulante Condition d'évolution, plus la valeur attendue par ce type.

Une évolution sans aucune condition est valide. Studio l'appelle Aucune condition, et le Pokémon évolue alors à n'importe quelle montée de niveau.

Voici toutes les conditions proposées par l'éditeur, dans l'ordre de la liste déroulante.

Condition	Ce qui est vérifié	Valeur à renseigner
Par montée de niveau	Le Pokémon a au moins ce niveau	Niveau, de 1 à 999
Avant un certain niveau	Le Pokémon a au plus ce niveau	Niveau, de 1 à 999
Avec une pierre évolutive	La pierre utilisée sur le Pokémon	Objet
Par échange de dresseur	Le Pokémon est échangé, avec n'importe qui	Aucune valeur
En échange d'un Pokémon	Le Pokémon est échangé contre cette espèce précise	Pokémon
En portant un objet	L'objet tenu par le Pokémon	Objet
Avant un bonheur maximum	Le bonheur vaut au plus cette valeur	Bonheur, de 1 à 255
Avec un bonheur minimum	Le bonheur vaut au moins cette valeur	Bonheur, de 1 à 255
En possédant la capacité	Le Pokémon connaît cette capacité	Attaque
En fonction de la météo	La météo en cours	Météo
En fonction de l'environnement	Le Système Tag sur lequel se tient le joueur	Système Tag, un nombre à partir de 0
À un moment de la journée	Le moment de la journée en cours	Moment : Jour, Couché de soleil, Nuit ou Matin
Si le joueur est sur une carte	Le joueur se trouve sur l'une de ces cartes	Cartes, des ID séparés par des virgules
En fonction du genre	Le genre du Pokémon	Genre : Mâle, Femelle ou Inconnu
Selon une fonction	Une condition codée en Ruby, appelée par son nom	Fonction, le nom de la méthode
Par Méga-Évolution	Réservé à la Méga-Évolution, voir plus bas	Objet

En possédant la capacité existe en quatre exemplaires dans les données, sous forme de quatre emplacements distincts : c'est ce qui permet à une même évolution d'exiger jusqu'à quatre capacités différentes. La liste déroulante ne propose que le prochain emplacement libre, on n'a donc jamais à se soucier de la numérotation.

Selon une fonction est la porte de sortie pour tout ce que cette liste ne sait pas exprimer. La valeur est le nom d'une méthode Ruby écrite du côté de PSDK, et Studio ne vérifie pas son existence : une faute de frappe ici plante le jeu avec un NoMethodError dès que le moteur teste l'évolution, on vérifie donc l'orthographe contre son script. Écrire cette méthode est un sujet à part entière, non traité ici.

Comment les conditions se combinent

C'est ici que les évolutions dérapent le plus souvent, parce que deux règles différentes s'appliquent à deux niveaux différents.

Au sein d'une évolution, les conditions se combinent en ET. Chaque carte de condition de la page doit passer. Une évolution exigeant un bonheur minimum de 160 et le moment Nuit ne se déclenche que si les deux sont vraies.

Entre les évolutions, c'est un OU. Un Pokémon possédant trois évolutions peut emprunter n'importe laquelle des trois.

Ce qui surprend, c'est la façon dont ce OU se résout. Le moteur parcourt la liste de haut en bas et s'arrête à la première évolution dont toutes les conditions passent. Il ne regarde jamais les suivantes. L'ordre de la liste fait donc partie de la logique, ce n'est pas de la présentation.

La conséquence mérite d'être énoncée clairement : on place l'évolution la plus exigeante en premier. Si une évolution large se trouve au-dessus d'une plus étroite, la large gagne toujours et l'étroite devient inatteignable, quoi que fasse le joueur.

Imaginons un Pokémon qui doit évoluer en A au niveau 20, et en B au niveau 20 en tenant un objet. Dans cet ordre, B ne se produira jamais : le joueur a beau faire tenir l'objet, l'unique condition de A passe déjà, et A est testée en premier. En les inversant, les deux fonctionnent.

L'Évoli par défaut illustre bien la règle. Nymphali exige un bonheur minimum de 160 plus une fonction, Noctali exige un bonheur minimum de 160 plus le moment Nuit, et Nymphali est listé au-dessus de Noctali. Un Évoli bien aimé qui satisfait la fonction de Nymphali devient donc Nymphali, même de nuit. Cet ordre est délibéré, pas accidentel.

remarque

Évoli embarque aussi Phyllali et Givrali avec une condition cartes valant -1, qui n'est l'ID d'aucune carte réelle. Ce sont des marque-places : le projet par défaut les laisse volontairement inatteignables, en attendant qu'on y renseigne les cartes de ses propres rochers moussus et glacés.

Les règles imposées par l'éditeur

Quelques contraintes sont câblées dans l'éditeur, plus faciles à comprendre qu'à découvrir.

Un type de condition par évolution. Dès qu'un type est utilisé, il disparaît de la liste déroulante de toutes les autres cartes de la même évolution. On ne peut donc pas exiger deux objets tenus dans une seule évolution : « tient l'objet A ou l'objet B » demande deux évolutions distinctes. Les niveaux sont l'exception qui confirme la règle : Par montée de niveau et Avant un certain niveau sont deux types distincts, encadrer un niveau entre 20 et 30 dans une seule évolution fonctionne donc.

La Méga-Évolution est un cas à part. Ajouter Par Méga-Évolution bascule l'éditeur en mode Méga : Évolue en cesse d'être une liste déroulante et devient un Mega-<nom> grisé. On ne choisit plus la cible, Studio la déduit.

C'est que cette condition n'en est pas vraiment une. La Méga-Évolution est gérée ailleurs, par le moteur de combat, et une évolution portant cette condition ne se déclenche jamais comme une évolution normale. Il faut la voir comme un marqueur déclarant que ce Pokémon possède une forme Méga, pas comme une règle évaluée par le moteur.

Les valeurs sont validées à l'enregistrement. Laisser un champ obligatoire vide ou hors bornes bloque la sauvegarde et place le curseur sur le champ fautif. Cela vaut aussi au moment de passer d'une évolution à une autre : une condition à moitié remplie retient sur la page courante jusqu'à ce qu'on la complète ou qu'on la supprime.

Conclusion

• Les évolutions vivent dans le bloc Évolution de la fiche d'un Pokémon, une liste par forme, une évolution par page d'éditeur.
• Au sein d'une évolution, les conditions se combinent en ET ; entre les évolutions, c'est un OU.
• Le moteur retient la première évolution de la liste dont toutes les conditions passent : on place l'évolution la plus exigeante en premier, sans quoi elle devient inatteignable.
• Un type de condition ne sert qu'une fois par évolution ; exprimer un « ou » entre deux valeurs d'un même type demande deux évolutions.
• Par Méga-Évolution est un marqueur de Méga-Évolution, pas une condition évaluée par le moteur : elle fige la cible et ne déclenche jamais d'évolution normale.
• Selon une fonction est l'issue quand aucune condition native ne convient ; la valeur est le nom d'une méthode Ruby qu'on écrit soi-même.