Unreal Safari : Post-mortem (3)

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

3 commentaires à propos de “Unreal Safari : Post-mortem (3)”

  1. Très intéressants, effectivement. Preuve que c’est bien écrit, j’ai aucune connaissances dans le domaines, mais j’apprécie quand même. Vivement la suite!

Répondre à drytaffin Annuler la réponse

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*