Little God Story – DevBlog #3 (Level-Design)

Je lâche un peu la génèse pure de Little God Story pour parler un peu de level-design. Ici, il est question d’un puzzle du jeu, de l’idée de départ jusqu’à la conception finale (graphique et technique). Je prends ici l’exemple du puzzle considéré comme le plus réussi par les testeurs. Il a subi également nombre de remaniements et de changements, ce qui à mon avis justifie d’en faire un bilan.

Pour les gros fans de Little God Story qui craignent que je spoile (si ça existe, signalez vous !), évitez de lire car la solution de l’énigme est donnée !

Idée de départ

Je rappelle que Little God Story est un jeu mixant phases de plateformes et énigmes, le tout en utilisant les quatre éléments. Lors des premiers tests, certains ont regretté le manque de phase de plateforme pure. Je me suis donc mis en tête de faire une énigme incorporant un aspect plateforme. Rapidement me vient à l’idée de faire une plateforme tournante sur laquelle le joueur devrait sauter pour passer un fossé. Le fait qu’elle bouge obligerait le joueur à sauter au bon moment. Afin d’ajouter un côté puzzle, une tuyère créerait une flamme au niveau de la plateforme tournante, forçant le joueur à l’éteindre pour passer. On peut donc résumer l’énigme à :

  1. Eteindre la flamme
  2. Activer la roue
  3. Traverser la fosse en sautant sur la plateforme mouvante

Premiers tests

En terme de level-design, je pense tout de suite à mettre deux interrupteurs : un de Terre pour actionner le mouvement de la roue et un d’Eau pour noyer la tuyère et donc l’éteindre. Rapidement, je crée un prototype de ma salle et les problèmes surgissent, certains n’ayant pas été anticipés…

  • si l’Eau monte trop haut, on peut franchir le fossé en nageant
  • on peut sauter sur la tuyère pour traverser le fossé
  • le joueur va avoir tendance à activer les boutons sans se demander à quoi cela peut servir
Première ébauche du puzzle
Première ébauche du puzzle

Pour le premier cas, deux possibilités : faire que le fossé se remplisse puis se vide complètement ou faire que l’eau baisse légèrement de niveau. J’ai choisi la deuxième option car elle permet de changer l’ambiance de la salle. En effet, les reflets de l’eau amènent à la fois du dynamisme par le mouvement des vaguelettes, mais également un aspect beaucoup plus froid que la chaleur des flammes précédentes. Cela permet d’utiliser une même salle pour faire deux ambiances différentes.

Dans le deuxième cas, j’ai simplement modifié un peu le principe. Au départ, il y avait trois tuyères alignées. J’ai réduit le nombre à une (afin d’éviter un passage simple) et j’ai créé un modèle de collision beaucoup plus abrupte que le précédent, empêchant le joueur de prendre appui sur l’objet.

Pour le troisième aspect, j’ai décidé de séparer les deux boutons en les positionnant dans deux salles différentes : l’un en face de la roue (bouton Terre), l’autre dans une salle indépendante (bouton Eau). Les problèmes n’ont pas tardé à arriver : quand on actionne le bouton Eau, on ne peut pas voir ce qui se passe. Certes, on peut le deviner, mais c’est trop léger. J’ai donc ajouté en premier lieu une cinématique lors de l’actionnement de l’interrupteur Eau. Ce genre d’artifice est rarement apprécié des joueurs. En effet, trop de cinématiques cassent l’ambiance et le dynamisme de l’aventure.

Plus loin dans le level-design

Même si mon énigme marchait plutôt pas mal, elle était très légère niveau level-design. Certes, j’avais travaillé les lumières pour un rendu sympa mais très proche des salles précédentes. J’ai alors décidé de reprendre entièrement la conception du lieu pour le rendre plus intéressant.

Il faut savoir qu’en level-design, il y a deux choses à essayer d’éviter le plus possible (selon moi en tout cas) :

  1. Le syndrôme « couloir » : on va dans une salle, on passe une porte, on arrive dans une autre salle, on passe la porte…
  2. Le syndrôme « ouvert » : le monde est tellement ouvert qu’on ne sait pas où aller.

Il est ainsi important dans les jeux linéaires (dont fait partie Little God Story par son essence même) d’éviter l’impression d’être dans un couloir trop balisé. Et dans les jeux ouverts limiter un minimum l’ouverture par des falaises par exemple pour guider le joueur. Dans Little God Story, je suis un peu coincé par le côté puzzle qui nécessite beaucoup de goulets d’étranglement, des endroits où le joueur doit forcément passer. La facilité serait un design en couloir. Un peu plus difficile, en croix (histoire de faire marcher le joueur et de lui donner l’impression d’ouverture).

J’ai opté pour un chemin en croix en essayant au mieux d’y mettre une logique afin de faire accepter au joueur la nécessité de faire ces allers-retours (pas toujours agréables, il faut bien l’avouer). Dans ce cas-là, j’ai déplacé la salle du bouton Eau et ajouté des vitres afin de permettre au joueur de voir directement l’effet de son action. Plus de cinématique ou d’ambiguïté, le joueur voit immédiatement ce qu’il a fait. De plus, les fenêtres en verre donnent des effets de distorsion sympathiques et enrichissent le design de la salle. De même ajouter des tuyaux allant de la « salle de contrôle » à la salle principale amène des éléments de décor bienvenus.

Complexification de l’énigme

La nouvelle salle vitrée de linterrupteur Eau
La nouvelle salle vitrée de l'interrupteur Eau

Cependant, l’énigme reste très bête. Appuyer sur deux boutons, qu’importe l’ordre ! Afin de donner un aspect plus sympa à l’ensemble, il faut ajouter un dynamisme. Pour cela, je vais utiliser l’arme que j’ai codé : les boules de feu. En effet, le joueur, en mode Feu, peut lancer des boules de feu et détruire de petits objets en bois. J’ai donc ajouté un bout de bois qui bloque l’ouverture d’une grille, qui elle-même donne accès à la salle du bouton d’Eau. Le joueur doit donc remarquer ce bout de bois, le détruire, puis ouvrir la grille.

Sans changer réellement le côté énigme, il s’est avéré que le concept du bout de bois à détruire a posé problème à certains testeurs, repoussant la résolution de l’énigme. Le résultat était simple : le joueur comprend qu’il doit passer cette grille mais n’y arrive pas. Enfin, il y avait un côté puzzle réel dans cette énigme. A ce niveau-là, l’énigme a été testée et plutôt approuvée comme la plus intéressant et réussie du jeu (qui est loin d’être terminé).

Depuis, j’ai ajouté des armes d’Eau, d’Air et de Terre même si toutes leurs fonctionnalités ne sont pas implantées. Les idées actuelles seraient du genre :

  • TERRE : permet de défoncer des objets au contact (exemple : défoncer un objet qui gêne le passage)
  • AIR : permet de déplacer des objets à distance, en les poussant ou en les tirant (exemple : actionner un levier hors de portée)
  • FEU : permet de détruire un objet en bois ou d’allumer un feu (exemple : détruire une barrière qui gêne le passage, allumer un feu pour démarrer une machinerie, faire fondre de la glace)
  • EAU : permet d’éteindre une flamme, geler de l’eau ou induire un courant dans de l’eau stagnante (exemple : actionner la roue d’un moulin, arrêter une machinerie…)

Toutes ces possibilités sont encore à l’étude et pourront être (je l’espère) étendues à d’autres possibilités. Parfois, sans faire partie d’une énigme, ces petites choses peuvent amener un peu de dynamisme. J’ai ainsi rajouté une grille à dégommer avant d’entrer dans la salle au bouton Eau. C’est inutile mais assez fun (même si l’effet reste à travailler pour être vraiment sympa).

Dernière chose ajoutée et non des moindres, la roue ne s’actionne non plus avec un bouton, mais par l’action de l’eau. En gros, il faut immerger la fosse d’eau. Avec l’arme d’Eau, on donne un courant à cette eau. Ce courant actionne alors des pales qui, par un système d’engrenage, fait tourner la roue principale. Ainsi, le côté énigme est renforcé car la solution est beaucoup moins évidente qu’un gros interrupteur lumineux en plein milieu du chemin…

Voilà où en est l’énigme actuellement. Il reste beaucoup de boulot (notamment sur les effets de transition : la mise en route d’un courant dans l’eau et du fonctionnement progressif de la roue).

Amélioration des graphismes

J’ai déjà dit que les graphismes avaient été amélioré par le changement du layer (disposition des salles) global et la mise en place de fenêtres. Mais c’était nettement insuffisant. En effet, il faut prendre en compte le jeu (et le niveau) dans son ensemble. Or, cela fait plusieurs salles que le joueur ne voit pas la lumière du jour et qu’il se balade dans des salles carrées, éclairées par des flammes (torches, tuyères…) et des boutons (surtout verts et bleus/blancs). Si le tout est plutôt sympathique à l’oeil, il est aussi particulièrement répétitif et donc lassant. Cette énigme passe un palier supplémentaire dans ce que doit faire le joueur, il est donc essentiel de lui donner un impact graphique qui va avec. J’ai donc revu une grande partie de la conception de la salle principale afin de lui donner de la personnalité.

Pour changer un peu, j’ai décidé de laisser entrer la lumière du jour par le toit en le détruisant (très) partiellement. Cela amène non seulement un dissymétrie bienvenue mais renforce également le côté abandonné du château (qui fait partie du scénario). La lumière du jour (bleutée) amène des ombres supplémentaires (et donc un aspect moins vide à l’ensemble), une colorisation supplémentaire mais également un peu de lumière. En effet, quand on éteint la tuyère en la noyant, la salle perdait sa principale source de lumière et finissait pas être trop sombre. La salle est au départ très lumineuse, avec des ombres marquées et des couleurs chaudes. Après activation du bouton Eau, on découvre une salle dominée par un côté plus froid (présence d’eau, lumière bleutée) et aux ombres adoucies. Avec une même salle, on fait deux ambiance différentes.

L’ouverture dans le plafond m’a permis également de faire un effet assez courant avec un cône lumineux plein de poussières en suspension. Cela amène un côté marquant à la salle, mais également du mouvement (même s’il est léger). De plus, cet effet se voit de loin et pousse le joueur à aller voir ce qu’il y a  et à réfléchir ainsi à l’énigme plutôt que de seulement activer des boutons (ce que ne faisaient pas forcément les testeurs, se lançant sur le premier interrupteur venu).

Dernière chose pour ajouter à l’ensemble. L’ouverture dans la plafond m’a permis d’ajouter des feuillages qui accentuent l’impression d’abandon du lieu et qui ajoutent également du mouvement (un buisson étant soumis au vent).

version actuelle du puzzle
version actuelle du puzzle

Ambiance sonore

Une des premières choses qui choquent quand on joue à une version alpha ou beta, c’est le manque d’ambiance sonore. Il manque souvent de la musique, des sons d’ambiance ou des sons tout court ! Un joueur accepte mal qu’il fasse une action sans qu’un bruit, même mineure, ne lui confirme que son action est prise en compte. C’est vrai aussi bien quand il actionne un interrupteur que quand il essaie  de pousser une grille (même s’il voit une main s’activer à l’écran !) Ce genre d’aspect est relégué assez tard dans le développement car ce n’est pas l’aspect le plus essentiel dans le jeu et que les (bons) sound-designers sont rares. Pourtant, on connait tous des jeux qui nous ont marqué par leur ambiance sonore (F.E.A.R., Bioshock…) et d’autres qui nous ont au contraire paru ridicules à cause de leur doublage foireux et de leurs armes qui font moins de bruit qu’un pétard mouillé (Alpha Prime…).

Ici, au niveau sonore, il y a deux/trois choses à implanter (dont certaines ne le sont pas encore) afin de rendre crédible et compréhensible l’énigme. Par exemple, il est bon que quand la roue se mette à tourner, le joueur l’entende (au cas où il ne regarde pas là à ce moment-là). Voilà en gros le listing de ce qu’il faudrait implanter, dans le meilleur des cas :

  • Bruit de flamme intense pour la tuyère
  • Bruit de flamme léger pour les torches présentes
  • Bruit mécanique de la roue qui tourne
  • Bruit de l’eau stagnante
  • Bruit de l’eau qui coule
  • Bruit de l’eau qui rempli la fosse
  • Bruit de la herse qui se lève
  • Bruit de la herse qui a fini de se lever
  • Bruit de l’interrupteur qui s’active
  • Bruit du bout de bois qui explose
  • Bruit de la grille qui tombe

On voit qu’avec une seule énigme, pas mal de sons sont à trouver (et encore, j’enlève toute la partie relative au joueur : bruit de l’arme d’eau, de feu, du joueur qui marche, qui saute, qui se blesse, qui meurt, etc.). Il faut rajouter à cela qu’ils doivent avec une certaine spatialité (si le joueur est loin du son,il l’entend moins que si je suis à côté) et qu’il faut gérer les différents volumes sonores.

Je ne cache pas que, évidemment, d’une énigme à l’autre, certains sons sont récupérés…

En conclusion

J’ai passé ici toute la partie liée à la gestion des scripts (« si j’appuie là, ça fait ça ») qui n’est pas toujours simple à mettre en place. Cette gestion prend en compte autant les sons, les déplacements d’objets et les déclenchements d’évènements.

J’ai également décidé de créer un niveau prototype pour tester l’énigme avant de la complexifier ensuite. Le fait de ne pas avoir encore tout implanté dans le jeu au début du design (notamment la gestion des armes) m’a évidemment posé des problèmes et m’a pas mal ralenti. Evidemment, le mieux aurait été d’avoir mieux conçu l’énigme en amont, afin d’éviter de refaire certaines parties.

3 commentaires à propos de “Little God Story – DevBlog #3 (Level-Design)”

  1. Quand tu rentrera de vacance, ce qui sera intéressant de connaitre c’est la chronologie du développement.

    Quand t’es venus la première fois l’embryon d’idée sur le jeu ?
    Quand est-ce que tu as commencé/terminé un cahier des charges ?
    Est-ce que tu as passé du temps à chercher des technologies ou l’UDK était une évidence ?
    Quand est-ce que tu as réellement commencé à développé ?
    Combien de temps t’as pris la réalisation complète du niveau présenté dans ce dev blog ?
    Sortie d’une alpha, beta, ou démo prévus, si oui quand ?
    Sortie finale déjà envisagée ?

    Combien de temps tu y passe par jour ?
    Est-ce que tu as d’autres occupations importantes (travail, études) à coté de ça ?

    Etc…

    En tout cas continue comme ça, j’ai aussi un projet jeux (type Starship Tycoon amélioré) et même si il est très différent du tien, ça aide toujours de profiter de l’expérience d’autrui.

  2. J’adore ces petites histoires 🙂

    Mais les sons, pour la plupart, seront forcement réutilisé.
    L’univers ne devrait pas changer plus d’une fois [intérieur/extérieur] même ne connaissant pas le scénario [bon après tu peux faire des truc loufoques].
    Les pouvoirs sont les mêmes tout au long du jeu.
    Les élement aussi [ce qui rejoin en partie les pouvoir: Feu etc..]

    ‘fin j’dis ça à moitié pour t’encourager: Des herses, des flammes, de l’eau qui coule et qui stagne etc… tout ça, ça ne fera pas partie d’une seule énigme !

    En tout cas, j’vous souhaite bon courage, n’hésite pas à écouter les commentaires de Dev de Portal et de Portal Prelude [en Fr !] c’est super instructif pour les puzzle et les système de bouton par rapport au son joué et à la lisibilité de l’engrenage.

  3. Moi qui compte me mettre au développement aussi l’année qui vient. je trouve ton blog bien intéressant. (j’ai deja pris quelques notes d’erreurs a ne pas faire, tu les aura faite :p)

Laisser un commentaire

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

*