Crusader Kings 3 : Evénements


Voici la traduction du 30ème carnet de développement de CK3, le prochain jeu de Paradox Development Studio, consacré aux événements.


Anatomie d'un Evénement
Le cœur d'un événement de personnage standard vous est presque certainement déjà familier : nous avons un titre, une description, généralement un portrait, et une ou plusieurs options en bas.

En ce qui concerne le script, nous avons cependant modifié quelques éléments, en cherchant à améliorer la fonctionnalité, la lisibilité et l'hygiène générale du script au fil du temps. Voici une comparaison du début d'un événement dans CK2 contre CK3 :



Le premier changement que vous remarquerez est que nous avons échangé le type d'événement et l'ID de l'événement : un événement est maintenant créé par un espace de noms (toujours défini en haut de chaque fichier) et un ID unique, et le type défini à l'intérieur de l'événement, plutôt que l'inverse. Cela signifie que vous pouvez maintenant toujours lire les ID d'événements après avoir plié les événements eux-mêmes !



Ensuite, nous avons modifié le fonctionnement des textes conditionnels. Dans CK2, c'était un outil vraiment utile pour s'assurer que la saveur était localisée de manière appropriée à la situation du joueur, et nous permettait de rendre les événements très largement applicables tout en se sentant unique. Cela pouvait cependant devenir un peu lourd, car nous n'avions pas de méthode pour que les textes conditionnels s'excluent facilement les uns des autres, ce qui conduisait parfois à des situations comme celle-ci :



Ce n'est pas le pire du monde, mais c'est assez bien pour ce que nous voulons vraiment qu'il fasse.

Dans CK3, nous pouvons réduire ce nombre en utilisant un bloc first_valid à l'intérieur de blocs de texte conditionnels (comme dans la première image présentée), en choisissant la première entrée d'une liste qui répond à un ensemble de critères. Cela signifie qu'au lieu de devoir s'assurer que les blocs de texte conditionnels sont toujours mutuellement exclusifs en fonction d'un déclencheur (et qui a tendance à augmenter en complexité avec le nombre de textes conditionnels), nous pouvons simplement ordonner notre texte préféré logiquement en fonction de déclencheurs assez simples.

Par exemple, si j'ai un bloc de texte conditionnel où la copie est différente pour un personnage français, un personnage Ashari, et un personnage de plus de quatre-vingts ans, avec un texte par défaut pour toute personne qui n'entre pas dans ces catégories, j'écrirais quelque chose comme ceci:



Il sera alors automatiquement placé en bas de la liste. Un personnage français verra une chose, un Ashari non français en verra une autre, un non-Ashari non français de plus de quatre-vingts ans en verra une troisième, et tous les autres en verront une quatrième. Il est donc incroyablement facile d'ajouter une nouvelle copie contextuelle aux descriptions et aux titres des événements.

Un autre point mineur, mais comme le texte conditionnel est désormais également conservé dans le corps d'un bloc supérieur, il est beaucoup plus facile de le trier à la volée : quelle que soit la quantité de texte conditionnel dont vous disposez, il suffit d'un clic pour réduire le corps dans l'éditeur de fichiers de votre choix, et non plus une douzaine ou plus. Lorsque vous minimisez le nombre de clics, chaque petit détail compte !

Thèmes d'événements & arrière-plans
Quelques absences notables dans le format CK3 sont les blocs d'image et de bordure.

Et bien, c'est pour de bonnes raisons ! Elles ont été pour la plupart intégrées dans le nouveau système de thèmes des événements, que vous pouvez voir dans le tout premier exemple de script CK3 ci-dessus.

Les thèmes sont ce qui décide de l'icône de l'événement affichée en haut à gauche, ce qui permet de regrouper des ensembles d'événements largement thématiques, et de faire savoir au joueur à quoi il peut s'attendre à ce qu'un événement se rapporte. Ils nous donnent également un fond d'image approprié par défaut (qui, lui-même, détermine l'éclairage utilisé sur les portraits des personnages), qui changera en fonction de votre situation, et différents ensembles de SFX ambiants.

Les arrière-plans et les icônes thématiques peuvent être remplacés si nécessaire par une ligne de script manuel si nous pensons avoir un script plus approprié à montrer. Ainsi, bien que le système soit configuré pour réduire la quantité de travail nécessaire pour ajouter une saveur supplémentaire à chaque événement, nous avons toujours un contrôle total sur la saveur que nous incluons réellement si nous le voulons.

Il va sans dire que les thèmes des événements sont entièrement scriptables : vous pouvez modifier les icônes, l'arrière-plan par défaut, l'éclairage du modèle de personnage et les SFX ambiants que vous souhaitez, ainsi que créer et ajuster les thèmes en toute simplicité.

Portraits & Animations
Les bonnes choses ! Les portraits dans le nouveau système sont, de manière très surprenante, un peu plus dynamiques que dans le CK2, et un événement donné peut avoir entre 0 et 5 portraits au total. Parmi ceux-ci, deux sont entièrement animés (positionnés respectivement à gauche et à droite), et trois sont des portraits alignés de manière égale le long du bas de l'événement. Vous pouvez les utiliser dans n'importe quelle combinaison afin d'obtenir le bon aspect pour un événement.



Les portraits de gauche et de droite peuvent utiliser n'importe laquelle des nombreuses animations créées pour la sortie. Les portraits du bas ne sont pas animés, ce qui vous permet de visualiser les personnages secondaires mentionnés dans la description de l'événement.

On Actions pour Tous !
Tous les événements viennent de quelque part, et, dans CK2 (surtout au début du cycle de vie du titre), cela se faisait souvent par le biais du système Mean Time To Happen, qui nous permet de définir approximativement le temps qu'il faudrait à un événement pour se déclencher en (typiquement) quelques mois. Malheureusement, lorsque l'on met en regard un nombre extrêmement important d'événements, la flexibilité de ce système devient plus un inconvénient qu'autre chose, ce qui rend difficile la détermination de la fréquence de déclenchement d'un événement sans déclencheurs particulièrement rigoureux. Cela a également entraîné de nombreuses anomalies statistiques bizarres dues à un travail sur la base de probabilités pures, et des performances absolument réduites.

Au cours de la longue vie du CK2, nous avons commencé à nous orienter davantage vers le déclenchement d'événements via des on_actions, de petits accroches de code attachées à des caractéristiques ou des impulsions régulières qui activent des événements (et, si nécessaire, des effets) chaque fois que cette accroche est appelée. Cela demande un peu plus de travail pour équilibrer, mais cela nous donne beaucoup plus de contrôle sur la façon dont les événements sont appelés et le moment où ils le sont, tout en facilitant considérablement les réglages, et c'est très rapide du point de vue des performances.

Pour CK3, nous utilisons entièrement des on_actions pour déclencher les événements. Il y a tout un tableau d'accroches au code, qui nous permet de déclencher des événements soit lorsqu'une action spécifique se produit dans le monde (par exemple, à la naissance d'un personnage), soit sur une impulsion régulière (par exemple, tous les cinq ans). Ils peuvent être configurés pour se déclencher chaque fois qu'une action se déclenche, ou être placés dans une liste pondérée d'événements potentiels susceptibles de se déclencher (dans ce cas, les multiplicateurs de poids s'appliquent toujours et prennent en charge les facteurs habituels et autres).

Une amélioration majeure par rapport aux on_actions de CK2 (autre qu'un système d'utilisation plus approfondi et rationalisé, ce que je trouve très excitant mais j'apprécie également que d'autres personnes mènent des vies beaucoup plus intéressantes que moi et puissent avoir des normes plus strictes) est l'ajout de on_actions scriptés ! Ceux-ci nous permettent (et, bien sûr, à vous !) de créer et d'accrocher des on_actions entièrement en script qui se comportent comme des on_actions réguliers, au lieu de devoir toujours se fier aux on_actions codés en dur. Les on_actions scriptés se comportent alors exactement comme les on_actions codés, agissant comme un complexe d'événements/effets pondérés et non pondérés, juste appelés de quelque part dans le script accessible plutôt que dans le code inaccessible.

Par exemple, disons que j'ai fait une nouvelle série d'événements sur la réconciliation après une guerre civile, des voisins apprenant à vivre côte à côte après s'être battus pour des sièges opposés, ce genre de choses, et je veux que cela se produise chaque fois qu'une guerre civile se termine. Tout ce que j'ai à faire pour mettre en place ce flux, c'est d'ajouter quelque chose comme cela aux effets pertinents de la fin de la guerre :



Ensuite, créer un fichier incluant ce dernier dans le répertoire approprié :



Partout où vous pouvez scripter un effet, vous pouvez scripter une référence à une nouvelle (ou existante) on_action.

Le Bloc Immediate & Vous
Une nouveauté majeure du script CK, que nous utilisons avec une extrême régularité dans le bloc immédiat, est la liste scriptée !

Celles-ci nous permettent de faire un tri dans différents groupes, de sélectionner les personnages pertinents correspondant à un ensemble de critères, puis de ne trier qu'avec facilité dans la liste des personnages pertinents.

Par exemple, disons que je veux prendre tous les vieux grincheux parmi mes vassaux et mes courtisans, j'écrirais vaguement quelque chose comme ça :



Et puis, je veux choisir les deux personnes les plus en colère et les plus obstinées parmi elles afin qu'elles puissent se disputer lors d'un événement ou autre :



Trié ! Je peux alors faire référence à ces deux personnages dans ma localisation, leur appliquer des effets, en faire des personnages de portrait, etc. Vous pouvez noter notre nouvelle fonctionnalité alternative_limit : il s'agit de limites qui sont vérifiées si la limite immédiatement supérieure échoue.

Cela dit, nous nous efforçons de minimiser la maintenance inutile et d'éliminer les bogues potentiels avant qu'ils n'existent, et ce script devrait quand même sonner l'alarme, en appelant deux listes distinctes qui utilisent les mêmes conditions, qui font elles-mêmes partie d'un déclencheur scripté séparé.

Il y a plusieurs façons de résoudre ce problème, mais nous allons montrer quelques nouvelles fonctionnalités, avec l'effet ordered_in_list :



Ordered_in_list prend une liste et, à l'aide d'un système appelé script_maths (dont nous aurons, nous l'espérons, le temps de parler une autre fois), attribue des valeurs numériques aux éléments de cette liste. Il applique ensuite tout effet dans son bloc comme normal à, par défaut, l'élément ayant la plus grande valeur dans la liste (bien que, comme ici, nous puissions lui dire d'appliquer ses effets à n'importe quel nombre d'éléments de la liste). Ici, nous triions une quantité relativement faible d'éléments de la liste en fonction d'un ensemble assez limité de facteurs, mais cette fonctionnalité de tri peut être aussi complexe et étendue que vous le souhaitez.

Dans d'autres actualités liées au bloc immédiat, nous avons également facilité la sauvegarde des scopes (anciennement cibles d'événements, que vous pouvez voir un peu dans l'exemple ci-dessus), et des variables, et utilisons habituellement ce bloc pour définir les piqûres musicales pour un maximum de drame. La fonctionnalité standard du bloc immédiat (exécuté avant l'affichage de l'événement) est inchangée, et les effets visibles exécutés dans l'immédiat seront affichés sous un en-tête "S'est Produit" dans toutes les infobulles des options de l'événement.

Options: Donner de la personnalité à l'IA et stresser les joueurs
Enfin, les options. Les options se comportent de la même manière que dans CK2, avec un minimum d'une par événement visible et chaque option nécessitant du texte, mais vous permettant par ailleurs de saisir les effets que vous souhaitez.



Les deux principaux ajouts à ce domaine que vous remarquerez sont une utilisation considérablement accrue de ai_chance, et, assez communément, de stress_impact.

AI chance, comme dans CK2, régit la probabilité approximative qu'un personnage non joueur choisisse cette option. Dans CK3, nous faisons un usage beaucoup plus intensif de ce bloc et de nos ai_value_modifiers exposés (qui construisent une personnalité pour chaque personnage en fonction de la quantité de chaque valeur qu'il possède, elle-même dérivée principalement de ses traits) afin de s'assurer que les personnages agissent en accord avec leur personnalité autant que possible en pondérant presque toutes les options d'événements vers le haut ou vers le bas en fonction des ai_value_modifiers appropriés. Le bloc prend toujours d'autres déclencheurs également, de sorte que nous pouvons faire en sorte que l'IA préfère une option plus ou moins basée sur les traits, s'ils sont en guerre, si l'option concerne un rival, etc.

Stress_impact, alors que, c'est ainsi que nous organisons la nouvelle mécanique du stress, dont vous vous souvenez peut-être dans certains carnets de développement ! Ne stressez pas (*ahem*) si vous ne le faites pas : le stress est, en un mot, une mesure des effets négatifs que votre personnage acquiert en accomplissant des actions qui vont à l'encontre de sa personnalité (par exemple, un personnage compatissant n'aime pas torturer les gens).

Nous vérifions cela ici, en remplissant le bloc stress_impact avec tous les traits de personnalité pertinents pour choisir une option particulière, et en utilisant les valeurs de stress_impact scénarisées. Grâce à l'automagie sorcière, nous pouvons combiner n'importe quel nombre de stress gagnés et perdus dans le bloc stress_impact, et il sera calculé sur une option d'événement en un seul nombre.

Vous pouvez également ajouter le stress comme un effet ordinaire, en dehors du bloc stress_impact, auquel cas il ne se combinera pas. Si vous le souhaitez, vous pouvez même ajouter plusieurs blocs d'impact de stress, qui ne combineront que les modificateurs de stress individuels, ou vous pouvez omettre le bloc entièrement. Peu importe ce qui fait flotter votre scripting-boat.

Et, avec cela, nous arrivons à la fin d'un autre carnet de développement. Je serai là pendant quelques heures pour répondre à vos questions, et nous nous réjouissons de vous voir la semaine pro...

N'allez-vous pas couvrir Déclencheurs ?
Ha, vous êtes tombé dans le panneau de mon astucieux complot. Levez la main tous ceux qui ont remarqué le déclencheur furtif dans une capture d'écran précédente, vous gagnez exactement un point Internet !

Pour tous les autres, refaisons cette capture d'écran :



Maintenant, un bref rappel : les déclencheurs scriptés dans CK2 étaient un moyen de regrouper une longue liste d'exigences sous une seule référence, puis de se référer à cette référence lorsqu'il fallait vérifier des choses.

Par exemple, disons que j'ai deux endroits dans un événement où je dois vérifier plus de 20 conditions : l'événement sera parfaitement fonctionnel si je scrute toutes ces conditions deux fois, mais que se passe-t-il si quelqu'un, à l'avenir, met à jour une série de déclencheurs mais pas l'autre ? Source instantanée de bogues. Maintenant, que se passe-t-il si je dois vérifier ces déclencheurs plus de deux fois, ou sur plusieurs événements, ou, pour un maximum de sadisme, sur plusieurs événements dans différents fichiers ?

Comme vous pouvez l'imaginer, cela tourne rapidement au chaos. Cependant, nous ne voulons pas utiliser des déclencheurs moins complexes, en partie parce que cela rend le titre pire et moins amusant pour tout le monde (est-ce vraiment CK sans une quantité ridicule de spécificité ?), et en partie parce que cela ne fait que réduire l'ampleur du problème, et non le résoudre.

Au lieu de cela, nous créerions un déclencheur scripté, qui est la liste des déclencheurs écrits une fois dans un fichier qui peut être référencé par d'autres fichiers. Ensuite, à tout endroit où il faut vérifier ces déclencheurs, nous appelons le déclencheur scripté, qui vérifie son contenu. Chaque fois que les déclencheurs ont besoin d'être mis à jour ou corrigés, il suffit de corriger le déclencheur scripté une fois, et, en général, tous les endroits suivants qui vérifient le déclencheur scripté ont été corrigés par proxy également. Des économies de maintenance instantanées, une réduction énorme et immédiate du potentiel de bogues !

Cependant, dans CK2, ces déclencheurs scriptés devaient être stockés dans un dossier spécifique dans /common, séparé des événements (et autres scripts) auxquels ils faisaient référence. Cela peut ne pas sembler énorme, mais cela ajoute un peu de travail supplémentaire à la création et à la maintenance des déclencheurs scriptés, et ne vous donne vraiment qu'une énorme liste de déclencheurs scriptés, dont certains peuvent être utilisés seulement quelques fois à quelques endroits.

Dans CK3, nous améliorons cela en ajoutant des déclencheurs scriptés en ligne, c'est-à-dire des déclencheurs scriptés qui peuvent être écrits directement dans le fichier qui les utilise, à condition qu'ils ne soient utilisés que dans ce fichier. Pour les déclencheurs scriptés plus utilitaires qui doivent être utilisés dans plusieurs fichiers, l'ancien système de dossiers fonctionne toujours. Cela nous permet de séparer les déclencheurs de script majeurs et mineurs, et d'utiliser les déclencheurs de script (et, d'ailleurs, les effets scriptés) de manière beaucoup plus approfondie dans tout le titre, ce qui nous facilite considérablement (et vous aussi !) la création de scripts sans faire de compromis sur la complexité ou les détails tout en étant faciles à maintenir.

Et avec cela, nous arrivons à la fin réelle du carnet de développement. Nous vous donnons rendez-vous la semaine prochaine !

Vous pouvez discuter de ce nouveau jeu sur le forum

Carnet traduit avec l'aide de DeepL