Sanguelia, Level 4 : L’hôpital et ses fantômes

le premier niveau (inachevé) de Sanguelia

⇐Retour au Level 3

L’interface et les éléments de base définis, je me suis penché sur le level design. Je sais que l’aventure doit commencer par la morgue de l’hôpital de L’Au-delà, qui offre un bon point de départ : la résurrection des premiers morts-vivants – où trouve-t-on des cadavres en milieu urbain à part une morgue ou un cimetière ? Du coup, je veux ménager leur apparition, avec au départ des cuves d’acide comme « simples obstacles ». J’ai vaguement dessiné le tableau sur mon carnet, même si j’avais déjà l’architecture générale en tête. Je savais où placer les items, notamment le premier crâne qui nécessite de rebondir sur un zombi, mais au retour, une fois que les morts-vivants sont apparus. Comme ça, dès le début, le joueur sera obnubilé par ce bonus trop haut pour être atteint d’emblée. Même si je vais devoir me faire violence pour que chaque monde soit constitué d’un certain nombre de tableaux, j’ai essayé d’optimiser au maximum, de placer le plus d’objets cachés dans un seul écran. Malgré le format cinémascope, chaque tableau est vite parcouru même si je pourrais par la suite caser de trois à quatre étages par niveau au besoin, si on n’a pas besoin de sauter trop haut.

La difficulté du level design, particulièrement pour un premier niveau, est de guider le joueur de manière naturelle, presque inconsciente. L’avantage d’un jeu 2D, c’est que le joueur a au moins le réflexe d’avancer, même si dans l’absolu il n’en a pas besoin. Mais avec la porte qui se referme derrière lui et la clé apparente à l’étage, ça devrait le faire. De même, je joue sur la position des lampes pour suggérer la présence éventuelle d’un coffre caché au rez-de-chaussée. Au pire, l’échelle invisible au bout du premier couloir enfoncera le clou. Le seul souci, c’est qu’il n’est pas nécessaire d’allumer la lampe-torche pour grimper à l’échelle, et le joueur pourra se mettre à escalader sans faire exprès, et sans découvrir la mécanique associée, au risque de croire qu’il s’agit d’un bug. La facilité consisterait à faire apparaître un petit « prompt » pour signaler au joueur le bouton pour allumer la lampe. Après tout, j’ai prévu des petits mini-jeux à base de matraquage de bouton par la suite. Mais au-delà de ce problème, il y en a un plus général qu’il est important de résoudre ; faut-il que les coffres cachés soient visibles – et donc éclairés – pour être ouverts ? Il y a du pour et du contre.

Manette Xbox 360

Sans le plugin XNA, les logiciels ClickTeam ne reconnaissent que le stick gauche et les quatre boutons de face

Pour moi, il faut qu’ils soient visibles, car sinon on pourrait les ouvrir sans faire exprès ; mais il y a deux contre-arguments. Le premier, c’est que cela nécessitera d’appuyer sur deux boutons simultanément (poing + lampe) et hélas, The Games Factory 2 ne gère que les boutons de face de la manette – un bouton de tranche serait préférable pour la lampe. Le second, c’est que cela crée une incohérence avec l’échelle. Le problème, c’est qu’autant un objet actif – qu’on peut faire apparaître ou disparaître – peut faire office d’obstacle, et donc de mur ou de plateforme, autant il ne peut pas servir d’échelle ; il faut forcément un élément de décor. Tout ce que je peux faire, et que j’ai fait, c’est avoir une échelle noire « recouverte » par un objet actif avec le visuel de l’échelle qui apparaît ou disparaît. Mais du coup on pourra toujours grimper. De toute façon, vu que la jauge de batterie se vide rapidement, obliger le joueur à maintenir allumée la lampe pour escalader une simple échelle serait laborieux. Et je n’ose pas imaginer une séquence où il faudrait sauter sur des plateformes invisibles, d’autant que dans la config’ actuelle, les boutons de saut et de lampe ne sont pas à côté…

Et en réfléchissant bien, ça reste logique. Si vous êtes sur une échelle ou une plateforme et qu’on éteint la lumière, vous n’allez pas tomber ! En revanche, ouvrir un coffre dans le noir peut s’avérer délicat. Et puis j’aurais aussi des parois « magiques » qui disparaissent quand on les éclaire ; comme pour les coffres, c’est plus logique d’avoir à maintenir la lampe allumée et ça évite de trouver des passages secrets involontairement. Cela règle la question selon moi, mais il reste le problème de l’échelle ; peut-être que si elle ne touchait pas le sol et qu’il fallait sauter pour l’atteindre, le joueur ne pourrait pas y grimper sans l’avoir vue au préalable en allumant sa torche… Et effectivement, j’ai découvert bien plus tard, en reprenant un peu le jeu fin 2013, qu’il suffit d’élever un tout petit peu l’échelle pour qu’on ne puisse pas grimper à même le sol – alors qu’elle touche quand même le visage de l’héroïne. Ainsi, elle suffisamment basse pour être bien perçue quand on allume la lampe. Parce qu’il ne faut pas oublier que le joueur qui ne connaît pas le jeu n’a pas la moindre idée d’où elle se trouve, et doit donc la faire apparaître facilement en allumant sa lampe dans le coin.

Éclairer l'échelle la fait apparaître

Éclairer l’échelle la fait apparaître

Un autre problème concerne les variables du jeu. Même si je n’ai qu’un seul tableau pour le moment et que je n’ai pas encore besoin de transférer les infos d’un niveau à l’autre, il faut y penser. Mais surtout, j’ai vite constaté qu’en cas de mort, lorsque le niveau recommence, toutes les variables locales sont réinitialisées. À l’époque de Klik & Play, c’était un vrai casse-tête car le score et les vies constituaient les seuls compteurs globaux, mémorisés d’une scène à l’autre. Il fallait alors tricher en créant trois autres joueurs fictifs, même dans un jeu solo, afin d’avoir quelques compteurs en plus… Au départ, pour ne pas multiplier les compteurs, je pensais utiliser les valeurs modifiables du protagoniste, et le définir comme objet actif global – ce qui conserve les valeurs d’une scène à l’autre. Hélas, elles sont aussi réinitialisées chaque fois que le niveau redémarre, et ça risque de poser problème si je veux utiliser d’autres objets actifs par la suite. Car même si le logiciel permet aujourd’hui de définir plusieurs types de mouvements par objet actif, je peux avoir besoin, par exemple, d’un sprite qui nage, donc avec des animations différentes pour les niveaux sous-marins. Le mieux est donc de créer des valeurs globales via les propriétés générales du jeu.

Ce faisant, j’ai identifié un autre problème avec le score qui fait office d’argent dans le jeu, même si je ne sais pas encore s’il servira à acheter des objets entre les niveaux. Paradoxalement, sa nature globale est un problème, parce que lorsqu’un niveau redémarre, certains bonus comme l’argent réapparaissent, ce qui permet au joueur de faire du farming ! Je suis donc obligé de dédoubler mon score, ce qui n’est pas simple parce que l’option « créer », située entre « cloner » et « dupliquer », ne fonctionne qu’avec un objet actif ou un décor. Il me faut donc copier, chiffre par chiffre, ma jolie typo façon Spectrum en italique dans un nouveau compteur qui fera office de score temporaire. Fixé au départ à la valeur du score actuel, il se réinitialisera de lui-même à chaque game over et, en fin de niveau, le score se mettra à jour avec cette nouvelle valeur. C’est le genre de petit détail facile à régler, mais qu’on a vite fait d’oublier et qui peut déséquilibrer le jeu. Et comme les vies sont infinies, permettre au joueur de garder son argent à chaque mort serait une grave erreur de design !

À bientôt pour le Level 5 intitulé « Optimisations et trans-fusions » !

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.