Wildstar – Interview : le moteur de jeu #1

ZAM a eu l'occasion de discuter un moment avec Steve Moret, Lead Software Engineer, et d'en savoir un peu plus sur le moteur de jeu grâce auquel la planète Nexus de WildStar vit. Petite traduction pour vous !

Quel est le nom du moteur de jeu de WildStar ?

C'est drôle que vous demandiez parce que WildStar est rempli de choses savoureuses avec des consommateurs de bière, des fumeurs de cigares ou ces mercenaires rocker Granok, notre code de base est très générique, tout reposant sur un nom très bateau, Moteur (Engine), le nom de notre moteur. Avec un nom aussi créatif, ça risque d'être un choc pour vous de savoir que tout le code spécifique de WildStar est regroupé dans un projet appelé Jeu (Game). Tandis que l'exécutable que vous utilisez pour vous connecter à nos serveurs s'appelle Client. Vous ne devinerez jamais quel est le nom de notre exécutable Serveur (ou peut-être que si..).

Non, nous n'avons pas fait ça parce que nos ingénieurs sont ennuyeux et sans goût. Au contraire, les idées et le code qui compose WildStar  ont été/sont régulièrement changés. Des noms fantaisistes auraient eu besoin d'être changés pour ne pas créer de confusion. De plus, des noms atypiques rendraient plus difficile la distinctions de parties des codes ; ou sur le côté de la frontière dl'interface auquel un élément doit exister. Avec des lignes clairement définies, comme Moteur ou Jeu, c'est plus simple d'éviter de mettre par erreur un sort pour les joueurs dans le projet Réseau.

Quel est le point de départ pour un projet aussi ambitieux qu'un MMO ? Est-ce que vous commencez avec un produit du marché et construisez de là ou est-ce que vous commencez du début ?

La première étape pour nous a été de décider ce que nous pourrions utiliser dans le commerce et de voir où cela nous mènerait. En 2005, nous savions que nous aurions quelques années de Recherche & Développement, donc nous avons évalué quelques moteurs clés en main et, alors que ces moteurs offraient des graphismes sympas la première année, ils ne semblaient pas adaptés à nos besoins 5 ans plus tard. Nous avons décidé de dépenser la majorité de notre temps de travail à créer la bonne solution à chaque problème.

Heureusement, la majorité de nos problèmes étaient déjà connus. Beaucoup de Carbinites avaient récemment quitté Blizzard après le lancement de World of Warcraft. Pour être honnête, j'ai pu énumérer la plupart de nos futurs problèmes lors de mon entretien chez Carbine. Il était évident pour moi que dès le premier jour toute l'équipe savait déjà ce pour quoi nous signions. En fait, la plupart étaient excités et heureux de recommencer et, cette fois, de ne pas faire les mêmes erreurs qu'autrefois.

Quelles sont les éléments d'un moteur de jeu pour un MMO moderne à la fois du point de vue joueurs que ce que nous ne voyons pas ?

Bien entendu, les jeux sont différents, mais notre technologie chez Carbine est décomposée en 3 groupes/frontières (la plupart partagent des composants) : Clients, Serveurs et Outils. Les Clients concernent des choses comme le patcher, le client de jeu en lui-même et, assez étrangement, l'éditeur d'interface (comme l'éditeur va être utilisé par les joueurs, nous traitons notre éditeur d'interface comme une application Client et non un Outil). Les Serveurs sont là pour traiter les processus nécessaire pour gérer les tâches de fond (l'article du blog de David Ray en a parlé) et les Outils sont tous les outils utilisés par le jeu et le support client en jeu (les outils pour les GM, les enregistrements de logs, les rapports web et l'accès au jeu).

Ces grandes parties sont composées de nombreuses petites parties, comme une librairie du système d'exploitation, une librairie pour le réseau (pour la communication), une librairie graphique (pour dessiner de jolies choses), des librairies de bases de données pour écrire/lire les données, des librairies pour la création de graphes dans le cadre du pathfinding (méthode algorithmique consistant à calculer le plus court chemin entre 2 points), des langages de programmation (à la fois serveur et client), les simulateurs physiques, les gestionnaires d'entrée, les routines pour la manette, la localisation et plus encore... La plupart ne sont pas directement reconnaissables par l'utilisateur final, ils apprécient certainement que leur jeu soit bien dessiné et que leurs textes soient localisés dans leur langue mais, pour la plupart, ils sont inconscients de ce qu'il se passe et pourquoi.

Certaines des parties listées ci-dessus sont combinées pour former des couches encore plus complexes. C'est là que les fonctionnalités notables commencent à émerger. Par exemple, notre librairie graphique gère l'affichage des polygones à l'écran Notre système de modèles se trouve au-dessus, il gère et anime nos éléments modélisés. Notre système de costume est au-dessus du système de modèle et gère les textures modifiables et la géométrie de ces modèles.

Les calques du jeu sont composés de toutes ces petites et moyennes parties, ainsi que de nombreux contenus de jeu. Ces couches contiennent toute la logique qui vous donne de l'expérience quand vous complétez une quête, qui s'assure qu'un chemin valide existe entre vous et le monstre vers lequel vous voulez sauter ou pour s'assurer que votre avatar n'a plus son arme quand vous êtes désarmé par vos adversaires.

Ces systèmes de couches de jeux existent sous différentes formes dans les trois composants (Clients, Serveurs et Outils). Parfois de façon légèrement différente (par exemple, un Serveur ne sait pas dans quelle langue un joueur joue, et n'a même pas accès aux texte localisé) mais certains systèmes de quêtes existent sur plusieurs clients, Serveurs et Outils).

Lors de la construction d'un MMO, qu'est ce qui vient en premier, le client ou le serveur?

À mon avis, il vaut mieux faire les deux. Mais dans notre cas, nous avons fait un terrain simple et un rendu de modèle en premier (environ un mois ou deux de développement). Quelques mois plus tard, nous avions un serveur de base qui nous permettait de courir et de se voir les uns les autres (inutile de dire que c'est à ce moment que nous avons eu notre premier tricheur). Nous avons alors commencé à dispatcher les difficultés en couches. Chez Carbine, nos fonctionnalités sont toujours ajoutées au Client et au Serveur en même temps, généralement par le même programmeur. Anecdote : nous maintenons toujours un serveur indépendant, sans Client, nos artistes l'utilisent pour avoir un aperçu de leurs créations sans avoir à se connecter à un serveur.