Little God Story – DevBlog #2

Les premiers pas

Dans un projet, il y a toujours le moment où il faut ramener son concept sur un plan plus pragmatique. Après le « j’aimerais faire ça« , il faut passer au niveau « suis-je capable de le faire ? » Plus expérimenté depuis mon projet précédent, je me suis penché immédiatement sur la partie programmation. En effet, Unreal Safari m’avait montré qu’il était essentiel d’avoir un prototype minimal pour commencer à faire un level-design un tant soit peu intéressant.

L’embryon de Little God Story est, sur le papier assez simple. Voilà les features qui m’intéressaient au départ :

1 – Le joueur peut changer d’élément et cela affecte certaines caractéristiques (vitesse et hauteur de saut)
2 – Certaines parties d’un niveau sont liées à un élément et interagissent avec le joueur selon l’élément dans lequel il est (par exemple, le joueur meurt dans le Feu sauf s’il est dans l’élément Eau)
3 – La vue est à la troisième personne

Coder cela m’a pris deux jours. En effet, il n’y a rien compliqué à cela. J’ai d’abord utilisé mes connaissances d’Unreal Safari pour faire changer les caractéristiques de saut et de déplacement (en gros, c’était le même principe). Pour la partie Eléments du monde, cela n’a pas été très difficile. En effet, il existe déjà un système de Volumes dans l’Unreal Engine dont les biens nommés UTWaterVolume et UTKillZVolume. En les combinant, il a été facile de créer des volumes qui ne blessent que selon l’élément utilisé.

Le prototype créé est ultra-simple et encore pas mal buggué (le temps de réaction aux touches est de l’ordre de la seconde, les volumes blessent le joueur systématiquement quand on entre dedans…). Cependant, il est suffisamment avancé pour commencer à faire des maps de tests et à déterminer les distances de saut pour chaque élément, les différences de vitesse entre feu et terre (ce qui est très important pour les puzzles incorporant un besoin de rapidité). En quelques clics, je teste le saut à travers le Feu (base originelle de mon concept). Je trouve ça sympa de devoir changer d’élément en plein saut. Voilà un aspect plateforme qui est déjà implanté et déjà agréable.

A peine le prototype terminé, j’ai ressenti le besoin de le perfectionner bien qu’il atteigne les objectifs que je m’étais fixés. En effet, il est très désagréable de ne pas pouvoir savoir avec quel élément on joue. Même si il y a des ressentis en jeu (ne serait-ce que la vitesse de déplacement), l’intégration d’un HUD, même sommaire, paraissait essentiel, ne serait-ce que pour contrôler que les éléments changeaient bien quand j’appuyais sur la touche voulue (c’est ainsi d’ailleurs que je me suis aperçu du temps de réponse de mon code…). Le premier HUD est alors ultra-simple et moche, mais fonctionnel.

Les contrôles

Premier HUD
Premier HUD

Deuxième souci qui va vite se manifester : l’ergonomie des contrôles. Même s’il est prévu que le joueur puisse les changer, le rôle de la souris va ici être prépondérant. En effet, à l’origine, il n’y a pas d’armes dans Little God Story. Résultat, les clics gauche et droit sont utilisés pour changer d’éléments. Or, dans le cadre d’une permutation d’élément, ce n’est pas forcément ce qu’il y a de plus pratique. Les contrôles sont encore un sujet de discussion avec les testeurs. En effet, une arme a été ajouté (clic gauche) et il y a de forte chance qu’un tir secondaire soit implanté (clic droit). Résultat : le changement d’élément risque de devenir plus compliqué à gérer et la partie plateforme moins ergonomique. Dès le départ (même quand le jeu était plus simple et proposait moins de features), le souci d’ergonomie s’est posé. Je précise quand même que l’idée d’adapter les contrôles à un pad ne m’a jamais effleuré l’esprit…

Rapidement, je me suis aperçu également qu’il faudrait restreindre l’utilisation des éléments. En effet, en jouant aux premiers niveaux de test, j’ai pris l’habitude de me balader en mode Feu systématiquement pour aller plus vite et à sauter en mode Air pour assurer la hauteur de saut. J’ai donc du intégrer une jauge de mana pour contrôler tout ça. Je reviendrais là-dessus dans un prochain article, ce genre de feature méritant beaucoup plus qu’un simple paragraphe…

Première modélisation du personnage
Première modélisation du personnage

La vue à la troisième personne

Dernière chose qui fut changée dès les premiers tests : la vue à la troisième personne. Les premiers testeurs ont en effet critiqué cet aspect là, en arguant qu’elle n’apportait rien. J’ai donc du réfléchir à l’éventualité de supprimer ou non cette vue. J’avais prévu de donner une identité visuelle originale à mon personnage afin de renforcer l’idée de « petit dieu ». Abandonner la troisième personne me faisait perdre un aspect prépondérant. En revanche, passer à une vue à la première personne faisait que la modélisation et l’animation du personnage n’étaient plus essentielles, du moins dans l’immédiat. De plus, cela m’évitait de nombreux problèmes de caméra inhérents au style plateforme vue de derrière. J’ai donc fait sauter sans trop de remord la vue à la troisième personne.

Cela a eu beaucoup d’influence dans le développement du jeu en lui-même. Ce changement de perspective a changé radicalement les sensations de jeu et m’a poussé ensuite à ajouter des armes car Little God Story avait perdu fortement en dynamisme. J’avoue être également un très gros joueur de FPS. C’est clairement ce que je préfère. Je pense être plus à même de comprendre ce que veulent des testeurs sur ce genre de jeu que pour un jeu à la troisième personne où mes seules références sont Prince of Persia : The Two Thrones et Prince of Persia : Warrior Within… (quoiqu’on me reproche pas mal de faire un FPS puzzle-game sans avoir joué à Portal…)

L’intégration des boutons

Rapidement, je comprend que l’aspect plateforme sera insuffisant pour faire un jeu réellement intéressant. Tous les jeux plateforme intègre un aspect différent, souvent des combats (Prince of Persia, Tomb Raider…). Le problème, c’est que faire des combats demande beaucoup de boulot :

  • Faire des personnages non-joueurs
  • Animer ces personnages
  • Animer leurs armes
  • Donner une IA à ces personnages
  • Ajouter des armes au personnage principal
  • Ajouter les animations de ces armes
  • Coder les effets de ces armes (impacts, muzzleflash, dégâts…)
  • Équilibrer les combats
  • … etc
Le bouton Terre, le plus fréquemment rencontré dans le jeu
Le bouton Terre, le plus fréquemment rencontré dans le jeu

J’ai donc vite rejeté cette idée. Non seulement parce-que cela me paraissait infaisable seul, mais aussi parce-que je ne voulais pas faire des combats peu intéressants avec des ennemis imbéciles. Je me suis donc orienté vers une partie réflexion. Je ne l’ai pas fait que par fainéantise, dès le concept j’avais quelques idées ce genre (un peu comme Prince of Persia comporte quelques énigmes). Je me suis donc lancé dans la programmation d’un système d’interrupteurs basé sur les éléments. Par exemple, voilà le genre d’énigme prévu :

  1. Pour ouvrir la porte, je dois activer un interrupteur Feu
  2. Je dois donc me changer en Feu
  3. L’interrupteur Feu est immergé dans l’Eau
  4. Je ne peux donc pas l’activer (sinon je meurs car en Feu, je ne peux aller dans l’Eau)
  5. Comment changer ça ? (retirer l’eau, faire sortir l’interrupteur, etc.)

Il est évident qu’avec les quatre éléments, ce genre d’interrupteurs permet de créer de nombreuses énigmes. Malheureusement, le jeu s’est vite orienté vers le principe : actionner les interrupteurs dans le bon ordre. Dès les premiers tests, il a été important de corriger cela et d’éviter un aspect un peu rébarbatif, sans supprimer ce concept pour autant, qui donne une identité visuelle et de gameplay au jeu. Il fallait dynamiser le jeu. J’ai donc été rapidement rattrapé par mes démons : si je voulais faire un jeu varié et intéressant, je n’avais pas le choix : il fallait ajouter des « armes »… (pour rappel : les armes sont une des étapes primordiales que je ne suis jamais arrivé à passer pour Unreal Safari, tant en terme d’imagination que de réalisation).

A ce stade, je suis un peu taraudé entre deux tendances : je tiens un concept intéressant mais j’ai conscience qu’il faut que je le développe un peu pour qu’il atteigne un niveau autre qu’un simple concept intéressant (comme on voit beaucoup pour les projets étudiants par exemple). Il est toujours difficile de passer le cap d’une idée à un jeu complet. Malgré le fait que je voulais être très prudent sur ce point-là, je me sentais obligé d’être plus ambitieux… Pour le meilleur et pour le pire !

4 commentaires à propos de “Little God Story – DevBlog #2”

  1. Dans Puzzle dimension, il y a aussi des interrupteurs, et des cases sur lesquelles on ne peu passer qu’une seule fois par exemple, donc la plupart du temps, un niveau se résume à trouver le chemin à prendre pour arriver à la fin sans être bloquer quelque part.
    Portal c’est souvent un peu pareil. The Ball aussi il me semble.
    Mais ça n’est en rien répétitif si tu arrives à mettre une grosse dose de réflexion et/ou trouver de nombres situation différentes possibles.

    Tes devblog ne sont pas assez espacés à mon gout. Tu pourrais nous tenir vraiment en haleine comme avec une bonne séries tu n’en publiais qu’un seul par semaine par exemple.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*