Little Blog Story

Game-Design & Modding le blog de belzaran.

Archive pour la catégorie ‘Post-mortem’

Post-mortem : cs_bladerunner

Mardi 21 décembre 2010

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

Unreal Safari : Post-mortem (6)

Vendredi 23 juillet 2010

unrealsafari

Il est temps de clore cette série d’articles avec l’arrêt du développement d’Unreal Safari (qui, globalement, a traumatisé pas grand monde !). Les raisons principales sont évidemment toujours les mêmes et elles sont évidemment liées :

1 - La perte de la motivation
2 - La quantité (astronomique) de travail restant à faire

Le but de ce dernier article n’est pas de développer ce genre de propos, très banals,  mais d’expliquer les petits trucs qui petit à petit, amènent à ce ressenti.

1ère raison : je ne suis pas assez compétent

Il n’est jamais très agréable de l’avouer, mais il y a un moment où j’ai pris conscience de ma propre incompétence, notamment en terme de modélisation (pour les personnages et les armes, c’était assez flagrant), d’animation, d’effets visuels, voir de programmation. Quand on voit tout ce que j’ai appris à faire depuis le début, on pourrait penser que j’aurais pu me lancer dans l’aventure et apprendre comme pour les autres domaines. Mais trop c’est trop. Apprendre de nouvelles techniques à la pelle est intéressant et gratifiant mais ne fait qu’ajouter du boulot. Quand je modélisais une caisse à la truelle, ça me prenait 5 minutes. Quand je fais un model sympa avec des textures plus variées et le support de lightmaps par exemple (le minimum syndical en sorte), j’en ai pour la matinée. A force d’apprendre, on augmente aussi son temps de travail. Ce n’est pas nouveau, développer un jeu next-gen prend de plus en plus de temps et j’étais encore loin des techniques next-gen…

2ème raison : j’aime pas les jeux multijoueurs

Patator : Nevermind the Beach

Patator : Nevermind the Beach

Contrairement à ce que l’on pourrait croire, je ne joue quasiment jamais en multi. J’ai joué à une époque un petit peu à Counter-Strike : Source, Unreal Tournament III, Warcraft III ou Company of Heroes, mais jamais très longtemps. Cela vient aussi bien de mon faible niveau que de mon manque d’intérêt. Mais alors pourquoi mapper et modder pour le multi ?!

J’ai toujours eu en projet de faire un mod/jeu solo. J’avais à l’époque un scénario et une personnage, Patator. J’ai essayé de développer Patator sur FPS Creator, Far Cry, Half-Life ² et Crysis, avec des avancées plus ou moins grandes. Et un jour j’ai compris que l’avantage de faire des maps multijoueurs, c’est que ça demande moins de travail pur, car elles sont souvent plus petites et rejouables. Ce sera mon leitmotiv pour plus de 2 ans de rejet de mes pulsions primaires qui adorent les jeux solos.

Patator : Source

Puis ce fut le choc : j’ai joué à The Ball. Une révélation. En effet, contrairement aux screens que j’avais pu voir du mod, quand on joue au premier niveau, The Ball n’est pas renversant. Il est beau mais sans plus, très carré, très couloir et avec des mécanismes simples voire simplistes. Au fur et à mesure des niveaux, il se complexifie. Des NPCs apparaissent, les énigmes deviennent plus ardues, le monde devient plus beau et diversifié… A ce moment-là je me suis dit : “je peux faire ça ! (en moins beau)”. C’était certainement un peu utopiste de ma part, car si ce n’est pas dit clairement, il était sous-entendu que je considérais que j’espérais être capable de le faire tout seul… Bref, l’idée de faire un FPS solo sans combat trotte dans ma tête. A l’époque, je n’ai aucun concept en tête, mais la frustration de modder pour du multi s’installe.

http://www.moddb.com/games/the-ball

3ème raison : je suis frustré artistiquement

Cela peut paraître un peu pompeux, mais je rappelle que je suis allé modder sur UT3 pour pouvoir utiliser des lumières dynamiques. J’adore les jeux d’ombres. En cela, mes références graphiques sont Doom III, F.E.A.R. ou Bioshock. Alors forcément, un mod africain avec une lumière crue et forte, ce n’est pas ce que je préfère. L’univers que je développe est certes original mais n’exploite pas mes qualités de mappeur. En effet, je modélise de façon brute. Or, un éclairage fort et uniforme souligne ce côté simpliste. Comme mes éclairages étaient le point fort de mes maps précédentes, je commence à prendre conscience que si je suis passé sur UT3, ce n’est pas pour faire des maps comme ça.

4ème raison : j’ai perdu ma map !

Modèle de mur pour la mosquée

En commençant réellement la totale conversion, j’ai du créer un nouveau dossier “Unreal Safari” pour intégrer pleinement les armes/personnages/maps et sortir du côté “je bidouille un peu UT3″. Ceci ne s’est pas fait sans douleur et malgré toutes les manipulations, je continuais de devoir stocker mes maps dans le dossier UT3… Un jour de mauvaise manip, j’ai supprimé mes packages Unpublished au lieu de mes packages Published. Je vais tenter d’expliquer un peu la nuance entre les deux :

Unpublished : contient toutes les textures / models / sons / whatever bruts. Ils ne sont pas compressés et restent modifiables
Published : contient uniquement les textures / models / sons / whatever utiles au mod/jeu/map. Ils sont compressés et ne sont pas modifiables.

Modèle de colonne pour la mosquée

On pourrait croire que le fait de ne pas pouvoir modifier mes anciens assets n’était pas si grave, mais UT3 a décidé de me plomber bien plus encore ! Sur ma map SAF-Gizeh, il ne retrouve plus du tout les models et textures. Après quelques tentatives infructueuses, je m’aperçois que la map est fichue. Il faut tout recommencer…

Cela m’a freiné un peu, mais pas arrêté ! Après quelques semaines je m’y remet, décidant d’en profiter pour changer le level-design et de monter d’un cran en terme de graphismes. Quelle erreur ! Le level-design de SAF-Gizeh tenait la route et ne nécessitait pas de changer du tout au tout. Quand à l’amélioration graphique, si elle a été appréciée par les “fans” du mod, elle rejetait la sortie du mod à beaucoup plus tard…

5ème raison : comment vais-je faire jouer à mon mod ?

Si vous suivez un peu les releases de mod, il n’est pas rare de voir comme remarque “ce mod a l’air sympa, mais ils n’ont aucun serveur pour le tester”. En gros, le mod espère que des fans vont mettre en place des serveurs pour y jouer. Ceci est suicidaire car un mod multi est souvent très peu joué d’emblée, alors l’absence de serveurs existants et encore pire. J’ai donc pris conscience à un moment que je devrai investir dans des serveurs pour la promotion d’Unreal Safari. Or, en étant seul, louer des serveurs est loin d’être gratuit… Ce genre de préoccupation a un peu plomber les dernières semaines de développement. Cette idée me perturbait car je ne voulais pas non plus faire un mod injoué. Je ne faisais pas ça dans le but unique de faire un post-mortem après…

6ème raison : L’UDK apparaît

L’Unreal Development Kit est un véritable graal pour les moddeurs. Il donne accès au moteur Unreal Engine plus ou moins gratuitement (il y a quand même des royalties qui traînent). Je traiterai de cet outil plus en détails dans un prochain article.

Il faut comprendre que la sortie (surprise) de l’UDK a été une véritable bombe dans la communauté du modding et notamment du modding UT3. En effet, il devenait possible de faire passer son mod au statut de jeu complet, voire même de jeu complet payant. Toute Totale Conversion qui se respecte avait l’occasion d’élargir son public ! Et quand on connait la petitesse de la communauté UT3…

Je n’ai jamais eu l’envie de convertir mon mod UT3 en jeu UDK. Cependant, les grands mod UT3 (ceux du Make Something Unreal Contest) sont rapidement tous passés sur l’UDK. L’impression, vue de l’intérieur, était que la communauté se délitait.

L’UDK a précipité la chute d’Unreal Safari. En effet, je suivais à l’époque attentivement un jeu complet en développement : Exil. Son concepteur développait son propre moteur. Il abandonna cette idée et migra sur l’Unreal Engine à la sortie de l’UDK, l’aubaine était trop  belle. L’univers me plaisant et la programmation me gonflant de plus en plus, je proposais ma candidature et intégrais l’équipe en tant que mappeur/modeleur (il est difficile de n’être que mappeur sous l’Unreal Engine). Je pouvais ainsi mapper des endroits sombres et contrastés, dans un jeu solo ! Le bonheur fut de courte durée (quelques semaines avant que le projet s’arrête), mais mis une fin définitive à Unreal Safari.

http://www.udk.com/

http://www.makesomethingunreal.com/

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

Mais alors, qu’aurais-je donc pu faire pour sauver Unreal Safari ?

Faire le post-mortem d’Unreal Safari m’a donné beaucoup de nostalgie et je regrette de ne pas l’avoir poussé plus loin. Cette série d’articles m’a apporté un recul que je n’avais pas imaginé à l’origine. En déterrant les bouts de code, les models, les maps et les concepts, je me suis aperçu que j’ai eu les yeux plus gros que le ventre. Tant que j’ai su rester simple, j’ai fait des releases de produits finis et honorables. Dès que j’ai décidé d’attendre une release plus complète, le travail restant est devenu trop grand. Si j’avais voulu faire une Totale Conversion, il fallait accepter l’idée de recruter des gens. Ce qui était pour moi inacceptable, ne voulant avoir à gérer des gens et des personnalités. C’est un choix de ma part et l’avenir me donnera (j’espère) raison.

Ce que j’aurais du faire, c’est développer le game type Safari. Ajouter un HUD plus personnalisé, des messages plus originaux, un écran en début de partie pour choisir son équipe… Cela m’aurait apporté beaucoup et le game type aurait gagné en personnalité et en originalité. Cela aurait été plus qu’une idée sympa.

L’autre idée (en lien avec la précédent) aurait été de développer des maps pour le game type Safari. Ces maps auraient pu être jouables aussi bien en Deathmatch par équipe qu’en mode Safari. L’occasion de faire jouer sur mes maps et de promouvoir mon game-type en quelque sorte.

Je tiens à préciser qu’en faisant le post-mortem du game-type Safari, il y a une part de moi qui me pousse à en reprendre le développement (notamment car j’ai beaucoup progressé en programmation et que ça me demanderait moins de temps). Mais il est vrai que la communauté UT3 étant tellement petite (et ça ne s’est pas arrangé avec le temps j’imagine), je ne pense pas que je reprendrai ce mode de jeu pour en faire une version 2.0.

Quel bilan en tirer ?

Unreal Safari fut une histoire fantastique et dura près d’un an et demi. Si le fait de vouloir faire une Totale Conversion fut une erreur évidente, elle m’a permis de toucher à tout et de pouvoir lancer mon projet suivant, Little God Story, en connaissance de cause ! De plus, l’apprentissage et l’amélioration de mes techniques lors du projet furent colossales. Je suis parti de très bas pour arriver à faire plein de choses, dans des domaines assez différents.

Même si Unreal Safari n’a pas eu un rayonnement énorme (c’est peu de le dire…), j’ai pu m’apercevoir au bout de plusieurs mois que les différentes releases m’ont permis de changer un peu mon statut dans la communauté, au moins francophone. Quand j’ai présenté mon nouveau projet, je n’étais pas un pauvre noob rêveur. J’avais une expérience concrète, prouvée par des réalisations correctes et surtout publiées. Faire un bout de map impressionnant, c’est à la portée de beaucoup. Faire une jolie map avec une gameplay qui tient la route sans que ça rame, c’est plus difficile. La plupart de mes maps sous Source avaient d’ailleurs fini à la poubelle pour des problèmes d’optimisation.

La sortie de l’UDK m’a permis également d’avoir un statut plus élevé du jour au lendemain. En effet, les développeurs UT3 étaient rares et quand l’UDK est sorti, beaucoup de projets ont vu le jour. Mais un nouvel outil demande un apprentissage. Du jour au lendemain, je devenais quelqu’un d’expérimenté ! Cette prise de conscience et ces réalisations m’ont fait prendre confiance en moi et c’est pour cela que j’ose, aujourd’hui, rédiger des tutoriaux sur l’Unreal Script.

Ce post-mortem est désormais terminé. J’espère que vous l’aurez trouvé intéressant et surtout pas trop narcissique. J’espère surtout qu’il servira aux personnes qui se lancent dans le modding. Car si j’ai fait des erreurs, j’ai fait également à des moments de bons choix qui m’ont permis d’avancer. Tout moddeur rêve de faire son jeu stand-alone qui déchire et qui surpassera Crysis et/ou Stalker. Il ne faut pas hésiter à être plus modeste et/ou plus original. L’industrie du jeu vidéo nous apporte de plus en plus de jeux formatés, alors si les moddeurs se formatent également, on peut dire adieu à l’originalité…

Unreal Safari : Post-mortem (5)

Jeudi 22 juillet 2010

unrealsafari

Depuis le début, on assiste dans ce post-mortem à des réalisations (modestes) mais le mod final est très loin d’être accompli. A partir de maintenant, plus aucune release ne sera faite. Commençons donc à nous intéresser à ce qui a été démarré et n’a jamais été terminé…

Map : SAF-Gizeh

Parlons d’abord mapping. Une fois le prototype de gameplay codé, j’ai pu m’atteler au level-design. Intelligemment, j’ai repris le thème de Gizeh en premier, histoire de réutiliser tout ce qui avait été fait auparavant. Contrairement à ce que j’avais prévu, la map WAR-Gizeh ne me sera d’aucun secours, le gameplay s’étant trop éloigné du mode Warfare d’Unreal Tournament III. En effet, en terme de level-design, l’une des particularités à exploiter est le (double) saut des gazelles. Cela me servira de référence pour construire les immeubles. L’idée est de faire des étages d’une hauteur telle que les gazelles puissent les atteindre et pas les hippopotames. Les premières ébauches sont très encourageantes. On peut sauter à travers les fenêtres, monter sur les toits… Sans être difficile, cela demande un minimum de prise en main (et donc du skill).

Le level-design doit donc comporter des ruelles et des petits immeubles pour être intéressant. De plus, je souhaite ajouter plus de passages intérieurs (où les gazelles seront désavantagées). Au final, je réutiliserai peu d’assets de WAR-Gizeh. D’autant plus que je me suis amélioré en terme de modélisation 3D. Je parviens à faire des modèles mieux texturés, plus fins. Je retouche donc certains modèles et refais entièrement d’autres.

improvement02 improvement03

Je me recentre aussi sur le monde d’Unreal Safari. J’ajoute un peu d’humour, un côté plus décalé et essaye de faire vivre le monde. Pour cela j’ajoute des petits objets colorés, des enseignes, des pancartes… Ceci me permet également de varier la palette de couleur (WAR-Gizeh était trop jaune dans l’ensemble). Sans revenir à l’idée d’un aspect cartoon, je donne un côté un peu rafraîchissant au mod, revenant aux idées de départ.

Cette map a atteint un niveau respectable. Je n’étais plus très loin d’une version beta testable. En tout cas, le gameplay fonctionnait bien et il y avait de quoi exploiter les caractéristiques des uns et des autres. Graphiquement également, elle a vu une amélioration nette de mes compétences. En effet, des gens ont commencé à s’intéresser à Unreal Safari pour son aspect graphique à partir de cette map. Ce n’était pas le cas avant.

gizeh_wip_15 gizeh_wip_14 gizeh_wip_11

Programmation

En terme de programmation, bien que le gameplay soit codé entièrement (jusqu’à nouveaux tests, ajustements et ajouts de features éventuelles), je n’étais pas en reste. Le game type Safari ayant atteint sa version finale, j’ai commencé à le modifier pour l’adapter à Unreal Safari. Ainsi, on n’était plus dans la “Heavy Team” mais chez les “Hippos”. De même, on ne passait plus “Niveau 4″ mais “Wild Beast”. Avec le recul, je me dis que j’aurais du intégrer ce genre de personnalisation directement dans Safari. Ce côté personnel, original, voire drôle aurait pu donner un coup de pouce par sympathie. En voulant faire quelque chose de générique, j’avais fait quelque chose de banal.

En terme de programmation, il me fallait faire également un HUD personnalisé. Contrairement à ce que l’on peut croire, c’est plus dur que l’on ne croit. En fait, pour faire un HUD, il faut avant tout supprimer tout ce qui existe. Par exemple, le score des bleus s’affiche en bleu. En fait, le moteur récupère une partie d’une texture blanc/gris puis la colore en bleu. Cela évite d’avoir des textures différentes pour chaque équipe. Cette optimisation est une bonne idée m’a posé le problème suivant : j’ai conçu mon HUD à partir de fruits (kiwi, oranges…) qui sont déjà colorés. Je devais donc trouver quelle partie du code colorait le HUD et la supprimer. Ceci n’est évidemment qu’un exemple parmi d’autres…

Un HUD est un bon moyen de personnaliser son jeu. Si j’aime les HUD discrets, je voulais ici apposer un côté cartoon. Le résultat n’était pas forcément de bon goût, mais il permettait au mod de se différencier. Je me suis aperçu qu’il est très difficile de faire quelque chose de plaisant pour tout le monde. Certains voulaient que tout soit affiché à l’écran (points d’XP, points d’XP restants pour le prochain niveau, équipe, score, frags, points de vie, munition, équipe…) et d’autres qu’il n’y ait rien et que l’on puisse tout afficher d’une pression d’une touche.

Autre point de programmation pas si évident à supprimer, ce sont tous les messages, annonces et voix intégrés au jeu. Par exemple, une voix annonce “il reste 5 frags avant la victoire”. Sauf que, techniquement, dans Unreal Safari on peut perdre des points (c’est ce qui en fait l’intérêt évidemment). Donc il peut arriver que cette annonce soit faite 3 fois en 30 secondes… C’est dans ces détails que la programmation devient désespérante. Comme dit sur le blog Conquérir le monde, quand on a fait 90% du travail, il reste 90% à faire. Et dans ce cas-là, c’est 90% qui n’apportent RIEN en terme de plaisir de jeu. Qui plus est, c’est souvent pénible à tester…

hud

http://conquerirlemonde.com/blog/category/creation-de-jeux-video/

Arme : L’AK-Banana

Avec l’AK-Banana, je suis persuadé d’avoir trouvé l’arme qui déchire et qui va faire le succès de mon mod. Le nom sonne bien, l’AK-47, l’arme originale, est très appréciée des joueurs et son design, avec deux banane à la place du chargeur est vraiment sympa. Le problème de cette arme, c’est qu’elle n’a pas d’équivalent. Je n’ai pas trouvé réellement de quoi faire d’autres armes sympas. La seule idée sympa était les grenades en noix de coco. J’avais vraiment envie de faire des armes originales .Mon influence originale était les armes de Prey qui m’avaient marqué par leur design. Même si je n’y avais pas joué à l’époque, Zeno Clash est dans la même veine avec ses armes classiques dans le fonctionnement mais originales dans leur design. Pour cet aspect-là d’Unreal Safari, j’ai simplement manqué de créativité. Peut-être que le fait de développer seul montrait ses limites.

Etant très moyen en modélisation, la création de l’AK-Banana fut douloureuse et n’atteindra pas les objectifs de départ. Cependant, son design décalé pouvait détourner (un peu) de la modélisation grossière. Il est intéressant de voir que sur mon projet actuel, c’est encore une fois l’arme qui pêche par sa modélisation.

Au niveau réussite, l’AK-Banana sera modélisé, animé et importé dans le jeu. Même si les animations sont extrêmement sommaires, sans les mains du joueurs et que l’arme n’est pas codé (cela reste un skin du Shockrifle), c’est une véritable victoire. C’est la première fois que j’arrive à importer une arme dans un jeu ! (et ce n’est pas faute d’avoir essayé, notamment quand j’essayais de modder sur Far Cry).

Au niveau échec, je n’arriverais jamais à me lancer dans le coding de l’arme (système de chargeur avec reloading, type d’impact, muzzleflash (étincelle et fumée au bout du canon). Techniquement, les armes d’UT3 étaient trop compliqué pour moi. Trop de fonctions, de paramètres à gérer, cela était incompréhensible à l’époque. Or, si je ne personnalisais pas un minimum mes armes, quel intérêt de faire une conversion totale ? En effet, il existe des mods qui reprennent le feeling du jeu original en opérant essentiellement une refonte graphique (Galactic Warfare pour Call of Duty 4 par exemple). Sans critiquer ce genre de mods, ce n’est pas ce que je recherchais.

akbanana_wip_02

http://www.moddb.com/mods/star-wars-mod-galactic-warfare

Personnage : L’Hippopotame

Je suis parvenu à faire un personnage assez simple : l’Hippopotame. Sa modélisation assez ronde était correcte même si son texturing l’aurait rendu très statique. Je pense que je me rapprochais de Bisounours Party dans le rendu. Je me voyais déjà avec une sorte de peluche mal articulée… Ceci n’arriva jamais puisque je n’ai jamais fait le rigging (c’est-à-dire le squelette du personnage) et donc encore moins l’animation.

hippo_wip_03a

http://www.moddb.com/mods/bisounours-party

Dans le prochain article, on verra les multiples (et surprenantes !) raisons qui m’ont poussé à arrêter le développement d’Unreal Safari.

Unreal Safari : Post-mortem (4)

Mercredi 21 juillet 2010

unrealsafari

Premier game type:  Safari

Pour information : la plupart des problèmes techniques que j’ai rencontré sur ce game type, je les ai traités par une série de tutoriels publiés sur ce même blog. Je conseille donc aux lecteurs de mes tutoriels de récupérer les sources de Safari afin de les lire. Elles seront un très bon compléments aux tutoriels.

Après avoir publié mon premier mutator, je me lance dans la conception de la deuxième partie du gameplay : la partie niveau/expérience et bonus/malus. Le but est, je le rappelle, de faire que les niveaux des joueurs influent sur le nombre de points qu’ils marquent lorsqu’ils fraggent quelqu’un. Schématiquement, quand un noob tue le meilleur joueur, il fait gagner 10 points à l’équipe, alors que quand le meilleur joueur tue un noob, il ne fait gagner qu’un point. Le tout avec 6 niveaux possibles de jeu, sachant que l’on peut perdre un niveau si on se fait fragger.

Très rapidement, je m’aperçois qu’intégrer deux mutators dans un même game type peut amener des problèmes de conflits entre eux. Je décidé alors de développer un game type, Safari, qui intègrera d’office le mutator Opposite Team. Contrairement à ce que l’on peut croire, cette histoire de niveau m’a posé beaucoup de problèmes. D’abord parce-que certaines fonctions que j’avais utilisé auparavant n’existaient que pour les mutators. De plus, ce système est beaucoup plus perméable aux bugs de fonctionnement (remise à niveau des points d’XP ou du score, problème dans le décompte des points…). Bref, plutôt qu’une adaptation d’un tutoriel existant, je me suis rapproché un peu du vrai boulot du programmeur : traquer les bugs ! Ce game type m’a aussi montré les problèmes inhérent au jeu multijoueur. En effet, la programmation ne se fait pas de la même façon pour un jeu solo ou un jeu multi. Ce côté plus complexe m’a obligé à comprendre un minimum ce que je faisais et j’ai commencé à mieux appréhender l’Unreal Script.

Autre problème : quand on fait un jeu avec des points d’expérience et des gains de niveau, on est un peu obligé de les afficher à l’écran. La première version de Safari (non publiée) était fonctionnelle mais opaque. Impossible de voir quoi que ce soit. J’ai donc commencé à travailler sur un HUD et un système de message. Pour simplifier, il me fallait :

1 - un affichage à l’écran permanent du niveau, des points d’XP, de l’équipe et du nombre de frags
2 - un message annonçant un changement de niveau (positif ou négatif)
3 - un message affichant le nombre de points d’XP gagné lors d’un frag

Ce genre d’aspect paraît relativement simple mais quand on est un débutant en programmation, tout est compliqué. Au niveau des messages, j’ai vite su faire deux messages différents : l’un disait qu’on avait gagné un niveau et s’affichait en vert, le deuxième disait qu’on avait perdu un niveau et s’affichait en orange. Très vite, il a paru essentiel de remplacer “Level Up !” par “You are Level 2 !” Après des difficultés, j’ai commencé par créer une classe par niveau. Ce qui me donnait en gros :

LevelUpOne.uc
LevelDownOne .uc
LevelUpTwo.uc
LevelDownTwo.uc

Et ainsi de suite pour les six niveaux. On voit très bien les problèmes. Car si multiplier les classes est déjà pénible et peu optimisé, c’est encore plus compliqué à l’intérieur du code (je vais essayer d’expliquer ça simplement). Quand on change de niveau (c’est détectable par du code assez simplement), le jeu envoie un message. Si les classes de messages sont séparées comme ici, on doit alors mettre des conditions :

Si je suis niveau 1 -> Message 1
Si je suis niveau 2 -> Message 2
Si je suis niveau 3 -> Message 3

Et ceci, une fois pour les gains de niveau, puis pareil pour les pertes de niveaux. Même avec seulement 6 niveaux, cela faisait des lignes de codes à n’en plus finir. Or, ajouter des lignes de code, c’est s’ajouter des risques de bugs. J’ai donc appris à optimiser un peu mes messages afin de faire :

Si je suis niveau X -> MessageUp (X)

Evidemment, il faut faire la même chose si on perd un niveau. Cette façon de faire est beaucoup plus souple également si l’on souhaite changer des choses plus tard (par exemple ajouter 5 niveaux supplémentaires !). Avec le recul, je pense qu’il est tout à fait possible d’intégrer la notion de perte/gain dans une classe de message générique, mais le gain n’était pas forcément énorme. Cette “optimisation” (car après tout faire le bourrin fonctionnait très bien !) me permettra plus tard de coder des messages qui affiche le nombre de points d’XP gagnés lors d’un frag. Pour information, le fait d’afficher le niveau qu’on a atteint lorsque l’on change de niveau n’arrivera qu’à la toute dernière version du game type !

Au niveau du HUD, je n’ai pas rencontré de difficulté fondamentale si ce n’est mon inexpérience. L’affichage d’un HUD permet aussi de débugguer le code car on a accès aux changements de données en temps réel (quand le HUD fonctionne en tout cas !). Avec le recul, c’est peut-être une des premières choses à faire quand on code un game type un peu différent.

La première beta de Safari souffre de quelques bugs que je considère comme mineurs mais qui seront abhorrés par les joueurs. Par exemple, quand on respawne, un freeze de l’écran dure une seconde. En arrivant à corriger ce genre de bugs, je me suis senti pour la première fois un programmeur.

Octobre 2009 : je publie la version 1.0 de Safari. La version est tellement proche du gameplay que je souhaite pour Unreal Safari que je décide d’apposer ma “marque” sur le nom. Ce game type intègre les deux composantes du gameplay final : expérience et équipes opposés. Techniquement, cette version est stable et fonctionnelle. Cette release aura un impact plus fort encore que les autres sur la visibilité d’Unreal Safari. En effet, en lui donnant un nom extrêmement proche, j’alimente la confusion entre le game type (=Safari) et le mod (=Unreal Safari). Résultat des courses : ModDB annonce la release de mon mod en première page et l’intègre dans les releases de sa newsletter. A ce moment là, j’atteins des pics de fréquentation sur la page d’Unreal Safari.

safari3 safari4

Malgré tout, le game play Safari reste très confidentiel (à cause d’une communauté restreinte) mais les retours sont plutôt positifs. Je travaille sur une version 1.1 publiée un mois plus tard et apportant des changements importants comme le support des bots ou l’affichage des points d’XP gagnés ou perdus lors d’un frag. J’en profite pour préciser que si une release est toujours un moment excitant, publier un correctif ou une nouvelle version est encore plus fort. En effet, on a vraiment l’impression de progresser en lisant la liste des améliorations apportées.

Au niveau des releases, j’ai impliqué une nouvelle fois la communauté française. J’ai ainsi publié le game-type sur les forums spécialisés. Une fois que j’ai pu constater qu’il n’y avait pas de bug majeur, je lançais une release plus large sur des forums et sites plus fréquentés (forums Epic, BeyondUnreal et bien sûr ModDB). J’en profite pour remercier une nouvelle fois la communauté Unreal.fr, dont les conseils en terme de gameplay sont toujours pertinents !

Au final, la mise en place du gameplay Safari m’a permis de vraiment comprendre comment fonctionnait le code de l’Unreal Script et m’a obligé à apprendre à la débugguer et surtout l’optimiser. La version 1.1, aboutie et fonctionnelle, est la preuve vivante que l’Unreal Script (contrairement à ce qu’on lit partout !) est facile d’accès si on est prêt à mettre les mains dans le cambouis. En partant de zéro, il m’aura fallu 4 mois environ pour coder un game type pas si simpliste qui fasse pas trop bidouillé (c’est-à-dire avec un habillage cosmétique cohérent et ergonomique).

Avec le recul, ce game type est peut-être mon plus grand accomplissement dans l’aventure Unreal Safari. Car j’ai ajouté une cartouche à mon fusil de moddeur : celle de programmeur. Et vu le manque de codeurs dans le paysage du modding, ce n’est pas rien !

http://www.moddb.com/mods/unreal-safari/downloads/safari-11-game-type

Unreal Safari : Post-mortem (3)

Mardi 20 juillet 2010

unrealsafari

Premier mutator : Opposite Team

Après avoir publié une map, j’ai pris la décision de me lancer dans la programmation. En effet, j’ai eu conscience à ce moment là que tant que je n’aurais pas un embryon de gameplay codé, je ne pourrais pas réellement faire du level-design. Un exemple simple pour illustrer ça : certains animaux sautent plus haut que les autres et un des intérêts est de pouvoir prendre des raccourcis auxquels les autres animaux n’ont pas accès. Mais tant que je ne sais pas à quelle hauteur saute tel animal, difficile de construire une map…

Dans le cadre d’une modification d’un jeu Unreal Tournament 3, il y a plusieurs niveaux :

1 - le mutator : change un aspect mineur du jeu (par exemple, les joueurs démarrent avec un seul point de vie)
2 - le game type : change les règles du jeu (par exemple, un capture the flag avec un seul flag central)
3 - le mod : change le game-type mais aussi des éléments du jeu (par exemple, de nouvelles armes)
4 - la totale conversion (TC): change entièrement le jeu (normalement, on ne doit plus voir que l’on joue à UT3)

Evidemment, comme beaucoup de modders, mon rêve était la TC. C’est la façon de modder la plus prestigieuse mais aussi la plus difficile. M’appuyant sur des tutoriaux, je décide de faire petit à petit, à savoir de faire d’abord un mutator, de le complexifier en game-type, puis d’ajouter les armes, puis de tout finaliser. Je pense que c’est à ce moment que j’ai pris la meilleure décision… En effet, en devant coder du gameplay, ça me poussait à fixer mon gameplay.

C’est à ce moment-là que j’ai finalisé mon gameplay. Au final, il était bien plus original qu’à l’origine. Il se basait sur deux équipes, les hippopotames et les gazelles. Deux idées principales fixaient le gameplay :

1 - Les deux équipes sont très différentes : les hippopotames sont lents mais résistants, les gazelles sont rapides, sautent haut mais meurent vite
2 - Quand un joueur fragge un autre, il gagne un certain nombre d’XP et le joueur fraggé en perd… De plus, tuer un bon joueur rapporte plus de points d’XP.

Pour la première idée, rien de très nouveau, cela a déjà été exploité, mais je préférais cette idée à un système de classe encore plus classique et utilisé dans 90% des mods existants… La deuxième idée, avec la perte d’un niveau, était selon moi plus originale. En effet, il devenait possible de perdre un niveau (qui représentait plutôt le skill plus que l’expérience d’ailleurs). De plus, le meilleur joueur devient clairement l’homme à abattre. Plutôt que de le fuir (oui, je suis comme ça, j’avoue), ça vaut le coup d’essayer de l’abattre. C’est valorisant pour un noob qui peut devenir utile à l’équipe (car plus on est nul, plus on rapporte de points quand on fraggue). Ce sentiment d’injustice est compensé par le fait qu’un gros joueur se sent une grosse responsabilité : il ne doit absolument pas mourir.

L’idée de départ était de développer un mutator pour chaque idée et de les mixer dans un game type. En effet, développer un mutator (simple) n’est pas trop compliqué avec les tutoriaux adaptés. Le tout est d’avoir une idée. Au final, je ferai différemment.

oppositeteam1-1

Je commençais donc à coder le premier mutator (avec les équipes antagonistes) : Opposite Team. Bien qu’annoncé comme une part d’une future Unreal Safari, j’avais alors prévu de le publier, afin de tester son effet réel, de me faire de la pub. En effet, une release, c’est toujours mieux qu’un screenshot (sauf si elle est bugguée à mort bien sûr). Je passe sur les difficultés pour un noob de la programmation Unreal Script (je n’avais codé qu’en Visual Basic des années avant et uniquement des choses très simples). Globalement, ce ne fut pas très compliqué, et j’ai pu ne publier qu’une version, car elle était fonctionnelle. Par contre, graphiquement, le tout était très limité. Peut-être ai-je négligé à ce moment-là l’aspect cosmétique (changer la phrase : “You are in Red Team” en “You are in Heavy Team”).

Une nouvelle fois, je m’appuyais sur la communauté pour tester et critiquer mon travail. Je publiais également le code du mutator afin d’aider les apprentis codeurs (je le conseille toujours d’ailleurs pour ceux qui se lancent là-dedans). La communauté a confirmé plusieurs choses très importantes

1 - pas de bug
2 - équilibrage correct
3 - idée sympathique et rafraîchissante

Certains détails inhérents à UT3 m’étaient complètement passé au-dessus de la tête. Ainsi, un joueur m’a dit que le gros avantage de l’équipe rapide était d’aller piquer les power-ups… Je n’y avais pas du tout pensé ! Encore une fois, il est essentiel de tester son jeu aussi bien avec des joueurs moyens qu’avec des joueurs aguerris.

Outre le fait de me prouver que j’étais capable de programmer, j’ai augmenté la visibilité de mon travail et eu un début de confirmation que les idées de gameplay d’Unreal Safari pouvaient être sympas. En revanche, en tant que mutator, Opposite Team n’a a priori pas eu de succès. Il faut dire que la promotion a été minimale. Ici, j’ai peut-être été pénalisé par le fait que je jouais peu à UT3. N’étant pas régulier sur certains serveurs, je n’ai pas eu l’occasion de le faire implanter afin d’élargir ma publication. Après, il faut aussi rappeler qu’UT3 étant peu joué, un mutator anecdotique a peu de chances de trouver un endroit où être joué !

En conclusion, aussi simpliste soit Opposite Team pour un codeur expérimenté, une fois encore j’ai publié quelque chose. J’ai finalisé une partie de mon projet. Je me suis prouvé que j’étais capable de programmer quelque chose tout comme je m’étais prouvé que je pouvais publier une map correcte. Et à force de publier des créations, on prend confiance. De façon plus narcissique, publier des produits finis permet aussi plus tard d’être pris au sérieux lorsque l’on veut intégrer une équipe (sérieuse). Avoir modélisé une salle ou avoir des bouts de code, ça ne sert pas à grand chose. Mieux vaut voir petit, faire simple et finir les choses. Car finir les choses, ça amène d’autres problèmes, comme la correction de bugs. On en avait parlé pour WAR-Gizeh, on en reparlera dans la prochaine partie !

http://www.moddb.com/mods/unreal-safari/downloads/opposite-team-mutator

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

Unreal Safari : Post-mortem (1)

Dimanche 11 juillet 2010

Introduction

En juin 2008, lassé par les problèmes d’optimisation de mes maps pour Counter-Strike : Source, fatigué d’être bridé pour les éclairages (notamment dynamiques), je décide d’acheter Unreal Tournament III pour pouvoir faire les maps de mes rêves. En substance, j’espère créer un mod, ayant toujours plein d’idées pour ça. Au départ, j’espère qu’un de mes concepts amènera du monde et que je ne serais “que” mappeur/level-designer/game-designer/leader. Bref, un grand classique du newbie qui va se planter.

Je pense qu’il est important de préciser mes compétences de l’époque.

Mapping (trois maps publiées)
gg_techcenter (version finale) : une map simple avec un design 90% custom, plutôt bien accueillie
cs_bladerunner (version beta) : une map à objectif bien accueillie, graphiquement originale et avec une gameplay qui tient la route
gg_paintball 69 (version beta) : une map sur commande, très incomplète et moche

Modeling
Beaucoup de bidouillages. Les modèles 3D sont souvent très simples et/ou comportant des défauts majeurs de modélisation. Quelques modèles simples (caisses, cylindres, tuyaux) ont été intégrés à mes maps et n’ont pas choqué.

Programmation
Des notions de base. Programmation sur calculatrice, maple (à visée purement mathématique) et programmation d’un casse-brique (très peu abouti) en Visual Basic.

A la vue de tout ceci, il paraît inconcevable que, quelques semaines plus tard, je décide de me lancer dans une Total Conversion (TC) pour Unreal Tournament III ! (je rappelle qu’une TC est un mod qui change absolument TOUT dans un jeu. On a l’impression que c’est un nouveau. Cela demande un travail colossal).

Le concept

Le concept de base d’Unreal Safari est assez ambitieux. Le jeu est multijoueur, 4 classes sont jouables, 3 modes de jeu, le tout dans plusieurs environnements différents.

Les classes : ce sont ici des animaux, chacun possédant ses caractéristiques (essentiellement la vitesse, hauteur de saut, armure, points de vie et mana), une arme de prédilection et une attaque spéciale.

Les modes de jeu : ils évolueront beaucoup, mais au départ l’idée est de faire une refonte du mode Warfare d’UT3, du Team Deathmatch et un mode Hunt où un joueur joue contre tous les autres. Tout ceci sera affiné par la suite. A ce moment là, j’ai plus un univers graphique en tête plus qu’un gameplay défini.

Les armes : Les armes sont des versions modifiées d’armes existantes. Toutes fonctionnent avec des bananes comme chargeur.

Les environnements : L’originalité ici est l’Afrique (même si Far Cry 2 l’a exploité). Les environnement prévus étaient Gizeh (désert et Afrique du Nord),  Madagascar (île luxuriante), Offshore (plateformes pétrolières) et Kilimandjaro (savane).

A cela, j’ajoute l’idée d’un graphisme cartoon pour compenser mes lacunes en modélisation et un aspect humour. Cet aspect humour, que j’intègre à la base à toutes mes productions, est souvent le plus difficile à garder pour plein de raisons. J’y reviendrai plus tard. Au final, Unreal Safari avait un concept assez proche de mods comme Bisounours Party.

Un game-design document est réalisé, assez précis, des concepts et des artworks sont dessinés. Tout est prêt. Il ne reste plus qu’à s’y mettre.

premier palmier, type cartoon !

premier palmier, type cartoon !

Les premiers pas

Rapidement je prends conscience que j’y arriverai jamais. Je décide alors de couper le mod en releases “par morceaux”. Dans la première, il n’y aura “que” deux personnages et armes jouables, sur une seule map, dans un seul mode de jeu. Cela peut paraître restrictif (et ça l’est !), mais il était essentiel de définir un objectif atteignable afin de garder la motivation. Cependant, aussi “petit” soit cet objectif, il était déjà démesuré étant donné que la plupart des choses à faire pour ce mod, je ne savais pas du tout comment les effectuer…

Comme c’est ce que je sais faire de mieux, je pars dans la conception des maps. C’était une erreur magistrale (comme on verra dans le détail plus tard). En effet, sans un embryon de gameplay ou de programmation, difficile de faire du level-design efficace.

Etant seul, je dois faire un choix et ne pas m’éparpiller. Je dois choisir un environnement, créer des modèles et textures correspondants et faire une map dans un mode de jeu donné. Evidemment, je vais rapidement changer mes choix et passer d’un environnement à l’autre. Si certaines choses pourront être récupérées (caisses, tables, ponton…), beaucoup sont trop typées pour cela (pyramides, obélisques…) .

Gizeh - première version

Gizeh - première version

A l’origine, je démarre par l’environnement Gizeh et ses pyramides. Le côté égyptien étant assez attractif, l’impact visuel est vite sympa. On remarque que dans les tous premiers modèles, j’essaie d’incorporer un côté fun. Cela doit détourner les éventuels joueurs du fait que mes modèles sont très (même trop) simples. Faire tous mes modèles 3D me prend beaucoup de temps pour des résultats pas toujours concluant. J’abandonne rapidement le fait de devoir faire un aspect cartoon (pour les maps en tout cas) qui est finalement plus difficile à faire que de faire quelque chose de réaliste.

Je finis par abandonner Gizeh et me lance dans l’environnement Kilimandjaro. Il en sort des trucs sympas, mais la map en elle-même, pour un mode typé Warfare, est beaucoup trop petite et trop plate. Cependant, je fais de gros progrès en ajoutant pas mal de features qui m’avaient incité à passer sur UT3 au départ : effets postprocess (bloom, deep of field), eau plus réaliste… Je travaille également sur les terrains et fais de gros progrès. Cela me semble plus intuitif que les displacements sous Source. Avec les textures made in UT3, ils rendent tout de suite de façon sympathique. Cependant, les défauts de level-design sont trop importants et je décide d’abandonner de nouveau cette map pour travailler sur une map TDM dans le milieu Offshore. Deux avantages pour cela : je peux utiliser les modèles d’UT3 et la map sera plus petite.

Kilimandjaro

WAR-Kilimandjaro

DM-Offshore m’a permis de comprendre beaucoup de choses sur le fonctionnement de l’UnrealEditor. Au lieu de focaliser sur la création d’assets, je pouvais faire du mapping pur (comme au temps où j’utilisais Source). Cela m’a permis de travailler notamment les éclairages (qui sont certainement l’un de mes points forts en mapping). Rapidement, je me suis aperçu que l’UnrealEngine n’était pas forcément l’eldorado tant attendu.

L’autre problème est que les modèles d’UT3 sont particulièrement beaux. Résultat : à côté des miens, on voit trop la différence. L’idée de pouvoir utiliser les modèles d’UT3 s’est vite estompée, à part pour des cas particulier, notamment naturels (eau, cascade, arbres, plantes, ciel, etc.).
A ce moment là, mon ordinateur a planté, m’obligeant à formater le tout. Je n’ai pas tout perdu pour autant (heureusement), mais cela m’a incité à tout reprendre. J’ai alors retravaillé entièrement les layers de mes maps et suis reparti sur l’environnement (jaune) de Gizeh. On pourrait croire que j’ai beaucoup tourné en rond en quelques mois (on est en février 2009, soit 6 mois après le début du projet), mais comme je ne connaissais rien à l’Unreal Editor et que je modélisais à la truelle, les avancées ont été importantes, bien que rien ne soit réellement utilisable pour un futur mod.
La suite au prochain épisode, avec les premières releases !

DM-Offhore

DM-Offshore

Quelques liens en rapport avec l’article :

Unreal Safari : http://www.moddb.com/mods/unreal-safari
Bisounours Party : http://www.moddb.com/mods/bisounours-party
gg_techcenter : http://www.fpsbanana.com/maps/51213
gg_paintball69 : http://www.fpsbanana.com/maps/55405
cs_bladerunner : http://www.fpsbanana.com/maps/55119