Little Blog Story

Game-Design & Modding le blog de belzaran.

Articles taggés avec ‘Game Design’

Un peu d’humour…

Mercredi 1 septembre 2010

Introduction

A l’heure actuelle, les gros blockbusters rivalisent de sérieux et de “maturité”. Au point que le jeu le plus vendu, Call of Duty : Modern Warfare 2 propose de massacrer des innocents… De plus, l’omniprésence des couleurs grises et marrons dans les graphismes next-gen leur donne un rendu toujours très sérieux et sombre. Pourtant, nombre de jeux passionnants se sont basés sur l’humour et ont acquis un statut de jeu culte grâce à un côté décalé et/ou humoristique (Duke Nukem 3D, Monkey Island, Fallout, Rayman…).

Dans tous les jeux/mods/maps que j’ai pu créés (ou essayés de créer), j’ai voulu ajouter une composante humoristique à la chose. Outre mon côté mutin, cela a souvent été une façon d’essayer de me différencier par rapport à la masse de projets plus sérieux et aux qualités graphique et technique  plus importantes. Une sorte de cache-misère en quelque sorte, mais pas seulement. J’ai alors souvent éprouvé une difficulté à intégrer ce côté humoristique à mes projets même lorsqu’ils étaient entièrement basés là-dessus. Petit tour d’horizon des moyens utilisés et des problèmes qu’ils ont posé et posent encore.

J’utilise ici des exemples de projets réels : ce sont des maps (de mods ou non) qui ont atteint un niveau avancé, bien qu’elles ne soient pas toutes publiées. Les composants humoristiques dont je parle ici ont tous été implantés concrètement dans une map.

L’humour est quelque chose d’assez personnel, les exemples donnés ici ne feront pas rire tout le monde, loin de là.

L’écrit

Bonjour les fautes dorthographe !

Bonjour les fautes d'orthographe !

Le moyen le plus simple d’implanter de l’humour est bien sûr l’écrit. On peut ainsi directement écrire une blague, un jeu de mot, une situation et introduire un côté décalé. L’écrit peut se manifester soit par des messages in-game (annonce d’objectifs par exemple), soit par des objets directement dans la map (pancarte, enseigne…).

Un des possibilité est d’utiliser les messages en jeu (par exemple pour annoncer les objectifs au joueur). Il est facile d’en ajouter et cela est peu contraignant techniquement. Cependant, pour que la composante humour soit assez présente, cela demande un renouvellement important des objectifs. Dans ma map Patator : Nevermind the Beach, voilà à quoi ressemblait les objectifs :

  • Essaie de trouver une meuf sur cette île
  • Il y a trop de mecs ici, descends les tous
  • Attention aux coups de soleil, reste dans la jungle

Un autre moyen est d’implanter directement des objets dans la map. Unreal Safari devant être un mod fun avant tout, j’avais prévu nombre de blagues que j’ai voulu implanter dans la map WAR-Gizeh. Ce fut un fiasco et les models furent même retirés. D’abord parce-qu’il n’est pas évident d’ajouter un texte à une texture. La compression a tendance à “écraser” le texte et à le rendre peu lisible. De plus, selon l’éclairage et la taille de l’objet, cela est assez difficile à lire. Dernier élément contre ce procédé : beaucoup de joueurs ne lisent pas un petit panneau avec un petit texte. Ma pancarte “interdit aux momies” prévu pour WAR-Gizeh fut donc éliminé…

Je passe rapidement sur le fait qu’ajouter des éléments écrits pose évidemment le problème de la langue. Actuellement, il paraît difficile de passer à côté de l’anglais. Or, faire de l’humour dans une langue qui n’est pas la sienne est beaucoup plus difficile (sans compter que les joueurs non-anglophones risquent de ne pas la comprendre !)

Le dessin

Une manière de rendre le tout plus facilement lisible et universel est d’utiliser le dessin plutôt que l’écrit. Evidemment, on passe ici à un humour différent (et donc qui peut être plus difficile). Ici, la barrière est la compétence pure à savoir dessiner et mettre en forme ce genre de choses. Pour reprendre l’exemple des momies de WAR-Gizeh, j’avais comme projet de faire un panneau d’interdiction avec une momie symbolisé dessus. Cependant, c’est bien plus compliqué à réaliser qu’à conceptualiser…

Ici également on va utiliser massivement les pancartes, panneaux et enseignes pour diffuser notre bonne parole. Le plus simple consiste en un panneau assez grand contenant un texte minimal et une image attirant l’attention. Dans le panneau du restaurant (Unreal Safari), la feuille de cannabis attire l’oeil du joueur afin qu’il lise le jeu de mot (“Hippopotatoes”) et la blague dessous (“Vegan food”)

LAK-Banana

Modification de skin pour blague vaseuse

L’univers

Le moyen le plus simple d’ajouter de l’humour est d’avoir également un univers complètement décalé. Dans Unreal Safari, le monde est complètement barré. Le pitch raconte que les animaux génétiquement modifiés sont devenus intelligents et ont abattus l’Homme grâce à une nouvelle source d’énergie incroyable : la banane transgénique. Cela se traduit par tout une somme de choses peu sérieuses comme l’utilisation de bananes comme chargeurs des armes… Ainsi, le joueur a une banane en permanence à l’écran devant lui.

Cependant, l’univers ne suffit pas. Patator : Nevermind the Beach possédait un background travaillé et sensé être drôle, mais il n’est pas toujours évident de parler de ce background directement dans une map, sans cinématique ou équivalent. En effet, le héros de Patator est un agent secret haute-saônois (70). Il est donc l’agent 070 (dire zéro-sept-zéro). Son revolver possède le signe de James Bond modifié, mais comment le joueur peut-il faire le rapprochement entre la blague (un peu lointaine) et le résultat sur le skin d’un pistolet ?

Les sons

Une façon de pallier aux problèmes de texte est de les remplacer dans des voix. Cependant, encore une fois la barrière de la langue s’impose, en plus de celle du doublage. Les tirades de Duke Nukem ont eu beaucoup de succès notamment grâce à la voix de Jon St. John. Ainsi, pour un développeur indé, vouloir doubler son jeu risque de poser des problèmes évident (sans compter l’accent, l’articulation, les moyens d’enregistrements…)

Le moyen le plus simple est de faire parler le joueur principal, soit dans les cinématiques, soit directement in-game. Les jeux sont un peu scindés en deux, entre les héros muets (Half-Life) et les plus bavards (Duke Nukem 3D, Prey, Far Cry…). Dans Little God Story, le héros parle beaucoup, commente ce qu’il voit et apporte un côté décalé à l’univers. Un exemple simple est que le héros arrive dans une tour et doit monter à l’étage en sautant de plateformes en plateformes. Il déclare alors : “T’ai-je déjà dit que je souffre de vertige ?”

Toujours dans Little God Story, il était prévu d’ajouter à chaque début de puzzle majeur une stèle, avec une expression reprenant le terme “Dieu” (exemples : “ni dieu, ni maître”). Une variante existait avec la même chose écrite sur le mur en lettres de sang. Little God, en entrant dans la salle, était sensé commenter la chose avec ironie. Cette idée, un peu artificielle, fut retirée du concept du jeu.

Patator : Nevermind the Beach avait également son lot de tirades solos prévues. Je vous en donne quelques-unes. Le tout est très (trop ?) inspiré de Duke Nukem :

  • Look at my big gun, baby !
  • What is this fuckin’ island with no chicks ?
  • A bullet in my head ? Nothing more than a hangover !
  • Why everyone is trying to kill me ?
  • My clip is empty, but my balls are full !

LAK-Banana

L'AK-Banana

Une autre façon d’ajouter de l’humour est le dialogue. Dès les premiers concepts de Little God Story apparaît un personnage, Voicy. Ce dernier est simplement une voix désincarnée (afin d’éviter d’avoir à le modéliser) qui parle à Little God. Le but de ce “personnage” est d’expliquer l’histoire, de servir de tutoriel et d’apporter de l’humour. En effet, Little God passe son temps à vanner Voicy et à commenter ironiquement les paroles de son compagnon de route. Ce procédé n’est pas nouveau mais le dialogue augmente les possibilités d’intégrer de l’humour. Au final, Little God Story mixera le tout : Little God parlera avec Voicy, mais saura également sortir une tirade tout seul sur l’environnement.

Vers un peu plus de subtilité…

Lorsque j’intègre une blague dans mes projets, j’ai une tendance à prendre un screenshot que je publie, comme si j’avais peur qu’in-game, personne ne le remarque. C’est une erreur, car beaucoup de joueurs sont sensibles à l’environnement et “visite” les maps au moins une fois avec l’oeil du touriste (moi le premier).

Dans WAR-Gizeh, une des grosses blagues de la map (et peut-être la seule qui a finalement été conservé pour la version finale) était un panneau de signalisation posté juste à la sortie du spawn des tanks. Il fut cité par nombre de joueurs qui apprécièrent le clin d’oeil. Pas de jeu de mot, juste un élément décalé dans un univers futuriste en guerre.

Dans Little God Story, le héros démarre l’aventure en prison. Afin de meubler un peu sa cellule, je me suis amusé à ajouter un pot de chambre pour que Little God puisse faire ses besoins. Le pot est dans un coin, visible mais discret. Un testeur a remarqué le pot de chambre et ça l’a fait sourire. Il a regretté ensuite que le pot ne soit pas plein…

Difficile de ne pas parler également des easter-eggs. Ceux-ci sont souvent destinés aux initiés (la campagne “I hate mountains” pour Left 4 Dead comporte pas mal de représentation d’avatars des créateurs, encore faut-il connaître les créateurs !), mais peuvent également servir à des fins humoristiques.

Conclusion

L’humour est une composante marquante dans le jeu vidéo qui peut permettre à un jeu de s’élever à un niveau supérieur. Il peut également être un facteur irritant, mais l’humour est souvent bien accepté par les joueurs, même quand il est moyen, car il constitue un composant supplémentaire du gameplay. Ainsi, si je ne suis pas séduit par le second degrés de Borderlands, il ne me gêne pas plus que ça.

Cependant, implanter de l’humour de façon subtile est difficile, surtout si l’univers n’est pas si décalé que ça. Dans Bisounours Party, l’équipe a pu se lâcher car le mod et son univers sont complètement déjantés.

Dans cet article, une réflexion sur les choix effectués en terme de HUD pour Little God Story. Comme d’habitude, beaucoup de changements ont eu lieu entre le début et l’état actuel des choses. Comme je pense avoir atteint un équilibre suffisant, il y a peu de chance que l’état actuel du HUD évolue fortement dans la suite du développement.

Mes choix ont été fortement influencés par les tests et donc par les testeurs. Merci à eux pour leurs idées qui permettent de rendre le jeu meilleur.

Le premier HUD purement utilitaire

Le premier HUD purement utilitaire

Introduction

Le HUD (Head up display) est un élément que l’on pourrait croire essentiel dans un jeu vidéo. Il affiche les points de vie, les munitions restantes, les points d’Xp ou plein d’autres choses encore. Un véritable changement s’est effectué ces dernières années. Certains jeux tentent de le supprimer le plus possible ou de l’intégrer au monde afin d’augmenter l’immersion (Far Cry 2, Metro 2033), d’autres persistent à en faire quelque chose d’envahissant (Borderlands avec ses messages explicatifs qui te cachent la moitié de l’écran pendant que tu vises).

En tant que développeur, je tiens à dire que le HUD est une façon facile de personnaliser un jeu/mod. Dès qu’on le change, l’impression de jouer à un jeu unique se renforce. Cela peut aller d’un simple texte (”XP = 325/640″) à une refonte graphique complète. Ainsi, pour un développeur, faire un HUD minimaliste, c’est difficile psychologiquement. Cela enlève une possibilité simple de donner une patte graphique à son jeu.

Dernier élément essentiel : le public visé. Comme je l’ai dit dans un précédent article, certains testeurs (dont moi) ont fait tester le jeu à des publics plus casuals (féminins et/ou enfants). Il est évident que le HUD choisi influencera fortement l’accessibilité du jeu. Ce choix n’est pas si évident, car Little God Story ne propose pas de combat et beaucoup de réflexion. En cela, il est tout à fait possible de l’orienter vers le casual gaming. Cependant, le jeu étant prévu sur PC, il paraît évident que les gens qui y joueront seront des joueurs assidus, adeptes de jeux indépendants !

Concept du HUD

Le premier HUD personnalisé

Le premier HUD personnalisé

Avant de commencer à créer le HUD de Little God Story, j’ai créé un prototype qui devait me permettre simplement de vérifier que le code fonctionnait. Le premier HUD m’affichait l’Elément en cours avec un texte de couleur correspondante. Il a fallu ajouter ensuite une simple barre de vie, de mana et de munitions (chaque barre étant d’une couleur différente !).

Le problème du HUD, c’est qu’il sous-entend que le concept du jeu doit être finalisé un minimum avant de s’y attaquer. En effet, tout changement majeur dans le gameplay peut induire d’introduire de nouveaux éléments ou de les supprimer. Dès la deuxième version de test, j’ai ainsi du ajouter la barre de mana. Avant le mana n’existait simplement pas… J’ai donc établi une liste de ce que le joueur aimerait bien pouvoir savoir à chaque moment :

  • L’élément actuellement utilisé
  • Les points de vie
  • Le Mana

Cela peut paraître peu, mais il n’y a rien de plus dans Little God Story. En effet, le Mana sert aussi de munitions et il n’y pas de carte à afficher (étant très linéaire). Je ne parle pas ici de certains concepts non-finalisés que le joueur peut afficher ou voir ponctuellement :

  • Résumé du tutoriel (aussi appelé Journal)
  • Affichage de l’objectif en cours
  • Messages divers et variés qui s’affichent à l’écran

En effet, ces informations ne sont pas utiles en permanence à l’écran. Certes, l’objectif pourrait être affiché tout le temps (comme dans Borderlands) mais ce serait occuper une partie de l’écran pour rien. Concernant le tutoriel et les messages, rien n’est finalisé actuellement. J’y reviendrai plus tard, quand tout sera beaucoup plus avancé.

Dernière chose : l’arme utilisée fait entièrement partie du HUD puisqu’elle peut afficher des informations également (les munitions sont directement affichées sur l’arme dans Doom 3, la jauge d’air comprimé dans Metro 2033…). Cela facilite fortement l’immersion.

Premières moutures

Lors des premiers tests, les joueurs connaissent mal le jeu. Il n’y a pas ou peu du tutoriel, les niveaux sont parfois bancals et les idées d’énigmes mal faites. Bref, faire un HUD intuitif n’est pas la meilleure chose à faire. Ainsi, la première mouture un peu personnalisé du HUD de Little God Story contenait une barre de vie rouge, une barre de mana bleue et un logo de l’élément utilisé. Les codes couleurs classiques sont utilisés afin de ne pas perdre le joueur. Enfin, l’élément est symbolisé par un logo afin d’aider le joueur à comprendre le jeu. En effet, il existe quatre interrupteurs différents dans Little God Story reliés à un élément. Le logo du HUD renvoie ainsi directement au logo de l’interrupteur, expliquant implicitement au joueur le lien entre les deux.

Cette version n’a pas posé de problème pratique aux joueurs. Les informations étaient facilement accessibles. Certains se sont plaints d’un logo d’élément trop envahissant (qui fut réduit pour la version suivante). Cependant, cette version était assez efficace, bien qu’assez moche. Le côté très coloré contrastait trop avec l’aspect sombre du jeu. De plus, Little God Story veut se doter d’une ambiance forte, à la fois sombre et mélancolique. Avec un HUD discret, cela est beaucoup plus simple à réaliser.

Le crosshair renvoie au graphisme de lélément utilisé

Le crosshair renvoie au graphisme de l'élément utilisé

En recherche d’immersion

Les derniers tests, plus pointus, m’ont amenés à rechercher plus d’immersion (au détriment d’un apprentissage plus intuitif). En effet, le changement d’élément se traduit par un changement visuel à l’écran et dans les déplacements. Les joueurs ont ainsi signifiés qu’ils n’étaient que rarement perdus, ils savaient dans quel élément ils jouaient. De plus, la main du joueur (qui sert d’arme) changera selon l’élément (en flammes pour le mode feu, semi-transparente en mode air…) et donnera ainsi automatiquement l’indication au joueur. On peut donc enlever le gros logo qui n’est donc plus nécessaire. Une autre indication sert également à signifier l’élément : le crosshair. Ce dernier a un design qui rappelle l’élément utilisé. Ainsi, peu de risque que le joueur soit perdu.

La barre de vie disparaîtra également, remplacé par les effets classiques vus dans les jeux actuels. En effet, les tests ont montré qu’il était rare dans le jeu que les joueurs soit blessés. L’erreur équivaut souvent à la mort dans Little God Story. Résultat : si un joueur se blesse, sa vie revient petit à petit (ce qui est cohérent avec le fait que le joueur est censé être un dieu !). La notion de barre de vie peut donc sauter.

Reste la barre de mana. Je remercie ici un testeur en particulier qui m’a donné l’idée : le curseur disparaît petit à petit quand le mana s’épuise. Cet effet, facile à implanter, est très visible. Il permet au joueur de voir son mana disparaître. Et comme il est situé au centre de l’écran, il est beaucoup plus simple à voir.

Au final, le HUD de Little God Story est discret : un simple curseur blanc et la main du joueur sont affichés à l’écran. Il est certain que cela est possible qu’avec l’avancée d’autres domaines :

  • personnalisation de la texture et du matériel de la main selon l’élément utilisé
  • ajout d’effets graphique qui permettent de mieux ressentir l’élément avec lequel on joue
  • ajout de sons personnalisés lors du changement d’élément
  • ajout de messages lorsque le Mana est épuisé

Si je suis arrivé à accepter d’avoir un HUD moins présent et donc de moins personnaliser graphiquement ce même HUD, c’est aussi parce-que le jeu en lui-même a une patte graphique plus affirmée. A partir du moment où le jeu semble présenter un aspect plus personnel (par les armes à l’écran, les interrupteurs, l’ambiance…), le HUD peut redevenir un élément d’immersion et non plus uniquement une façon d’imposer sa patte graphique.

Le HUD actuel, beaucoup plus discret

Le HUD actuel, beaucoup plus discret

Je me permet de faire une petite digression sur Unreal Safari. J’avais commencé à travailler sur le HUD que je voulais très africain et délirant. J’avais ainsi mis des fruits (kiwis, oranges) et des feuilles de bananiers. Je vous invite à lire le post que j’avais laissé sur WeFrag et les remarques qui avaient alors été faites : http://www.wefrag.com/forums/entre_aide/topics/138233

Unreal Safari : un HUD flashy !

Unreal Safari : un HUD flashy !

Making-Of : Hunt (2)

Mardi 24 août 2010

J’ai commencé à programmer le mode Hunt pour Unreal Tournament III. Le plus gros problème de départ a été de configurer UT3 pour qu’il compile le code créé et que cela fonctionne in-game (si en soit, l’Unreal Script a peu changé entre UT3 et l’UDK, la façon dont ces deux logiciels le compile est légèrement différentes). J’ai alors rapidement programmé un embryon de gameplay que je suis allé testé. Les mauvaises surprises n’ont pas tardé !

Etat actuel du projet

Actuellement, un joueur démarre avec 200 points de vie et une vitesse ralentie. Lorsqu’il réussit un frag, il passe à 75 points de vie, une vitesse et un saut doublé. Le système de score (plus je reste longtemps en cible, plus je marque des points) n’est pas encore implanté. Actuellement, j’ai le choix de n’avoir aucune cible réelle ou la possibilité d’en avoir plusieurs en même temps. Je n’ai pas encore bloqué le fait qu’il n’y ait qu’une seule cible à la fois.

Le début de partie

Le début de partie est évidemment le problème majeur à régler au départ. Comment choisir la cible ? Mon code actuel dit que si l’on tue la cible, on devient cible. Pas de problème, ça fonctionne. Sauf qu’avec ce code, il faut une cible au départ. Ici, ce n’est pas le cas.

Plusieurs solutions s’offrent à moi. La première serait de choisir un joueur au hasard ou de prendre le premier connecté. Hors de question étant donné que cela donnerait un avantage à quelqu’un sans une bonne raison. La deuxième possibilité est de modifier le principe du « First kill ». En effet, quand la première personne est fraggué sur UT3, un ‘announcement’ signale qu’il a eu lieu et qui l’a fait. Il suffirait alors de mettre une ligne de code afin de faire devenir la cible le joueur qui a réussi le frag.

Je pensais fortement aller dans cette voie quand j’ai songé à un problème que je n’avais pas imaginé : que se passe-t-il si la cible quitte le serveur ? Afin de pallier à ce problème (et à tous les autres), il faut que je programme une fonction qui récupère les données de tous les joueurs afin de voir s’il y a une cible. Cette fonction pourrait ainsi permettre :

  • De signaler aux joueurs s’il n’y a pas de cible (dans ce cas-là, on peut fragguer tout le monde)
  • De pallier au problème du lancement de la partie (sans cible)

Les bots

UT3 étant un jeu déserté actuellement, j’ai peu d’espoir de voir mon mode de jeu joué sur de nombreux serveurs. Il est ainsi essentiel qu’il soit jouable avec des bots. Or, en supprimant la notion qu’équipe (comme signalé dans le précédent article), je perturbe les bots. Ceux-ci continuent à jouer comme en Deathmatch, ignorant les règles nouvelles. En cela, c’est un problème énorme car je n’y connais absolument rien en programmation d’IA. C’est l’occasion de m’y lancer, mais le projet que j’imaginais simple devient d’un coup bien plus ardu. Certes, il me reste la possibilité de publier un mode de jeu jouable uniquement entre humains, mais je perdrais l’occasion de le faire tester au préalable (voir tester tout court).

Etant donné l’absence d’avancées significatives et d’un prototype fonctionnel, je ne publie pas encore le code actuel du projet.

Dans cet article, une réflexion sur les fameuses jauges de Mana. Pourquoi on les déteste et pourquoi elles sont aussi essentielles…

Qu’est-ce que le Mana ?

Le Mana (même s’il ne porte pas toujours ce nom) est une jauge permettant de limiter l’usage de magie dans les jeux vidéo. En soit, c’est l’unité de munitions des armes magiques. Quand il vous reste un chargeur pour une AK-47, il vous 10 points de Mana pour votre sort d’invisibilité. Cependant, le Mana étant par essence même inexistant dans le monde réel, il est beaucoup plus souple qu’une munition basique. En effet, il arrive qu’il se recharge petit à petit si on ne l’utilise pas (ce qui existe aussi pour certaines armes futuristes dans des jeux de science-fiction) ou en ingurgitant une potion. De même, certains pouvoirs, bien que passifs, utilisent quand même du Mana.

Le Mana se retrouve donc souvent dans les jeux moyenâgeux incluant un aspect RPG et/ou magie (Diablo 2, Dark Messiah of Might and Magic…). Un type de jeu qui décrit parfaitement Little God Story…

Pourquoi le Mana dans Little God Story ?

Little God Story est basé sur l’utilisation des 4 éléments. Chacun a des bons et des mauvais côtés et certains éléments se neutralisent entre eux. Rapidement, j’ai compris que certains aspects allaient poser problème. En effet, quand le joueur est en mode Feu, il va très vite (c’est la base de certaines énigmes). Il paraît évident que 90% des joueurs allaient passer le jeu en mode Feu pour aller plus vite et donc ne pas profiter des environnements (et surtout réduire de façon drastique la durée de vie du jeu).

Afin de rendre le tout cohérent, j’avais décidé que quand le joueur serait en mode Feu, il se consumerait. Cette idée m’était venu de Prince of Persia : The Two Thrones. Dans le jeu, quand le prince se métamorphose en son double noir, il devient bien plus puissant mais il se consume et perd des points de vie s’il ne tue personne. Ainsi, quand les joueurs utiliseraient le mode Feu, ils seraient pénalisés par la perte de points de vie.

Ce fut un fiasco retentissant et ce pour plusieurs raisons. Un joueur n’accepte simplement pas de perdre des points de vie sans avoir fait une erreur. Cela ne rentre dans les codes des jeux vidéo. Quand on passe une épreuve en étant blessé, on est toujours certain qu’il y avait un autre moyen qui, lui, n’aurait pas fait baisser notre santé.

L’autre raison, plus gênante encore, est que si le joueur perd des points de vie en utilisant le mode Feu, la possibilité de rater une épreuve et de devoir la recommencer devient moins évidente. Le droit à l’erreur disparaît dans un maelström booléen : je réussis ou je meurs. Là encore, ce principe a révolté les testeurs.

La première solution qui m’est venu à l’esprit était que les points de vie se régénèreraient au bout de quelques secondes. Outre que ce système est utilisé dans plein de jeux et que je déteste ça, il pourrait être facilement détourné. Au lieu de traverser un incendie en mode Eau pour ne pas être blessé (système lent), le joueur pourrait décider de traverser en mode Feu (système rapide), quitte à être blessé. Ses points de vie reviendraient alors petit à petit…

De plus, le mode Air (qui permet de sauter plus haut) possède également une vitesse plus élevée (pour pouvoir sauter plus loin). Résultat : je passais mon temps à explorer Little God Story en mode Air, beaucoup plus agréable que le mode Terre. Il était plus que temps de coder un système de Mana.

Le système de Mana de base

Avant même de parler d’équilibrage, il faut penser le système de Mana avec deux questions essentielles :

  1. Qu’est-ce qui me fait perdre du Mana ?
  2. Qu’est-ce qui me fait gagner du Mana ?

Les solutions sont évidemment multiples. Etant donné que le gameplay est basé sur les quatre éléments, il me paraissait évident d’utiliser un élément pour la récupération du Mana :

  • Feu : consomme beaucoup de Mana
  • Air : consomme un peu de Mana
  • Terre : aucun effet
  • Eau : redonne du Mana

les différents effets à lécran selon lélément utilisé

les différents effets à l'écran selon l'élément utilisé

Ainsi, tout est hiérarchisé avec un logique inverse à la vitesse déplacement. Plus le joueur va vite, plus il consomme du Mana (et inversement). Ici, le système est relativement simple et fonctionne aussi bien en mode actif que passif. Le joueur, même s’il ne se déplace pas, utilise du Mana en mode Feu ou Air. Ainsi, une bonne gestion du changement d’élément permet d’éviter de trop en consommer. Ainsi, le skill, même limité, fait son apparition dans Little God Story. En jouant, on se surprend à passer en mode Air juste avant de sauter et de repasser en mode Terre à peine décollé du sol. Le Mana avait apporté une dimension que je n’avais pas imaginé.

Evidemment, il y avait également une frustration évidente liée à ce système. Dans les premières versions, l’indication visuelle de l’élément utilisé était un simple mot dans un coin de l’écran. Il arrivait régulièrement que l’on oublie que l’on était en mode Air, consommant toute la jauge de Mana… Ceci a été corrigé par un aspect visuel différent selon l’élément utilisé (le tout par des effets post-process ou l’ajout d’une lumière en mode Feu).

L’équilibrage

Je précise avant de continuer que l’équilibrage du Mana dans Little God Story est encore en cours. L’ajout actuel de nouvelles features vont m’obliger à adapter la jauge. Cependant, il est à prendre en compte que l’équilibrage n’est jamais parfait : certains joueurs considèrent le Mana comme un élément de gameplay important et essentiel, d’autres sont prêts à tout pour vous convaincre de la supprimer (ou presque). Je vais donc ici parler des questions qui me taraudent. N’hésitez donc pas à donner votre avis sur la question en commentaire.

Il y a trois aspects sur lesquels le Mana peut influencer :

  1. Je suis en mode Air
  2. Je saute en mode Air
  3. J’utilise l’arme d’Air

Actuellement, chaque aspect consomme autant de Mana. Il n’y a aucune hiérarchie. Être en mode Feu consomme deux points de Mana à la seconde, points barre. La possibilité d’étager la consommation (être en mode Air fait baisser très légèrement le Mana, utiliser l’arme ou sauter beaucoup plus) est une idée séduisante, mais elle supprimerait une notion importante : je change d’élément parce-que je veux faire telle chose précise. Et pas uniquement parce-que j’ai envie d’essayer de plonger dans l’océan pour voir si le développeur a prévu le coup.

Une possibilité que j’avais d’abord envisagée était d’avoir deux jauges de Mana : une active (pour les armes) et une passive (pour le reste). Ce système permettrait de rester plus longtemps dans un élément donné mais l’utilisation des armes demanderait un minimum de parcimonie. J’attendrai les prochains tests (et donc des avis extérieurs) pour me décider là-dessus.

Reste la régénération du Mana. Dans le dernier test, c’est le mode Eau qui régénère le Mana. Comme en mode Eau, on ne peut pas faire grand chose (vitesse et saut limités), c’est forcément un peu frustrant. Mais bien sûr, c’est voulu. Si régénérer son Mana n’est pas pénalisant, quel intérêt ? Actuellement, j’ai ajouté une régénération très lente en mode Terre. Bien que limitée, elle permet que quand le joueur observe le monde, son mana revienne un petit peu (sur certaines énigmes, c’est très efficace).

Une autre possibilité envisagée est que si le joueur se déplace dans de l’eau (fontaines, rivières…), son mana revient très vite. Ce serait assez cohérent, le Mana étant lié à l’eau. De plus, l’eau faisant partie de nombreuses énigmes, cela permettrait au joueur d’avoir un moyen simple et rapide de récupérer son Mana. Certains testeurs ont tiqué quand j’ai annoncé mon intention d’implanter ceci : selon eux, ça rendait le jeu beaucoup plus facile : le fait de gérer son Mana (et donc de ne pas foncer et tester n’importe quoi) fait partie intégrante de Little God Story qui est avant tout un puzzle-game. Le côté “je veux pouvoir lancer des boules de feu tout le temps” est certes jouissif, mais pas vraiment adapté à la philosophie du jeu.

Une dernière possibilité est l’utilisation de fioles. C’est actuellement la solution qui me paraît la plus adaptée. En effet, à certains checkpoints, le joueur gagne une fiole qui peut lui permettre de regagner du Mana ou de passer en mode “Mana infini” un certain temps. Ce système atténuerait la frustration en donnant la responsabilité au joueur ou non de l’usage de sa fiole. Un peu comme quand on bourrine dans un FPS en visant à l’arrache et qu’on se retrouve sans munitions (c’est du vécu sur Métro 2033). Ceci permettrait également de limiter la linéarité du jeu en ajoutant une recherche de fioles, soit avec des énigmes mineures dans des salles annexes, soit avec des passages secrets (soit les deux bien sûr). Evidemment, on pourrait ajouter ce système pour la santé également. Je ne cache pas que rien que d’en parler je suis à la fois excité et angoissé. Ce genre de système apporte un paquet de problème à gérer (notamment sur les sauvegardes) mais en résoudrait un paquet, notamment au niveau du level-design. Ajouter des pièces annexes à fouiller rend un jeu plus crédible. Je passe dans une chambre, il y en a d’autres à côté (et pas que des portes fermées qui suggèrent qu’il doit y en avoir d’autres…).

Petite digression : l’utilisation des fioles m’est venue pendant que je rédigeais cet article. En écrivant mes réflexions et mes problèmes sur ce fameux Mana, cela m’a permis de trouver de nouvelles possibilités. Je conseille donc à tout développeur de faire un DevBlog !

Conclusion

J’espère vous avoir convaincu avant tout que le Mana, dans Little God Story, est essentiel. Sans lui, le jeu perdrait de son essence même. Certes, le Mana est frustrant, mais jouer à un FPS avec des munitions infinies n’a que peu d’intérêt. Se retrouver avec un flingue merdique, dix balles dans le chargeur et trois monstres qui vous sautent dessus, c’est pour moi la définition d’un jeu réussi (oui, j’avoue, j’aime S.T.A.L.K.E.R.).

http://www.moddb.com/games/little-god-story

Little God Story : DevBlog #1

Mercredi 28 juillet 2010

La génèse du projet

Avant de démarrer cette série d’article sur mon projet actuel, Little God Story, je tiens à préciser deux/trois choses afin qu’il n’y ait pas d’ambiguïté sur mes intentions. Ce devblog n’a pas pour but premier de faire la promotion de mon jeu, mais d’expliquer ce qui a guidé certains choix de game-design. Un jeu est une entité qui part d’un point de départ, avec certains objectifs, mais cela reste très changeant. Je vais ici parler de choix de game-design déjà effectués et validés par des tests extérieurs. Dernière chose : le début de ces articles démarre exactement là où mon post-mortem d’Unreal Safari se terminait. Je vous conseille la lecture de ce dernier pour bien comprendre les choix suivants.

Exil

Après une expérience en solitaire de près d’un an et demi sur Unreal Safari, j’arrivais au bout de ma motivation. Cherchant à intégrer une équipe pour un mod/jeu solo, je profitais du fait qu’Exil migre sur l’UDK pour postuler. Embauché en tant que mappeur, je me faisais plaisir en modélisant un monde médiéval sombre aux ombres tranchées. Cependant, Exil ne mit pas très longtemps à capoter. Je pense qu’il est important que je précise un petit peu ce qu’est réellement ce jeu.

Exil est un jeu en vue à la troisième personne. Au moment où j’intègre l’équipe, Exil est une sorte de clone de Prince of Persia (tendance les Sables du Temps). Si le monde diffère légèrement (plus médiéval qu’oriental) même le roi, Enklave, ressemble à s’y méprendre au prince de perse. Dans le cahier des charges, seul la notion de cristaux diffère du jeu original.

Lorsque j’ai commencé à mapper, le but était de rechercher une ambiance dans le but d’attirer le codeur (comme pour beaucoup d’équipe). Malheureusement, j’ai vite souffert du manque de programmation dans l’équipe. Sans un embryon de gameplay, difficile de faire quoi que ce soit. Mes premières demandes furent pour des choses bêtes : à quelle hauteur peut sauter Enklave ? Sur quelle longueur ? A quelle vitesse va-t-il ? Rapidement, je me suis lassé de mapper “pour mapper” et non pas pour du gameplay. Je n’ai jamais été intéressé par le mapping pur, j’ai toujours aimé le côté level-design qui est pensé avant tout par rapport à un joueur.

Nous avons alors eu une discussion avec Froyok, chef de projet, afin de définir précisément le gameplay d’Exil et d’essayer de le différencier un peu de Prince of Persia. L’idée était d’opposer cristaux et eau. J’avais alors comme idée que le personnage pourrait se transformer en cristaux et accroître ses performances (hauteur de saut, vitesse…). Le problème c’est que dans ce mode, il serait vulnérable à l’eau. Je voyais alors un gameplay où Enklave se transformerait en cristaux pour sauter plus loin mais devrait, en vol, redevenir normal pour traverser le filet d’eau qui le sépare de la plateforme suivante…

Cette idée n’a pas été retenue pour le gameplay d’Exil, mais j’ai senti qu’il y avait quelque chose à creuser. En attendant d’avoir un prototype de gameplay pour mapper pour Exil, j’ai travaillé ce concept en l’étendant aux quatre éléments. Plutôt que de n’avoir qu’une combinaison cristaux/eau, je multipliais les possibilités de gameplay avec terre/air/eau/feu. Pour traverser du Feu, il faut être en Eau. Mais pour sauter haut, il faut être en Air, etc. Rapidement, j’ai pu développer pas mal de combinaisons possibles. C’est pour cela qu’au départ, Little God Story est un jeu avant tout de plateforme en vue à la troisième personne. Au final, le concept évoluera beaucoup. Mais contrairement à Unreal Safari, j’ai pris le temps d’asseoir mon gameplay avant de démarrer quoi que ce soit.

Deux semaines plus tard, Exil s’interrompait (le projet a plus ou moins repris depuis). Le travail en équipe n’avait pas été productif et ne m’avait montré quasiment que des désavantages. Mon concept de jeu semblait assez solide et prometteur. C’était un jeu solo, linéaire et dans une ambiance qui me plaisait. Je commençais alors à travailler plus sérieusement sur Little God Story. En solitaire.

http://www.moddb.com/games/exil

http://www.moddb.com/games/little-god-story

pageTracker._initData(); pageTracker._trackPageview(); } catch(err) {}