Little Blog Story

Game-Design & Modding le blog de belzaran.

Archive pour la catégorie ‘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.

Making-of : Hunt

Mardi 17 août 2010

Introduction

Little God Story est un projet passionnant mais particulièrement long à mettre en place. Ayant été habitué ces dernières années à publier du contenu régulièrement (maps, mutator, game type…), je me sens quelque peu frustré par cet aspect-là du développement. Ayant progressé fortement en programmation suite à mes travaux sur Little God Story, j’ai décidé de programmer un game-type pour Unreal Tournament III  : Hunt. Ce game-type était prévu pour Unreal Safari à l’origine (cf le post-mortem consacré au mod). J’ai décidé de le développer tranquillement et de publier ici les différentes avancées, sous forme d’un making-off. Quand j’aurais terminé (si je termine), je publierai les sources annotées pour aider les personnes souhaitant de mettre à l’UnrealScript.

L’idée ici est d’aller vite. Il n’est pas du tout prévu de développer des maps pour ce game-type ou de reprendre le développement d’Unreal Safari.

Concept du mode

Le mode Hunt est assez simple dans son fonctionnement. Un joueur est la cible. Tant qu’il n’est pas tué, il accumule des points. Quand il est fraggé, le tueur devient la cible et ainsi de suite. Il me semble que ce mode existe déjà dans plusieurs jeux mais je suis bien incapable de dire lesquels. N’hésitez pas à combler cette lacune culturelle dans les commentaires…

Une autre particularité (héritée d’Unreal Safari) est que la cible est très fragile. Elle a peu de points de vie mais court vite et saute très haut, pouvant prendre des raccourcis. Les tueurs sont lents mais très résistants. Si bien que la cible a intérêt à fuir plutôt qu’à chercher le combat.

A ce niveau, la question de l’équilibrage ne se pose pas encore. L’idée est de séparer les différentes façons de faire des points et de rendre leur changement aisé. Ici, il y a trois façons de faire des points :

  • Être la cible
  • Tuer la cible
  • Être la cible et tuer un chasseur

On peut également envisager un malus :

  • Être un chasseur et tuer un chasseur

Conception du code

Ici, je parle de la conception du code avant de plonger les mains dans le bousin. Rien ne dit donc que ça va marcher. A l’époque d’Unreal Safari, j’avais commencé à bosser sur ce mode. En fait, il y a une façon dont je l’ai envisagé qui me paraît mauvaise et compliqué : construire le mode comme un jeu d’équipe. L’équipe rouge chasse, l’équipe bleu est chassé. Si la cible est tué, elle passe dans l’équipe rouge et le tueur passe dans l’équipe bleu. Cela permet également de gérer simplement les friendly fire. Cependant, il faut bien prendre en compte que le mode Hunt n’est pas un feu d’équipe ! Chacun joue pour lui et seul le premier sera vainqueur. C’est une variante du mode Deathmatch. Changer le TDM posait d’autres problèmes tout simples :

  • Le HUD montre un score par équipe
  • La table des scores montre un score par équipe
  • Changer d’équipe nécessite de mourir (imaginez la frustration quand le joueur fraggue et qu’il meurt : il ne sait pas tout de suite s’il a été fraggué ou s’il est devenu la cible).
  • Une cible est définie dès le deuxième joueur connecté aléatoirement (c’est-à-dire qu’un joueur va faire des points sans avoir rien fait en début de partie)
  • Le message “VOUS ÊTES ROUGE” à changer pour “VOUS ÊTES LA CIBLE” (il est toujours plus facile d’ajouter simplement un message plutôt que d’en changer)

J’ai donc décidé de tout articuler sur la fonction ScoreKill (qui gère les frags). Elle se lance quand un joueur est tué et permet d’agir sur le tueur et le tué. Ainsi, je pourrais définir par une variable un changement de cible (certainement un booléen : bTarget). Plutôt que de mettre un système d’équipe complet, j’ajoute une variable à chaque joueur qui définit s’il est la cible ou non. L’idée est de faire :

Si le tué est la cible, alors le tueur devient la cible.

Rien de bien compliqué sur le papier, dans la pratique il y aura deux/trois choses à prendre en compte (notamment le friendly fire). Il faut également permettre aux joueurs de reconnaître la cible rapidement (même si elle saute deux fois plus haut que les autres et court comme Usain Bolt). Pour cela, une lumière dynamique suivra la cible pour qu’elle soit reconnaissable (en cela, utiliser un système d’équipe avait l’avantage de bien séparer visuellement les deux types de joueurs).

Dernière chose importante dans la conception pre-code : quand est-ce que je j’ajoute une cible ? En effet, si deux joueurs se retrouvent seuls sur un serveur, quel intérêt de mettre une cible ? Difficile ici de définir correctement. De toute manière, un joueur qui arrive en milieu de partie est toujours désavantagé pour du deathmatch. L’idée est de faire que la partie démarre sans cible. Dès qu’un joueur tue, il devient la cible.

Autres aspects du mode

Contrairement au game type Safari, ce mode demande beaucoup moins de personnalisation visuelle. Safari prenait en compte des niveaux et des points d’expérience qui avaient un impact important sur le jeu. Ici, quelques messages uniquement à afficher au bon moment :

  • Message : “Vous êtes la cible !” (avec un bruit reconnaissable)
  • Message : “Vous êtes un chasseur !” (lors du respawn)
  • Message : “Vous avez tué un chasseur !” (lors d’un friendly fire)

J’ai envie de faire quelque chose de plus personnalisé et fun avec plutôt des phrases du type : “Accident de chasse, arrêtez de boire !” ou “Vous êtes la cible, faites gaffe à vos fesses”. Le tout avec des sons enregistrés pour l’ambiance. Mais là, on parle déjà de finalisation du mode !

Sinon, le game-type Hunt a un nom pourri bien que représentant bien le principe. J’aimerais en trouver un de plus sympa. Hunting Safari sonne mieux je trouve mais je pense que vous voyez le problème…

C’est tout pour aujourd’hui. N’hésitez pas à donner votre avis sur le mode en lui-même. S’il y a des choses qui vous chiffonnent et qui vous paraissent rédhibitoires.

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

Aujourd’hui, je vais faire honneur à mes testeurs en analysant les différentes sessions de tests afin de mettre en avant leur rôle essentiel dans le développement d’un projet (surtout si on le développe seul, les avis extérieurs sont d’autant plus importants).

Quels testeurs ?

Avant de dire “je dois faire des tests”, je me suis posé la question “qui pourrait tester ?”. Trouver des testeurs n’est pas forcément si simple, car il est bon de les garder un minimum d’un test à l’autre et d’éviter un turnover très important. Très vite, par l’intermédiaire de ModDB, des personnes se sont proposées spontanément. Très vite, j’ai éliminé ce genre de profil pour plusieurs raisons. La première est la barrière de la langue : j’avais besoin de francophones afin qu’ils puissent expliquer clairement leurs idées, critiques ou conseils. La deuxième est le côté trop “fan” de ces personnes : quand quelqu’un est toujours fan de ce que vous faites, il risque de manquer d’esprit critique lorsqu’il jouera ou, pire, d’être très déçu par une version inaboutie très loin de leurs attentes. Je n’exclus par contre pas de les inclure dans des versions beta beaucoup plus proches d’une version finale.

Je me suis donc tourné rapidement vers les communautés francophones que je fréquentais : WeFrag, Mapping-Area et Unreal.fr. Avec des fortunes diverses (on ne peut pas dire que WeFrag se soit porté très volontaire sur le coup…), j’ai commencé avec une base de quelques testeurs (entre 4 et 8 selon les tests) qui a légèrement évolué tout en gardant un noyau dur, essentiel pour accompagner un minimum le projet et suivre son évolution. Plusieurs profils se sont alors dégagés naturellement, certains testeurs cumulant plusieurs profils :

  1. Le Gamer : il appréhende le jeu comme tel, de façon global. Il constitue la cible finale et donne des ressentis : j’aime/j’aime pas, je me suis amusé/ennuyé, etc. Essentiel évidemment.
  2. Le Level-Designer : il appréhende le jeu sur l’aspect graphique et technique : fonctionnement des scripts, qualité des lumières, intérêt d’un son à tel endroit.
  3. Le Moddeur ou Game-Designer : il appréhende le jeu de façon globale en incluant l’aspect promotion du jeu et en faisant des remarques sur la cible visée (typiquement le genre de gars qui fait tester le jeu à sa copine ou à sa petite cousine…) ou encore en critiquant le background.

Si chaque type de testeur est évidemment important, chacun va avoir tendance à être pointilleux sur des aspects très différents. L’un va dire que les textures du tabouret de la salle deux sont mal alignées, l’autre va reprocher que le mana ne se charge pas assez vite.

Un autre aspect important est que les testeurs sachent s’exprimer correctement. Si un testeur commence à dire trop souvent “je sais pas comment expliquer”, il ne faut pas hésiter à laisser tomber. Être concis est une qualité, certes, mais un testeur exhaustif est un don du ciel. Quitte à faire une synthèse derrière (ce que je fais systématiquement).

Fonctionnement des tests

Lorsque je lance un test, voilà comment je procède (en tout cas maintenant que je sais que c’est ce qu’il faut faire !) :

  1. Compiler le jeu
  2. Tester le jeu
  3. Uploader le jeu
  4. Downloader le jeu
  5. Installer le jeu
  6. Re-tester le jeu

Cela demande pas mal de temps mine de rien, surtout si l’une des étapes est défaillante. Par exemple, si l’étape 6 est défaillante, mieux vaut tout recommencer. Après toutes ces péripéties, il reste à prévenir les testeurs que la version est prête. Je joins systématiquement un fichier afin d’expliquer un peu à quoi ressemble un peu la version et les points sur lesquels je souhaite qu’ils se focalisent. Il va sans dire que certains testeurs ne lisent pas les instructions et lancent le jeu directement…

Voilà un exemple de ce qui est envoyé (deuxième test) :

Episode : Freyr Tutorial
Version : Beta 1.00
Description : Tutorial à tester

Points particuliers à observer et tester :
- Arriver à terminer le niveau
- Durée et pertinence des cinématiques (ou de leur absence)
- Observation de bugs éventuels (sonores, graphiques et de gameplay)
- Ergonomie du niveau (facilité de déplacement, collisions, etc.)
- Ergonomie des contrôles
- Toute autre remarque en termes de gameplay/idées/propositions graphiques
- Tout faire pour essayer de pourrir le jeu
Et surtout : quel a été l’enchaînement d’actions qui a permis de sortir de la salle ? (erreurs comprises) L’important est d’avoir un compte-rendu précis du cheminement qui permet au final de réussir. Que ce soit fait rapidement ou pas.

Bugs connus :
- La deuxième salle (hall du château) n’est pas terminée
- Pas de fin de niveau automatique (le tutorial se termine quand on entre dans le deuxième château)
- Menu de démarrage bancal
- Système de contrôle imparfait
- Les sous-titres ne sont pas centrés
- Pas d’animations sur les chaînes pour le pont-levis
- Le jeu se lance en fenêtré en résolution 1024×768. Pour passer en fullscreen : « alt+tab » et pour changer la résolution « TAB (ouvre la console) » puis « SETRES 1280×1024 » (par exemple pour une résolution de 1280×1024)

Changements depuis la dernière version :
- Système de contrôles revu
- Système de mana implanté
- Correction du bug qui obligeait à activer un élément AVANT d’aller sur un bouton
- Double saut supprimé
- Plus de dommages quand on utilise le mode FEU
- Ajouts de sons lors d’évènements (porte qui s’ouvre, plateforme qui bouge…)

Contrôles :
Left Mouse : Feu
Right Mouse : Eau
Left Shift : Air

Le fait d’annoncer les changements depuis la dernière version permet aussi de signaler aux nouveaux testeurs ce qui a été ajouté et supprimé, afin d’éviter qu’ils ne proposent des features déjà testées et abandonnées par exemple.

Suite à cela, chaque testeur me fait un compte-rendu plus ou moins explicite (certains font 5 pages, d’autres sont des screenshots commentés). Je prends le temps de les digérer, je rédige un compte-rendu que j’envoie aux testeurs. Dans cette note, j’écris aussi bien ce que m’ont dit mes testeurs, mais également ce que je vais prendre en compte et les idées que je ne retiendrai pas. L’avantage d’envoyer un compte-rendu global c’est que certains testeurs y réagissent ensuite, me permettant parfois d’affiner mes idées.

Un exemple précis : un testeur a rédigé un compte-rendu où il hurlait (métaphoriquement) contre le système de mana. Globalement, son test donnait l’impression qu’il aimait le jeu mais que le système de mana lui gâchait son expérience. Comme le mana me gênait un peu moi-même (j’utilisais souvent des cheats codes pour le court-circuiter), j’avais décidé de l’alléger un peu de multiples façons. J’ai donc, dans le compte-rendu, annoncé cette intention. Deux mails de testeurs m’ont été envoyé, disant que c’était une erreur. En effet, le système de mana pénalise les joueurs maladroits ou qui utilisent les éléments avec excès. En bref, le mana oblige aussi à réfléchir et à ne pas tout tenter jusqu’à ce que quelque chose fonctionne.

Le compte-rendu a aussi pour but de montrer à certains testeurs que leur avis est minoritaire. Non pas pour les descendre, mais il est important pour tout le monde de comprendre qu’un jeu doit plaire à plusieurs personnes et n’est jamais parfait pour un individu donné (ni même moi).

Le background

Je vais maintenant parler de certains aspects où l’apport des testeurs a été primordial. Les exemples seront donc on ne peut plus concrets !

Je reviendrai plus tard sur la genèse complète du background de Little God Story, mais l’impact des testeurs a été considérable. Au départ, j’ai créé un personnage : Little God. L’idée est qu’il ressemble à un viking, il est bourru, un peu comme un Nain. Je souhaitais ensuite écrire un scénario basé sur une quête des quatre éléments avec un background nordique. Au départ, rien n’est écrit de concret alors que les premiers tests démarrent.

Sur le deuxième test, voilà ce que m’a dit un testeur :

Pour moi, il apparaît très clairement que tu t’es posé beaucoup de questions quant au gameplay, mais en fait pas encore trop, derrière, sur son background. Et je pense très sincèrement que tu devrais procéder à l’inverse pour mieux asseoir l’ambiance et les principes de base de ton projet, afin de développer ensuite un gameplay en rapport avec.

Outch ! Et ça continue :

Plus terre à terre et en phase avec ce que tu présentes dans cette seconde beta : visuellement, tout d’abord, je trouve que le visuel que tu mets en place ici, – bien que déjà assez agréable – ne colle pas avec l’idée de ton mod. Tout cela fait plutôt médiéval (et plus proche d’ailleurs du haut moyen-âge) que de la culture viking. Quand au côté « divin », il me semble complètement passer à la trappe.

Ce genre de discussion s’est mené avec deux testeurs sur l’aspect Viking de mon jeu. J’ai tenté à de nombreuses reprises de coller Little God Story avec cet aspect-là, mais mes testeurs m’ont poussé à me rendre compte, simplement, que les Vikings n’avaient pas de château… Finalement, je me suis aperçu que pour enrichir et rendre crédible mon background, mieux valait le concevoir de A à Z. Cette souplesse me permettrait ensuite de faire ce que je souhaitais.

Le gameplay

Outre les ajustements de gameplay (tel que l’équilibrage), les testeurs apportent des briques bien plus importantes à l’édifice. Les premières versions de tests présentées ne possédaient qu’une part minime du gameplay de Little God Story aujourd’hui. Cela se limitait aux changements de capacités du personnage selon l’Elément utilisé (Feu = plus vite, Air = plus haut), aux interrupteurs et au système pierre/ciseau/papier (l’Eau tue le Feu, le Feu tue l’Air, etc.).

Comme dit précédemment, je me suis rapidement limité sur le gameplay afin d’éviter d’être trop ambitieux et de me brûler les ailes. Malheureusement, rapidement, j’ai du me confronter à mes testeurs qui (bien sûr) n’étaient pas du même avis :

Il faudra, je pense, que le joueur se serve de ses Runes pour déclencher des mécanismes d’une façon un peu plus naturelle qu’un simple interrupteur.

Ou encore :

Un petit coté Mirror’s Edge peut être sympa. En tout cas rajoute de la diversité.

Dès les premiers tests, avec une map de 10/15 minutes, le besoin de dynamisme se fait sentir. Comme il est généralisé chez TOUS les testeurs, je comprends que je vais être obligé d’ajouter des armes dans le jeu. Rapidement, je conçois l’arme de feu (la plus logique en fait) qui détruit des petits morceaux de bois. J’intègre ce principe dans les niveaux existants mais pas encore aux énigmes proprement dites. Plus tard, j’ajoute également l’arme d’air, mais ça reste encore un gadget pas très clair (l’arme fait bouger des objets à distance). Le travail demandé par ces ajouts est finalement relativement faible comparé au plaisir de jeu, bien plus intéressant.

J’ajoute un niveau entier supplémentaire avec des énigmes prenant en compte ces nouvelles armes et relance un test. Cette aspect dynamique est bien accueilli par les joueurs bien que pas évident (c’est plus facile de repérer un gros bouton vert qui brille plutôt qu’un bout de bois au plafond). Vient alors une remarque extrêmement pertinente :

Encore une fois, je pense que l’essentiel des problèmes que je te remonte est dû au fait que tu ne prends pas le temps de poser d’abord les choses sur papier.

Ce problème est évident car, à ce moment-là, je n’avais pas encore défini ce que feraient les armes d’Air et d’Eau, ni même s’il y aurait deux types d’attaques différentes (une sorte de tir secondaire). L’idée est d’arrêter de bloquer sur le principe de la réalisation. De ne plus se poser la question “est-ce que j’arriverai à faire ça ?” mais “qu’est-ce que je pourrais faire comme puzzle si le joueur peut faire ça ?” Il est essentiel d’avoir au moins en tête les features que l’on va implanter afin de prévoir un espace dans le tutoriel pour les intégrer, ainsi que l’agencement des puzzles. En pointant le doigt là-dessus, mes testeurs m’ont permis de comprendre que mon game-design était encore un peu léger.

La promotion

Certains m’ont déjà posé la question sur l’avenir de Little God Story. En gros trois questions sont les plus fréquentes :

  • Quand est prévue la sortie ?
  • Y’aura-t-il une démo ?
  • Sera-t-il payant ?

J’avoue ne pas avoir trop de réponse à ces questions. J’ai clairement envie de sortir une démo, mais je ne suis pas encore certain de le faire. FPS Terminator a eu droit à une démo qui a clairement douché l’enthousiasme d’un paquet de joueurs. Il lui manquait clairement une série de tests privés qui aurait corrigé une grande partie de ses défauts. Même si j’espère que ce jeu progressera, j’ai peur que beaucoup de joueurs s’en désintéressent (personnellement, je n’ai pas fait l’effort d’installer la version corrigée, javoue. J’avais envisagé de sortir une démo de Little God Story a un moment où aucun système de checkpoints n’avait été implanté. Mes testeurs m’ayant copieusement insulté sur ce point-là, cela paraissait impensable de le faire… Il n’est pas évident de se retenir de présenter son travail au plus grand nombre. Sortir une démo UDK, c’est s’assurer quelques articles sur les sites spécialisés…

Les tests permettent également de tester l’impact du jeu sur des publics pas forcément attiré à l’origine par le jeu :

Tout d’abord je dois avouer que le mod ne m’attirait pas plus que ça. (…) Toutefois je ne regrette pas d’avoir essayer LGS, et j’ai été surpris par le jeu. Agréablement surpris, j’entends.
Je ne cache pas qu’il y a eu des réactions inverses. Certains testeurs attendaient beaucoup du jeu et ont été très déçus par des versions encore peu abouties.
Comme dit précédemment, certains testeurs n’ont pas hésité à tester le jeu sur des publics plus larges (moi aussi d’ailleurs). Ceci a permis de préciser un peu la cible que je visais (qui n’est donc pas du tout les casual gamers !).

La version de test

Si choisir une version pour une release est très difficile, il n’est pas évident non plus de décider quand est-ce que la version présentée aux testeurs est suffisante. En effet, il ne faut pas faire trop de tests au risque de lasser les testeurs (qui joueraient toujours aux mêmes niveaux) et ne pas en faire trop peu afin de les impliquer dans le projet. Les tests sont très motivants pour un développeur car ils constituent des retours qui poussent à faire mieux (un peu comme un bon coup de pied au cul).

La première version de test que j’ai envoyé a été un fiasco. D’abord parce-qu’elle avait un bug très embêtant : le puzzle était orienté entièrement vers l’ouverture de la porte qui permettrait de partir. Or, cette porte n’avait pas de modèle de collision et permettait donc au joueur de finir le puzzle sans le faire réellement. Un bug inadmissible en soi, qui prouvait que je n’avais pas moi-même testé mon niveau dans cette optique. Deuxième grosse erreur : je n’ai présenté qu’un seul puzzle. En ne faisant pas de tutoriel, ni même de puzzle simple pour introduire ce qui reste actuellement l’un de puzzles les plus complexes, mes testeurs se sont arraché les cheveux. Ce qui nous mène directement au deuxième test.

Le deuxième test comportait le niveau “tutoriel”. Il démarrait au début de l’aventure et permettait d’apprendre petit à petit les pouvoirs. Son aspect graphique était rudimentaire (voir pire par moment) et le tutoriel mêlait mini-cinématique et sous-titres pour expliquer la marche à suivre. Au niveau du gameplay, il introduisait la jauge de mana (première feature à apparaître d’après les remarques des testeurs) et améliorait le système de contrôle. Quelques sons faisaient leur apparition, rendant le jeu plus crédible.

Le troisième test comportait ce même niveau “tutoriel” avec de fortes améliorations graphiques et l’ajout de nouvelles pièces, permettant d’obtenir les pouvoirs petit à petit. On peut noter également la personnalisation du HUD, l’ajout d’un journal de bord (pour se souvenir des instructions précédentes), de l’affichage de l’objectif en cours, de l’ajout de musique et de l’ajout de l’arme de Feu (lancer de boules de feu). Cette version, si elle modifiait relativement peu le gameplay pur (le lancer de boules de feu étant assez accessoire à ce moment-là) a donné aux testeurs une vision du jeu beaucoup plus agréable. Les graphismes étaient plus variés et plus beaux. L’ensemble était plus ergonomique et facile à jouer. Enfin, la suppression des cinématiques a atténué la lourdeur de l’ensemble. Pour info, je pensais à ce moment sortir cette version en démo publique.

Le quatrième test avait pour but de prolonger l’expérience en proposant le deuxième niveau (et donc des puzzles plus compliqués). Bien que relativement concluante, cette version a permis de pointer les soucis du premier tutoriel dès que les énigmes deviennent plus complexes. En revanche, de gros efforts ont été faits avec l’ajout de voix in-game qui donnent une réelle existence à Little God (et quelqu’un d’autre. Mais… Surprise !) et améliore le background qui était beaucoup trop léger. Il ajoutait également l’indispensable système de checkpoint. Bien qu’encore insuffisant, il supprimait ce qui était la partie la plus frustrante de la version précédente : devoir tout recommencer pour une maladresse… Cette version ajoutait également l’arme d’Air. A ce moment-là, cette arme était trop peu développée. Elle ne faisait aucun bruit, aucune animation à l’écran, aucun sprite ou particule… Il aurait été préférable qu’elle soit plus avancée avant de la faire tester. Ce quatrième test aurait mérité une ou deux semaines de développement de plus afin d’éviter les soucis qu’ont rencontré les joueurs.

Les améliorations que je cite dans toutes ces versions ont été proposées dans la majorité des cas par les testeurs. Soit directement (suppression des cinématiques), soit indirectement (manque d’ambiance sonore, background…) inexistant…). Le nombre d’améliorations à apporter pour le prochain test sont assez importantes. Je n’ai aucune idée de quand je le ferai, ni de ce qu’il contiendra exactement. Je décide de faire un test quand je considère que le jeu a pas mal évolué et qu’il faut tester ce qui a été fait afin d’être sûr de ne pas perdre son temps sur des puzzles ou features bancales.

Conclusion

Cet article est comme un cri d’amour pour les testeurs et je pense que tout le monde l’aura remarqué. J’avais déjà signalé leur rôle prépondérant dans le post-mortem d’Unreal Safari, je le confirme ici. Certes, les testeurs ont tendance à doucher l’enthousiasme d’un développeur de par leurs nombreuses requêtes et critiques. Il faut aussi prendre en compte qu’ils ne limitent pas leur conseil à la faisabilité. Nombre de fois, ils proposent des features que je considère comme infaisable (par moi). Et parfois, quelques mois ou semaines plus tard (et même quelques jours plus tard !), ces features sont (plus ou moins bien) implantées. Car les possibilités de plaisir de jeu qu’elles véhiculent sont énormes…

Je termine en rappelant que Little God Story a encore besoin de testeurs pour de nombreux mois (années ?) et que la communauté WeFrag ne m’a apporté à ce jour qu’un seul testeur ! Si vous voulez des jeux qui vous ressemblent, il faut savoir s’impliquer. De là découle ma conclusion : si vous avez un jeu/mod en préparation et que vous cherchez des testeurs, n’hésitez pas à me demander, je me ferai un plaisir de participer !

Pour ceux qui veulent tester ou faire tester un jeu/mod, voilà un article intéressant (en anglais) sur le sujet : http://www.moddb.com/tutorials/mod-testers-handbook

Autres liens :

http://www.moddb.com/games/fps-terminator

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.

Little God Story - DevBlog #2

Jeudi 29 juillet 2010

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 !

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