Comme je l’ai mentionné dans le précédent journal de développement, notre prochain objectif avec UnderRail : Infusion était de produire une courte vidéo de gameplay qui présenterait un peu d’exploration et de combat. Cette vidéo est enfin disponible. Il s’agit d’une étape importante pour nous car le jeu est enfin dans un état suffisamment bon pour être vu en action, mais aussi avec cette vidéo nous révélons probablement le changement le plus important (et potentiellement le plus controversé) – le nouveau système de combat.

Il est essentiel de souligner que l’état du moteur et le développement d’Infusion ont progressé de manière significative. Les fonctionnalités visuelles et de gameplay fondamentales sont désormais stables et prêtes à accueillir davantage de contenu. Bien que certaines mécaniques secondaires doivent encore être migrées ou réimplémentées, ces tâches sont généralement moins complexes et plus rapides à réaliser.

Je pense que nous sommes enfin arrivés au point où toutes les caractéristiques visuelles et de gameplay fondamentales sont stables et robustes, prêtes à être complétées par du contenu. Bien sûr, de nombreux petits systèmes secondaires doivent encore être transférés du jeu précédent ou réimplémentés complètement, mais ils sont beaucoup plus faciles et rapides à développer.

Par exemple, cette année, j’ai passé beaucoup de temps à faire passer le moteur d’un espace basé sur les tuiles à un espace basé sur les voxels, ce qui permet une véritable verticalité, qui à son tour permet un mouvement libre dans l’espace 3D pour le joueur, les créatures et les objets. Nous pouvons maintenant avoir des plateformes au-dessus et en dessous, des ennemis qui volent (et peut-être plus tard qui nagent ou plongent), des escalades et des chutes dynamiques, etc.

Mais comme beaucoup d’autres mécanismes reposent sur la structure spatiale, j’ai dû les retravailler également, y compris les mouvements, la vue, la lumière, les interactions de combat et l’IA en général. Pour cette raison, ce n’était pas la direction que je voulais donner au moteur au départ, mais plus nous discutions des caractéristiques de gameplay que nous voulions mettre en œuvre dans ce jeu, plus il devenait évident qu’aucune solution ne suffirait.

L’histoire est similaire avec de nombreux changements visuels dans le jeu. Ce qui a souvent commencé comme une petite modification du moteur de rendu s’est finalement révélé inadéquat, m’incitant à procéder à une réimplémentation plus radicale.

Mais en fin de compte, je ne regrette rien. Le gros du travail est maintenant fait et le moteur comme le jeu s’en porteront mieux. Dans les mois et les années à venir, je m’attends à ce que nous fassions des progrès rapides et visibles au fur et à mesure que nous passerons de la phase technique à la phase de production du développement.

Passons maintenant aux changements dans le combat.

Dans la conception d’Underrail, je me suis inspiré de ce que je considérais comme le meilleur de la tradition des RPG occidentaux et j’ai essayé de créer à partir de là. C’est également le cas pour le système de combat. J’ai adopté la conception des points d’action/mouvement avec des tours séquentiels qui fonctionnaient assez bien dans un certain nombre de RPG classiques, en l’adaptant à mes besoins spécifiques. Au fil des années, cependant, j’ai réalisé que, bien qu’il s’agisse d’une bonne façon d’aborder le combat en groupe, elle présente des inconvénients significatifs lorsqu’il s’agit de RPG avec un unique personnage, et encore plus lorsqu’elle est couplée à l’exploration libre :

La réactivité, ou plutôt le manque de réactivité. Comme les vétérans d’Underrail ne le savent que trop bien, si vous tombez par hasard dans un combat avec plusieurs ennemis puissants et que vous perdez un jet d’initiative, vous allez plus souvent qu’autrement vous faire ratatiner ou probablement vous faire assommer dans le même temps. En effet, dans ce système, le fait de donner un long tour à un personnage puissant, sans possibilité de réagir ou de contrer ses actions, désavantage considérablement le groupe qui le reçoit. Alors que dans un combat en groupe, vous pouvez tolérer qu’un ou deux de vos personnages soient détruits ou temporairement désactivés, si vous contrôlez un seul personnage, il s’agit souvent d’une situation irrécupérable. Dans une moindre mesure, il en va de même pour le joueur qui prend l’avantage sur les PNJ, même si, contrairement au joueur, ces derniers peuvent souvent se permettre de perdre une ou deux unités.

Deux modes temporels. Chaque chose active dans le jeu nécessite deux implémentations pour des modes opposés. L’un est le mode temps réel où les choses se produisent simultanément et peuvent et doivent être régies immédiatement, et l’autre consiste en de longs tours séquentiels où chaque acteur ne peut réagir qu’à l’état final du tour précédent. Cela va au-delà du combat lui-même et concerne l’IA en général et le comportement de l’environnement lui-même.

Lenteur. Ce système s’adapte mal à un grand nombre de belligérants si le joueur ne contrôle qu’un seul personnage. Le rapport entre l’attente et l’action du joueur devient de plus en plus mauvais avec chaque PNJ ajouté à la rencontre. Pire encore, parce qu’il est nécessaire de garder tous les combats au tour par tour afin d’éviter d’avoir à implémenter et à maintenir une IA de combat en temps réel, parfois dans Underrail vous êtes juste un observateur passif du combat de tierces parties.

Le nouveau système de combat est conçu pour répondre à toutes ces questions et à bien d’autres encore. Il s’agit d’une combinaison de combat roguelike traditionnel, où les tours sont toujours successifs mais à tours simultanés. Voici donc les grandes lignes de son fonctionnement :
– Dans des conditions normales, le jeu est en mode temps réel.
– Lorsque la présence d’entités hostiles l’exige, le jeu passe en mode combat. En général, le joueur ne pourra pas activer le combat manuellement, sauf dans des conditions particulières.
– En mode combat, tout est mis en pause jusqu’à ce que le joueur effectue une action. L’action prend un certain temps et ce temps est accordé à tous les participants non joueurs pour qu’ils l’utilisent pour leurs actions ou leurs actions en cours (telles que le déplacement, l’attaque, l’activation de capacités spéciales).
– Le temps est accordé aux PNJ est crucial, car ils peuvent parfois agir immédiatement pour interférer avec le joueur.
– Ce temps peut également être accordé en bloc ou en petites quantités (par exemple, des capacités telles que les soins).
– Le joueur est libre d’agir et de donner du temps supplémentaire aux PNJ à moins qu’il ne soit « bloqué » par une action d’un PNJ en cours. – Un ennemi dans la mêlée avec le joueur est pertinent et ce dernier doit « respecter » son temps disponible ; un crabe neutre qui erre de l’autre côté de la carte n’est pas pertinent et il peut faire ce qu’il veut.
– Les PNJ ne se bloquent généralement pas les uns les autres. Cela signifie qu’ils agissent simultanément la plupart du temps.
– Comme les PNJ ne font qu’exécuter leur IA en temps réel tout en s’arrêtant pour prendre du temps, il n’est pas nécessaire d’implémenter une IA séparée, et ils peuvent également profiter du temps où le joueur agit pour « réfléchir » à leur situation.

J’espère que cela vous permettra d’y voir plus clair sur ce que vous avez vu dans la démo de combat. Il s’agit de l’essentiel du système, mais, bien sûr, le diable se cache dans les détails. La quantité et le timing du transfert de temps entre le joueur et les PNJ, ainsi que la détermination des actions (et des circonstances) qui sont simultanées et de celles qui sont bloquées (séquentielles) – ces choses vont être cruciales. Je vais peaufiner et mélanger ces éléments tout au long du développement dans le but de rendre les combats aussi rapides, fluides et amusants que possible tout en les gardant cérébraux et tactiques. Vous devriez être capable d’aller vite et furieusement quand vous le pouvez et aussi délibérément lent quand c’est nécessaire. Et vous devriez pouvoir passer de l’un à l’autre de manière transparente.

Les changements apportés au combat ne se limitent pas à la gestion du temps, bien qu’il s’agisse de la modification la plus radicale. Il y a d’autres facteurs et considérations, comme la concentration, l’élan, l’endurance, la portée, différentes catégories de vitesse pour remplacer les modificateurs de points d’action/mouvement, différentes positions de combat et attaques, etc, etc. Je donnerai plus de détails à ce sujet dans les prochains devlogs.

Quelle est la prochaine étape ?

Après une courte pause pour les fêtes de fin d’année, nous allons entrer en pleine production l’année prochaine. Nous voulons produire plus d’environnements, de zones, d’équipements, de créatures, plus de tout. En même temps, je vais travailler à la réimplantation de tous les mécanismes de base du jeu précédent, comme le crochetage, le piratage, le commerce, ainsi qu’à la refonte de certains éléments de progression du personnage, comme les exploits et, bien sûr, le système de montée en niveau lui-même.

Notre objectif est d’avoir suffisamment de matériel pour créer une page Steam d’ici la fin de l’année prochaine et de commencer à faire connaître le jeu et à recueillir les précieux ajouts de la liste de souhaits. À un moment donné, il est probable que nous lancions le jeu en accès anticipé, comme nous l’avons fait pour notre premier jeu. Pour l’instant, je ne peux pas vous donner de calendrier précis ou large pour cette sortie, alors ne me posez pas la question. Ce qui est important pour nous, c’est de nous assurer que le jeu fonctionne bien, qu’il est amusant et qu’il y a suffisamment de contenu pour que vous puissiez en avoir au moins pour votre argent.