Little Blog Story

Game-Design & Modding le blog de belzaran.

Articles taggés avec ‘unreal safari’

Un peu d’humour…

Mercredi 1 septembre 2010

Introduction

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

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

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

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

L’écrit

Bonjour les fautes dorthographe !

Bonjour les fautes d'orthographe !

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

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

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

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

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

Le dessin

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

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

LAK-Banana

Modification de skin pour blague vaseuse

L’univers

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

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

Les sons

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

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

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

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

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

LAK-Banana

L'AK-Banana

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

Vers un peu plus de subtilité…

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

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

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

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

Conclusion

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

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

Making-Of : Hunt (2)

Mardi 24 août 2010

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

Etat actuel du projet

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

Le début de partie

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

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

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

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

Les bots

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

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

Unreal Safari : Post-mortem (2)

Lundi 19 juillet 2010

unrealsafari

La première map : WAR-Gizeh

Après les premières hésitations, je me met à travailler sérieusement sur une map dans l’environnement Gizeh. Pour y aller petit à petit, je tente d’abord des maps uniquement extérieures, avec des temples ouverts sur le ciel. A force de recommencer, je commence à avoir une bibliothèque de modèles assez importante qui me permet, quand je redémarre une version de la map (ce qui arrive assez souvent) de ne pas passer des journées entières à tout refaire. Je travaille pas mal la modélisation modulaire qui permet de modéliser de façon plus souple.

Cependant, les brouillons de maps n’atteignant jamais une version suffisante. Je ne peux donc pas vraiment tester ces layouts en terme de gameplay. Lassé par la grande taille des maps Warfare, je décide alorsd’essayer de faire une version 100% dans un village. Le côté confiné est un désavantage certain, mais il me permet de mieux maîtriser les déplacement des joueurs. Avec le recul, cette idée était très mauvaise. Ce genre de map n’est pas du tout adaptée au mode de jeu. Je revenais à mes (mauvais) réflexes de level-designer pour Counter-Strike : Source.

Techniquement, les rendus rappellent UT2003/2004. J’apprends alors à utiliser à bien les textures de type normal maps (relief), specular maps (reflets) et shadow maps (ombres). Cela m’a pris du temps, me demande souvent plus de travail, mais j’obtiens enfin eu un rendu in-game supérieur à ce que je faisais sous Source. Il m’aura fallu des mois pour ça.

Une fois ces techniques maîtrisées, je redémarre une dernière fois WAR-Gizeh. Globalement, la réalisation de la map ne posera pas de problèmes particuliers. Mon idée ici est de publier une map Warfare (c’est-à-dire pour UT3) que je modifierai ensuite pour mon mode “Warfare pour animaux”. En effet, à ce stade, le mode de jeu prévu pour Unreal Safari est une Warfare sans véhicule. Pour ceux qui ont joué à ce mode de jeu, ils comprendront sans peine que :

1 - inutile de faire un mod pour ça
2 - les véhicules sont un des grands intérêts du mode Warfare

Cependant, l’idée de faire une map publiable est certainement la meilleure idée que j’ai eu ici. Car elle me permettait de me prouver que j’étais capable de faire une map avec 90% d’éléments custom sur l’Unreal Engine. Le layout est pas mal mis en cause et changera au fil des bétas. Très vite, j’apprend à écouter la communauté, même si ses exigences sont parfois décourageantes. Ajouter des points de contrôle par exemple demande énormément de boulot, car il ne faut qu’ils ne soient pas destructible de trop loin (donc il faut les protéger). De même, ajouter des véhicules implique un équilibrage pas toujours évident. Au final, en écoutant les remarques, la map a pris beaucoup en intérêt stratégique car au départ, il n’y avait pas beaucoup de possibilités de jeu et la map devenait vite répétitive. Il est à noter que la communauté m’a poussé à faire une version Necris en plus afin de plaire au plus grand nombre !

layout

WAR-Gizeh ne sera jamais utilisé pour Unreal Safari. Mais ce n’était pas une perte de temps car elle m’a permis de :

1 - Me faire connaître un peu dans la communauté
2 - Constituer une banque de modèles et de textures pour Unreal Safari
3 - Apprendre de nombreuses techniques supplémentaires
4 - Travailler le level-design d’un mode de jeu pour lequel je n’avais jamais mappé
5 - Me prouver que ma “patte” graphique était appréciée et considérée comme original

Il est à noter que plusieurs mois après la release, j’ai été contacté par des joueurs qui voulaient que je corrige les quelques soucis restant sur cette map. Contrairement à ce que je croyais, cette map a donc été jouée sur certains serveurs.

Je termine là-dessus afin de préciser l’importance des avis de la communauté. J’ai eu la chance de faire partie de communautés pertinentes (bien que peu nombreuses) qui m’ont soit aidé techniquement, graphiquement ou au niveau du gameplay. Sans eux, je ne serais pas allé loin. Ces communautés sont Mapping-Area, Unreal.fr et Unreal-Design.

beta_2_01 beta_2_07 beta_2_06

Liens : http://www.moddb.com/mods/unreal-safari/addons/war-gizeh