Processus de design et intégration – solo : Skavendom – Mod de Total War: Warhammer 3

Introduction :

Dans Total War: Warhammer 3, les Skavens peuvent soit prendre le contrôle d’une région en capturant sa ville (et ainsi créer un “nid”), soit secrètement fonder une “ville souterraine” en dessous d’une région appartenant à une autre faction. Ces deux mécaniques sont indépendantes et n’interagissent pas entre elles.

La nouveauté clé que Skavendom apporte aux joueurs est la capacité de convertir le niveau de leurs villes souterraines en celui de leurs nids lorsque la région passe en leur possession.

Cette fonctionnalité provient d’une réflexion :

• Top-Down :

  • Dans l’univers Warhammer Fantasy, les Skavens sont des créatures qui vivent dans des villes souterraines appelées des “nids”. Ils ont tendance à s’installer dans les ruines, ou en dessous des villes d’autres civilisations. Lorsqu’ une ville est prise par les Skavens, l’infrastructure des peuples vivant à la surface est souvent pillée et détruite.

    • De ce fait, peu importe la taille de la ville, si elle appartient à une autre race, et qu’il n’y a pas de ville souterraine en dessous, elle donnerait alors un nid de niveau 1 lorsqu’elle est capturée.

  • Dans les jeux Vermintide 1 et 2, les Skavens envahissent la ville d’Ubersreik et le fort Helmgart en utilisant des villes souterraines. Ces villes souterraines deviennent alors des nids.

    • C’est pourquoi, si une faction Skaven possède une ville souterraine développée en dessous de la ville d’une autre faction, cette ville souterraine devient alors un nid du même niveau lorsque l’occupant à sa surface est expédié.

• Bottom-Up

  • D’un point de vue gameplay, les villes souterraines sont en dehors de la boucle de jeu principale : Construire une armée ⇒ Prendre une ville ⇒ Capturer une province ⇒ Répéter. Car une ville souterraine ne peut coexister avec un nid. Si l’on prend une région dans laquelle on possède une ville souterraine, celle-ci est détruite, et tout ce qu’on y a construit disparaît.

    • En ajoutant la conversion de ville souterraine, une ville souterraine peut alors être une étape dans la prise d’une ville, et donc dans la boucle de jeu : elle permet par exemple de monter en niveau une ville rapidement et indépendamment du niveau de croissance d’une région.

  • Les Skavens ont une mécanique leur permettant de payer de la Nourriture (une ressource propre à leur faction) afin de monter le niveau d’une ville capturée ou colonisée instantanément.

    • Personnellement, cette mécanique brise mon immersion. Elle engendre certaines stratégies abusives qui remettent en question d’autres mécaniques. J’ai décidé de la retirer, car la conversion de cités souterraines est une meilleure alternative selon moi, et répond à un besoin similaire.

Pour définir le niveau d’une cité souterraine, j’ai choisi les deux bâtiments de la branche “Annexation” : Warren et Stronghold. Ces bâtiments ont la particularité d’être sur 5 niveaux, et se trouvent dans le premier onglet de construction de bâtiments (comme les bâtiments principaux des villes).

Au niveau des tables du jeu, j’ai donc commencé par les rendre mutuellement exclusifs, et à les modifier pour que chacun d’entre eux apporte des avantages uniques et nuancés par rapport à l’autre. En effet, le Warren, que je visualise comme la présence d’un grand réseau de tunnels dans la région, offre au joueur des avantages de combat indirects dans cette région. Tandis que le Stronghold, que je vois plutôt comme de grands tunnels connectant cette région aux nids principaux de la faction, permet au joueur de régénérer ses troupes et de recruter des unités en quantité via le recrutement global à des prix réduits.

Pour la logique permettant de changer le niveau du nouveau nid une fois la ville prise, je me suis tourné vers les scripts Lua. En effet, aucune mécanique de la sorte n’existe en jeu ; je devais donc la programmer moi-même.

Un peu de contexte :

Lorsque l’on fait des scripts pour Total War, il y a deux méthodes principales pour ajouter ou modifier des mécaniques existantes : l’écoute d’événements de jeu, et les requêtes.

L’écoute d’événements permet dans un premier temps à un moddeur de récupérer des informations suite à un événement passé dans le jeu.

Il existe 251 événements pour Warhammer 3 selon la documentation, parmi ceux-ci, l’événement “RegionFactionChangeEvent” qui se déclenche à chaque fois qu’une faction acquiert du territoire par n’importe quel moyen : (confédération, offre de diplomatie, conquête, colonisation…).

Comme chaque événement, cet événement possède une variable “context” qui donne accès à un ensemble de fonctions permettant d’avoir des informations sur le contexte de cet événement.

Dans notre exemple, le contexte de “RegionFactionChangeEvent” donne accès à 3 fonctions :

1. previous_faction : qui renvoie l’interface faction de la faction qui possédait le territoire avant son changement de propriétaire.

2. reason : qui renvoie la raison de ce changement, sous forme de chaîne de caractères.

3. region : qui renvoie l’interface région de la région concernée.

Avec ces informations, j’ai accès à toutes les informations relatives à cet échange de territoire qui vient d’avoir lieu.

Ou est-ce vraiment le cas ? Car si vous avez remarqué, aucune des 3 fonctions n’évoque la faction qui reçoit la région. Ce qui n’est guère pratique si l’on veut affecter cette faction-là !

Aucune fonction ne donne explicitement accès à cette valeur, car cette méthode serait redondante ! En effet, nous avons déjà accès à une information permettant de trouver le nouveau propriétaire. Cette information est la fonction region, qui donne accès à l’interface “region”, contenant elle-même une grande quantité de fonctions donnant accès aux informations concernant cette région, telles que le nom de la faction qui la possède entre autres. En effet, étant donné que l’on écoute un événement qui a déjà eu lieu, si l’on questionne la région pour connaître son propriétaire actuel, elle nous donnera le nom du nouveau propriétaire !

Donc pour accéder à l’interface faction du nouveau propriétaire et propriétaire actuel de la région, il suffit d’écrire la ligne suivante :

context:region():owning_faction():

Avec ces connaissances, retournons donc à notre script, qui a pour objectif de permettre à une faction Skaven de passer son niveau de ville souterraine à son nid lorsqu’elle acquiert une ville.

Nous aurons besoin d’écouter le bon événement. Il existe dans notre contexte “CharacterPerformsSettlementOccupationDecision” qui se lance lorsqu’ une faction a vaincu la garnison d’un territoire, et est sur le point de choisir ce qu’elle fera de ce territoire (dont le choix de l’acquérir).

Ou encore “RegionFactionChangeEvent” cité précédemment, qui se déclenche lorsqu’ un territoire change de propriétaire de quelconque manière.

Si ma mécanique n’affectait que la conquête, le premier événement serait tout aussi éligible que le second pour ce travail. Mais étant donné que ma mécanique devrait affecter toute prise de territoire, j’ai choisi la seconde option.

J’écoute donc “RegionFactionChangeEvent”, et je cherche à récupérer le niveau du bâtiment d’annexation de la ville souterraine se trouvant sous ce territoire s’il existe.

newFaction = context:region():owning_faction():name()
myUndercity = context:region():foreign_slot_manager_for_faction(newFaction)

--[[du code parcourant les batiments de la ville sous terraine, renvoyant le niveau
du batiment d'annexation si il existe]]

-- suivi du code permettant de monter instantanément le niveau de la ville en question

Le problème :

Malheureusement, après de nombreux essais, le niveau de la ville restait inchangé.

Je parcours alors mon rapport d’erreur, et j’ai remarqué que quoi que je fasse, la variable myUndercity est toujours vide ! Cela ne provenait ni d’une faute de langage, ni de frappe.

Il m’a fallu de nombreux essais, pour finalement comprendre mon erreur. Vous vous souvenez quand j’expliquais plus haut que la région donnait le nom de son nouveau propriétaire, car l’événement est écouté après son exécution ? Cette logique s’applique aussi à l’existence d’une ville souterraine sous la région : étant donné que la région est déjà prise au moment de l’événement, et que l’on ne peut pas posséder une ville souterraine sous notre propre nid (d’où la conversion de villes souterraines), alors celle-ci n’est déjà plus accessible quand l’événement a lieu !

Cela cause alors un gros problème, car il me faut forcément accès à cette information pour réaliser mon changement.

La solution qui m’est alors venue à l’esprit était de sauvegarder dans un tableau la liste des villes souterraines d’une faction donnée, de manière à ce que, lorsque l’événement a lieu, je puisse retrouver la référence de la ville souterraine ayant disparu afin d’appliquer ses valeurs au nid correspondant.

Cela m’a amené à créer une table Lua qui liste, pour chaque faction skaven, chaque région dans laquelle ils possèdent une ville souterraine de niveau 2 ou plus.
Cette liste est parcourue lors de l’événement, et si la faction et la région correspondent à celles de la liste, le niveau est alors appliqué à la ville.

Il restait alors à définir comment je remplis cette liste. Étant donné que le jeu ne sauvegarde pas automatiquement les valeurs de mon script entre les sessions de jeu, je ne pouvais pas ajouter progressivement les villes souterraines à une liste, et les supprimer au fur et à mesure.

J’ai donc établi un script qui, à chaque début de tour, enregistre la liste des villes souterraines de la faction Skaven qui joue. De cette manière, cette liste contiendra seulement les entrées existantes à chaque tour.

C’est alors qu’un autre problème est survenu : lorsqu’un joueur sauvegarde et quitte la partie pendant son tour, et recharge sa partie plus tard, mon tableau n’existe plus, mais son tour est toujours en cours.
Pour prendre en compte ce scénario très courant, je sauvegarde aussi la liste des villes souterraines de la faction dont c’est le tour lorsque la partie est chargée !

Après une bonne quantité d’essais et d’erreurs, la fonctionnalité de conversion des villes souterraines a alors vu le jour.