Little Blog Story

Game-Design & Modding le blog de belzaran.

Post-mortem : cs_bladerunner

Mardi 21 décembre 2010 à 14:24

cs_bladerunner

Petit retour sur cs_bladerunner, première map stratégique que j’ai publiée. C’était un véritable test en tant que level-designer : allais-je arriver à faire une map jolie ET jouable ?

L’origine de cs_bladerunner est assez originale. A l’époque, j’ai eu une idée de mod inspiré de la scène finale de Blade Runner : un joueur, équipé d’un révolver pénètre dans un lieu et doit abattre quatre réplicants, armés de leurs seuls poings. Le gameplay serait orienté sur un jeu de cache-cache : l’environnement est sombre et regorge de cachettes en tout genre pour que les réplicants puissent surprendre le Blade Runner.

N’ayant à l’époque aucune compétence en coding et quasiment aucune en modeling, j’ai abandonné cette idée rapidement (rien que d’en parler, ça me donne envie de la mettre en oeuvre maintenant !). Cependant, l’idée d’une map dans un environnement proche de Blade Runner m’a donné envie de l’exploiter.

Le concept

la map regorge de coins sombres

la map regorge de coins sombres

Le concept de la map est dérivé de mon idée précédente. Comme la map est pour Counter-Strike : Source, le game type Hostage Rescue paraissait le plus adapté. J’ai ainsi développé un pseudo scénario : les réplicants se sont réfugiés dans un immeuble abandonné avec des otages, les blades runners doivent sauver les otages.

La map devait à l’origine être quasiment l’immeuble de la scène de fin de Blade Runner. Après visionnage des scènes, ce n’était pas forcément facile à réaliser. J’ai alors adapté la map afin qu’elle soit plus resserrée mais également plus lumineuse. Comme je voulais que la map se passe essentiellement en intérieur (pour des questions d’optimisation, mon cauchemar), j’ai supprimé l’idée de l’accès au toit.

Niveau ambiance, il fait nuit, il pleut et le fameux dirigeable passe avec ses lumières et ses messages. La map sera donc sombre, avec beaucoup de zones d’ombres. Contrairement à beaucoup de maps CS:S, je veux donner une ambiance forte à ma map. On peut discerner ici mon amour immodéré pour le jeu en solo et les jeux d’ambiance (F.E.A.R. en tête)

Le layout

Le layout est basé sur un immeuble. Il est donc très carré et possède peu d’endroits ouverts. Pour CS:S, ce n’est pas vraiment un problème. Le fait d’utiliser uniquement des salles/couloirs m’a simplifié la tâche, permettant de contrôler les déplacements des joueurs et donc les stratégies possibles.

layout

Lescalier de secours

L'escalier de secours

L’immeuble comporte trois étages. Cela rend le gameplay original. En effet, la map est peu étendue mais possède plusieurs niveaux. Si les niveaux restent très classiques dans leur construction, les accès sont eux très différents. La première partie de l’immeuble est un grand escalier en colimaçon. C’est le point de départ des contre-terroristes (CT). De l’autre côté de la map, un autre escalier, droit, permet d’arriver à tous les niveaux. Dans la cour, un escalier de secours permet d’accéder aux étages. Il a l’avantage d’être mieux protégé (accès par des portes fermées) mais il est moins pratique et plus long à utiliser (situation en retrait dans la map, échelle pour y accéder…). Enfin, un ascenseur abandonné permet de passer du niveau 2 au niveau 3 par une échelle de secours. Bien que dangereux à utiliser, sa situation dans la map est une alternative intéressante pour surprendre l’équipe adverse.

Les otages sont évidemment au niveau 3, en retrait. Ainsi, la map s’apparente à un siège. Les zones de ralliement pour les otages sont situés de part et d’autre de la map, à l’extérieur de l’immeuble. En cela, tout est très logique. Le premier escalier rencontré est évidemment la solution la plus simple, l’escalier suivant étant beaucoup plus loin. Reste la possibilité bien sûr de surprendre l’adversaire en empruntant plusieurs escaliers différents. En cela, la souplesse des changements d’étages (entre 3 et 4 possibilités à chaque fois) apportent un peu de profondeur et de diversité au gameplay.

Malgré l’espace étriqué, il existe des endroits où se tirer dessus à mi-distance. Au dernier étage, un long couloir mène de la cage d’escalier aux chambres où sont retenus les otages. Il n’est pas rare que cet espace soit un lieu d’affrontement (flashbang et fumigènes ont tendance à s’y amonceler). De même il existe une grande salle au niveau 2 où les mitraillages sont légion.

Au final, le gros avantage du layout c’est qu’on se retrouve facilement dans la map. On ne fait que passer de pièces en pièces et d’étages en étages.

Beta-test

Malgré que la version “finale” reste une version beta, il y eut une première version à tester d’abord. Comme je jouais beaucoup à CS:S à l’époque, je l’ai simplement proposé à mon serveur préféré (les OGT) et on a pu la tester ensemble. Les impressions étaient plutôt bonnes mais deux points ont nécessité des recadrages (que seuls des tests contre des humains ont pu mettre en évidence).

Le premier point gênant était que les terroristes devaient forcément commencer une partie dans un couloir donné. Or, ce couloir étant très long, il était possible aux CT de lancer directement une flashbang dedans… Les terroristes se trouvaient aveuglés systématiquement. Cela n’avait pas de conséquence immédiate (le temps que les CT arrivent, tout le monde était parti !), mais c’était très pénible et pénalisant. J’ai donc simplement ajouté une porte pour que les terroristes puissent passer ailleurs. D’où l’importance de toujours donner le choix…

Le deuxième point était que les deux points de ralliement pour les otages pouvaient être campés en même temps par un seul terroriste ! Il était donc déjà arrivé qu’un CT se fasse fragger juste avant que les otages ne rejoignent le point de ralliement… Pour cela, j’ai ajouté un véhicule qui protège le CT et empêche à un terro de guetter les deux points à la fois.

Résultat ?

une des pièces de limmeuble

une des pièces de l'immeuble

Au final, la map possède une vraie ambiance (même si elle sera trop sombre pour certains). On entend la pluie, l’orage, de la vapeur d’eau s’échappe des conduits, les lumières sont dynamiques, les ombres franches… Par contre, on pense relativement peu à Blade Runner. Certains éléments ont été modélisé pour l’occasion, mais ils sont souvent à des endroits peu ou pas du tout visité par les joueurs (notamment dans la rue). Cependant, m’inspirer de Blade Runner m’a permis de développer un concept de map sympa et quelques models sympas (notamment le grand escalier).

De petite taille, la map a l’avantage d’être très facilement mémorisable. Les salles sont assez différentes pour qu’on les reconnaisse et les voies d’accès sont suffisamment claires pour être repérées immédiatement. Son aspect cloisonné gênera fortement les campeurs et plaira aux adeptes du fusil à pompe. Elle est clairement peu ouverte et ne plaira pas à tout le monde. En revanche, elle est très bien optimisée grâce à ça.

Cette map est, je pense, peu adaptée aux gros joueurs de CS:S. Ils lui reprocheront d’être trop petite, trop confinée (pas de tirs de loin, ni de snipe) et pas assez lisible (beaucoup de coins très sombres). C’était un parti pris, donc ça ne me gêne pas, mais il est évident que ce genre de choix n’est pas le meilleur moyen de vendre sa map.

Le plus gros défaut est l’aspect extérieur. En effet, une fois le gameplay finalisé (et c’est le cas ici), j’avais prévu de retravailler  (voire travailler tout court) la rue qui est désespérément vide. Clairement, cela montre que la map n’est pas terminée. Mais comme 95% du jeu se fait ailleurs que dans la rue principale… Je regrette bien sûr de ne pas être allé au bout, mais mes limitations en terme de modeling à l’époque peut l’expliquer.

Et après ?

J’ai été terriblement limité dans cette version par le moteur Source. S’il était adapté au concept d’un immeuble, il était trop vieillissant en terme de lumières dynamiques. J’avais prévu à l’origine toute une série de lumières filtrant à travers le toit. J’ai pu au final en mettre une complètement esseulée, que personne ne remarquait au final.

Même si cela peut paraître prétentieux, j’avais l’impression d’être allé un peu au bout du moteur. J’avais fait une map jolie avec un gameplay qui tenait la route, mais je voulais aller plus loin dans les lumières (et notamment les contrastes). C’est pourquoi j’ai, un mois plus tard, acheté Unreal Tournament III dans le but de mapper dessus. J’ai plusieurs fois eu envie de retourner sur Source (notamment quand je galérais sur l’Unreal Editor). Je regrettais également le gameplay de CS:S, qui est sympa à mapper je trouve. Il n’est pas trop ouvert, pas trop compliqué et possède une dose de stratégie non-nulle. Au final, je n’ai jamais plus pu retourner sur Source à cause de deux points essentiels :

  • obligation de compiler la map pour la tester (et la compilation est longue…)
  • intégration des models customs complètement abracadabrantesque.

Bientôt, un retour sur ma toute première map : gg_techcenter.

LA MAP

Toute personne qui a un blog se soucie souvent de deux données : le nombre de commentaires et le nombre de visiteurs uniques. Ce sont deux informations qui permettent de juger de la pertinence d’un blog. Il existe d’autres moyens de définir la qualité d’un blog comme le temps passé dessus par les visiteurs, le nombre d’articles lus, la régularité des mises à jour… Evidemment, aucun ne peut être pertinent et le tout se doit d’être analysé dans sa globalité. Over-blog propose ainsi un « blog rank » se proposant de regrouper toutes ses informations en un nombre compris entre 0 et 100. Restant un peu obscur sur son mode de calcul, il reste un moyen de juger des progrès de sa popularité.

Over-blog propose un système de visionnage de statistiques intéressant mais souvent incomplet. Quand on arrive dans l’administration on peut voir les données essentielles : Blog Rank, évolution du nombre de visiteurs et nombre de pages vues :

graph1

Cependant, pour analyser plus profondément le profil des visiteurs et comment et pourquoi ils viennent sur un blog, il faut aller voir les statistiques détaillées. Assez limitées, les statistiques d’Over-Blog sont cependant suffisantes pour qui ne souhaite pas se prendre la tête. Cependant, pour une analyse approfondie, je conseille l’utilisation de Google Analytics. Cet outil par Google est assez simple à mettre en place sur son site/blog et permet d’avoir accès à nombre d’informations supplémentaires. De plus, il est entièrement gratuit tant que vous ne dépassez par 5 millions de visites par mois… Pour l’installer, il suffit d’insérer quelques lignes de codes sur votre site, le tout étant parfaitement invisible. Autre avantage : il fonctionne en temps réel (contrairement à Over-Blog qui propose un traitement journalier).

Par exemple, je souhaite connaître l’influence de Facebook dans les visites de mon site. Quel est le nombre de visiteurs qui viennent suite à un message qu’ils ont reçus via Facebook (soit envoyé par moi-même, soit par quelqu’un d’autre qui aurait aimé le blog) ? Voilà la page des statistiques de provenance des visiteurs d’Over-Blog :

graph21

On remarque tout de suite qu’Over-blog ne liste pas les liens de façon intelligente. Il se contente de les citer sans regarder si le site de base est le même. On se retrouve ainsi avec nombre de sites à une visite alors qu’en soit, c’est la même source. Ici, il y a donc 6 visiteurs en provenance de Facebook.

Comparons avec les données de Google Analytics :

graph31

On remarque tout de suite que Google Analytics analyse (comme son nom l’indique) les données et me propose un total des visites du site Facebook. Le classement des sites par visites, désormais regroupées, devient plus pertinent. Par exemple, mon dernier article sur mon blog WeFrag est le plus gros générateur de visites alors qu’il ne parle pas de bandes-dessinées, ni de dessin ! Autre remarque, les autres blogs de BDs (sur lesquels je laisse des commentaires), sont des apports importants de visites (8 visites ici).

Remarque : n’ayant pas configuré le fuseau horaire de Google Analytics au moment des captures, les valeurs données par Google Analytics et Over-Blog paraissent différentes. Dans les faits, à quelques visites près, c’est exactement la même chose.

D’autres données sont également très intéressantes, comme le nombre de pages par visite. En cela, il est lié au taux de rebond qui analyse si les visiteurs qui tombent sur le site le quittent sans rien regarder d’autre. En gros, un taux de rebond élevé veut dire que les gens arrivent sur la page et la quitte sans rien regarder d’autre. Autre donnée, le temps moyen passé sur le site peut également avoir son intérêt, de même que le pourcentage de nouvelles visites qui permet d’analyser la fidélité des internautes.

Autre source d’apport de visites : les moteurs de recherche. Comme Over-Blog, Google Analytics donne la liste des mots-clés utilisés par les internautes qui ont fini sur votre blog. Par exemple, le fait d’avoir publié une note sur le remaniement m’a apporté deux visites suite aux recherches « remaniement blog » et « remaniement bd ». L’avantage de Google Analytics est ici de pouvoir savoir si le visiteur a été satisfait (via le taux de rebond par exemple ou le nombre de pages lues).

graph4On peut ensuite s’intéresser au profil des visiteurs (et non plus de leur comportement). La provenance des visiteurs est accessible. Très précise, elle indique le pays et la ville de provenance des visiteurs. Cette donnée peut être reliée à la langue des visiteurs, également consultable. Jusqu’à là, rien de bien effrayant. Mais on peut également accéder à (tenez-vous bien) : le système d’exploitation, le navigateur, le fournisseur d’accès, les couleurs de l’écran, la résolution d’écran, si Java et Flash sont installés sur l’ordinateur… Evidemment, tout cela peut être utile à un webmaster pour configurer son site, mais cela sous-entend le nombre de données auxquelles Google peut avoir accès ! Simplement avec les fournisseurs d’accès, j’ai pu voir que certains de mes amis regardaient mon site au boulot par exemple, car certaines entreprises ou universités sont citées comme fournisseurs d’accès…

Il va donc sans dire que toutes les données ne sont pas foncièrement utiles au bloggeur, mais que leur nombre les rend globalement intéressantes. De plus, la personnalisation est totale :  libre à vous d’analyser vos visites sur la période de temps qui vous intéresse. Il est également possible de créer des alertes entièrement personnalisées (pour se faire signaler un pic ou un creux de fréquentation par exemple) ou de lier ce service à la régie publicitaire Google AdSense.

Google Analytics permet de centraliser vos sites et blogs (si vous en avez plusieurs) et de les analyser au même endroit avec le même outils. Par exemple, quelques données comparatives entre mon blog WeFrag et mon blog de BD sur Over-Blog sur une journée :

Little Blog Story

Le Blog BD de Belzaran

438 visites

82 visites

1,16 pages par visite

5,97 pages par visite

93 % de taux de rebond

3 % de taux de rebond

17 secondes passées en moyenne sur le blog (!)

4 minutes passées en moyenne sur le blog

20 % de nouvelles visites

72% de nouvelles visites

On voit sans peine que les audiences sont extrêmement différentes. NoFrag amène quantité de curieux qui cliquent et referment immédiatement la page (moi le premier), d’où un taux de rebond important. L’autre blog étant de la BD, il est plus naturel d’en regarder quelques-unes pour se faire une idée et donc d’y passer plus de temps. Ici, on peut voir que quelques données bien analysées permettent de juger du type d’audience du site, ce qui est bien utile si l’on souhaite l’améliorer (ou même par simple curiosité).

Au final, pour peu que l’on n’ait pas peur de la quantité d’informations, de graphiques et de tableaux, il paraît évident que Google Analytics est un formidable outil pour développer un media sur internet. Etant donné sa simplicité d’utilisation, il serait dommage de s’en priver.

Liens

Google Analytics

Over-Blog

Un peu d’humour…

Mercredi 1 septembre 2010 à 8:16

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.

Little God Story - DevBlog #6 (HUD)

Samedi 28 août 2010 à 12:20

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 à 13:07

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 à 7:22

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.

UDK - Pour ou Contre ?

Lundi 16 août 2010 à 7:12

The Ball

The Ball

L’Unreal Engine

L’Unreal Engine est un moteur de jeu développé à l’origine par Epic Games pour le jeu Unreal. Il a depuis subi de nombreuses améliorations et en est à sa troisième version : l’Unreal Engine 3. Unreal Tournament III a servi de vitrine technologique à Epic. Ce jeu était en effet très beau à sa sortie et bien optimisé. Malheureusement, UT3 n’a pas eu le succès escompté. Contrairement aux version antérieures d’Unreal Tournament, UT3 n’a donc pas fait des émules sur la scène du modding. A l’inverse, Half-Life² a toujours proposé plus de projets de mods. En revanche, l’Unreal Engine 3 se vendait remarquablement bien et était à l’origine de nombreux hits (Rainbow Six : Vegas, Bioshock, Gears of War…). Son aspect multi-plateforme, ainsi que sa facilité d’emploi (notamment grâce à un gros support d’Epic pour les développeurs) le rendent particulièrement bien vendable, contrairement à la concurrence (CryEngine en tête…)

Qu’est-ce que l’UDK ?

En novembre 2009, Epic surprend tout le monde avec la sortie de l’UDK. Globalement, cet outil permet de créer des jeux à partir de l’Unreal Engine sans posséder un jeu en particulier. La Totale Conversion ultime en quelque sorte… La sortie de l’UDK est accompagnée de l’annonce du portage de The Ball (mod célèbre pour UT3) sur l’UDK. Très vite, la plupart des mods majeurs sur UT3 annoncent leur passage sur l’UDK (Prometheus, Sanctum, AFF : Planetstorm). Ces annonces sont très vite suivis d’une démo, souvent très proche (voir identique) de la dernière version beta de leur mod.

Globalement, l’UDK c’est un peu UT3 sans avoir les assets. Il faut partir quasiment de zéro et tout reconstruire. L’avantage est qu’un projet amateur dispose désormais d’un moteur extrêmement puissant librement. Inutile de perdre du temps à développer un moteur graphique moyen et mal optimisé, le meilleur de la technologie est à portée de main. D’un coup, la scène du jeu indépendant et du modding se rejoignent.

Les opportunités offertes par l’UDK

FPS : Terminator

FPS : Terminator

Les nombreuses équipes qui développent des mods ambitieux (souvent des TC) ont désormais la possibilité de faire un stand-alone, c’est-à-dire d’ouvrir leur public non plus à un jeu unique, mais à toute la communauté du gaming.

Le cas de FPS : Terminator est ici assez criant. Ce mod était prévu pour Gears of War (PC). Il est alors aisé de comprendre que vu le nombre de joueurs qui ont Gears of War et sont prêts à l’installer pour joueur à son mod est extrêmement faible. En passant sur l’UDK, le mod devenu jeu a fait un buzz énorme (notamment grâce à son ambiance exceptionnelle) et est désormais suivi par beaucoup de joueurs.

Un autre cas intéressant est celui de Chivalry. A l’origine, Age of Chivalry est un mod pour Source. Avec la sortie de l’UDK, les développeurs ont décidé d’en faire un jeu complet sur l’Unreal Engine 3. Or, changer de moteur n’est pas de tout repos…

L’UDK permet également de vendre son jeu. La licence proposée par Epic est assez souple et évite aux équipes de développement de payer à l’avance pour le moteur. Le studio ne paye rien sur les premiers 5000$ gagnés. Puis Epic récupère 25%. Ce deal est évidemment très avantageux pour Epic. Et pour les devs, la prise de risque est moindre.

Il est à noter que l’UDK est depuis sa sortie mis à jour tous les mois. Si cela apporte son lot de galères parfois (non-compatibilité du code selon les versions), c’est très appréciable. Et je ne pense que personne ne niera que les dernières versions sont bien plus efficaces que les toutes premières.

Il est à noter que, comme pour Crysis, certains mappeurs se servent du moteur pour faire des maps où seul le souci esthétique prévaut. Certains codeurs codent des features pour tester le moteur. Sans forcément développer un projet complet, l’UDK est également un outil assez simple qui peut permettre d’apprendre simplement (importation des modèles et textures rapide et facile, visualisation en temps réel des maps…)

L’UDK a ainsi boosté la scène indépendante. Des démos de jeu sortent actuellement régulièrement avec une qualité graphique très appréciable et des contenus souvent originaux.

Les problèmes posés par l’UDK

Q.U.B.E.

Q.U.B.E.

Certains parlaient déjà avant l’UDK du problème de l’Unreal Engine 3 : il est utilisé par beaucoup de jeux et est très reconnaissable (les lumières font très artificielles, ça brille, c’est du next-gen quoi). Avec l’UDK, la scène indépendante risque de réutiliser massivement ce moteur et d’uniformiser d’autant plus les productions actuelles. Certes, la plupart des jeux UDK ont des rendus très colorés et originaux, mais pas mal de joueurs n’aiment pas ce côté artificiel.

Il est flagrant de voir que beaucoup d’écoles de jeux vidéo utilisent désormais l’UDK comme moteur pour leurs projets étudiants. On peut ainsi citer Q.U.B.E. , ColourRunnersGerridae ou Maglev. Ces projets sont souvent très propres et originaux, mais il y a peu de chances qu’ils dépassent le statut de démo sympa. La démo UDK devient un tremplin plus qu’un jeu à part entière.

Un autre problème est bien sûr la taille des projets. Sur l’UDK, les projets sont démesurés et très ambitieux. Il y a un risque que les mods périclitent devant la possibilité de faire un jeu complet. Alors que les mods arrivaient déjà rarement à une version jouable satisfaisante, on peut se poser la question sur des jeux complets… En tout cas, l’UDK a carrément enterré le modding pour UT3. Or, il faut rappeler qu’un mod n’est pas toujours une totale conversion et démarre souvent par des modifications mineures qui, mises bout à bout, finissent par de plus permettre de reconnaître le jeu original.

Le problème des jeux payants va également se poser. The Ball, premier jeu UDK annoncé, est passé de mod gratuit pour UT3 (de très bonne qualité) à jeu payant. Or, les qualités requises d’un jeu pour qu’un joueur accepte de le payer sont bien plus élevées. Que ce soit la durée de vie, les graphismes ou le côté rébarbatif du gameplay. D’ailleurs, l’équipe a beaucoup travaillé ces aspects-là en améliorant le graphisme de certains éléments importants (personnages, boutons…), en ajoutant un tutoriel et en permettant de voir à travers la boule (grand défaut rébarbatif du mod). On peut légitimement se poser la question de la valeur réelle de tous ces projets qui fleurissent.

Conclusion

alien Swarm

Alien Swarm

Si l’UDK a donné un coup de pouce évident à la scène amateur/indépendante, il paraît nécessaire qu’il aie des concurrents. Le moteur Source, de Valve, reste très concurrentiel et la sortie d’Alien Swarm (jeu gratuit) ou l’aide aux campagnes customs de Left 4 Dead 2 confirme l’envie de Valve de favoriser le modding. De même, Crytek envisage de publier une version libre de leur CryEngine 3. Il est vrai que cela fait des années que Crytek essaie de vendre (en vain) son moteur, la faute à un support trop limité. En permettant aux amateurs de faire leur armes sur le CryEngine, ils peuvent espérer vendre leur moteur plus facilement ensuite.

UDK : http://www.udk.com/

The Ball (FPS Puzzle Game): http://theball.toltecstudios.com/

Sanctum (FPS Tower Defense): http://www.moddb.com/mods/sanctum

Prometheus (Puzzle Game) : http://www.moddb.com/mods/prometheus

AFF : Planetstorm (FPS + Combats spatiaux) : http://www.moddb.com/mods/angels-fall-first-planetstorm

FPS Terminator (FPS) : http://www.moddb.com/games/fps-terminator

Q.U.B.E. (FPS Puzzle Game) : http://www.qubegame.co.uk/

ColourRunners (FPS pas très clair) : http://colourrunners.blogspot.com/

Gerridae (plateforme) : http://gamagora.univ-lyon2.fr/gerridae/blog/

Maglev (plateforme) : http://www.pauseponderplay.com/

Little God Story - DevBlog #5 (Le Mana)

Jeudi 12 août 2010 à 8:44

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 #4 (Les Tests)

Dimanche 8 août 2010 à 21:30

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

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

Vendredi 30 juillet 2010 à 10:03

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.