Wildstar – Interview : le moteur de jeu #2

Deuxième partie de l'interview de ZAM en compagnie de Steve Moret, Lead Software Engineer, à propos du moteur de jeu de WildStar.

Comment équilibrez-vous ce qu'il faut exécuter côté serveur et côté client?

La règle générale chez Carbine est que nous traitons notre client comme un simple terminal qui est en train d'envoyer des données illicites tout le temps. Cela signifie que, fondamentalement, tout doit passer par le serveur pour validation.

Dans le même temps, nous supposons que vous avez des tonnes de latence. Je serais vraiment heureux si le monde avait une infrastructure réseau qui pouvait garantir un ping inférieur à 10 ms entre deux points du globe, mais à cause des  lois de la physique cela ne peut juste pas arriver. Nous supposons généralement que votre client a au moins 300 ms de latence. Cela signifie que nous devons simuler beaucoup de choses sur votre client alors que c'est en transit vers le serveur. Parfois, cela consiste à jouer une animation avant l'incantation d'un sort, juste pour obtenir le message "Cible invalide" car la cible est déjà morte. Nous avons constaté que c'est à peine perceptible contrairement au fait d'appuyer sur la touche d'attaque une fraction de seconde plus tard, mais je suppose que l'utilisateur final sera le juge final pour dire si nous cachons bien le lag.

A quoi ressemble le processus de développement ? Y'a t-il des similitudes avec les éditeurs de logiciels standards qui utilisent un processus Agile, ou est-il plus que cela ?

Nous avons un mélange de principes Agile ainsi que le modèle de cascade traditionnel du développement de logiciels. Alors que nous avons les traditionnels secteurs Graphisme, Audio, Conception et Services de programmation, beaucoup d'entre nous se sont divisé en équipes basées sur les fonctionnalités, dans un système Agile. Ces équipes gèrent les parties principales du jeu (comme le social, l'économie et les rencontres). Ils ont à la fois des réunions traditionnelles, longues et ennuyeuses, ainsi que des réunions quotidiennes de 10 minutes par jour. Nous n'avons pas vraiment de mêlée et de sprint, mais quelque chose dans le style.

Ce que nous faisons le plus ce sont les itérations. Les fonctionnalités sont réécrites et reconçues plusieurs fois avant qu'elles ne soient présentées à quiconque en dehors d'une équipe de fonctionnalité.

Quel est le stade de développement du moteur actuellement? Est-ce que le noyau est complet ou ajoutez-vous sans cesse de nouvelles fonctionnalités ?

Il est pour la majorité terminé, oui et oui. Comme je le disais, le noyau du moteur est terminé, nous sommes continuellement en train de faire des prototypes de nouveaux types d'objectifs de quêtes, de chemins de missions, d'aventures, de types de champs de bataille JcJ, de styles d'arène, de composants de Warplot, de choses à mettre dans votre maison et plus encore. L'objectif a toujours été d'avoir un moteur de MMO souple que nous pouvons continuer à maintenir pour toujours (c'est un peu effrayant d'y penser maintenant que je le dis). Nous aurons toujours besoin de nouveaux Boss, avec de nouvelles capacités et de nouveaux télégraphes, donnant au joueur du butin impressionnant avec de nouveaux effets. Tout cela va nous tenir continuellement en développement.

Pouvez-vous nous donner une idée de la complexité du moteur de WildStar et de la taille du projet, sur le plan de l'art, de la création de contenu et d'autres domaines du développement ?

Eh bien, nous avons beaucoup de code (dont 99% est du C++). Le moteur est d'environ 750.000 lignes, les parties spécifiques du client sont d'environ 250.000 lignes, les serveurs sont environ 500.000 lignes, et nous avons plus d'1,1 millions de lignes de code dans les quelques 130 outils que nous utilisons quotidiennement. Nous faisons également très attention à supprimer les projets non utilisés et à ne laisser aucun code commenté dans notre dépôt, donc imaginez que les 2,6 millions de lignes de code sont vivantes, actives, des parties importantes.

Notre département de programmation ne représente que 25 des employés de Carbine sur les 210 employés dont je suis au courant. Bien que, compte tenu des nombreuses offres d'emplois, ces chiffres aient légèrement changé au moment où cet article est publié.

Quel a été votre plus grand défi, né d'une demande de l'équipe de conception ?

Heureusement, cette fonctionnalité a été supprimée, donc je ne peux pas vraiment en parler. Mais des problèmes se posent régulièrement de la volonté de Carbo,e de dépasser ses limites et de l'attitude non conventionnelle de WildStar (go-buck). Certaines des meilleures idées prennent le plus d'espace en base de données du serveur et il y a des limites strictes sur ce que nous pouvons stocker, si nous voulons gérer le nombre de joueurs que nous espérons avoir (c'est à dire beaucoup). Ajoutez à cela un désir de ne pas supprimer les anciens comptes et nous finissons par avoir à tout faire rentrer dans 2-3 Mo de stockage par joueur. Pas génial.

L'exploration des joueurs était un excellent exemple de dépassement de cette limite. La taille et le nombre d'hexagones explorables devaient être soigneusement réglés pour ne pas nous coûter trop de stockage en base de données. Faire des hexagones trop petits, et nous avions besoin de centaines de méga-octets de stockage par joueur, faire des hexagones trop grand et vous n'aviez pas une quantité raisonnable de fidélité à afficher sur votre carte. J'espère que nous avons réussi à atteindre un bon équilibre où les joueurs n'ont pas à se soucier du coût par gigaoctet du stockage.

Est-ce qu'il y a une fonctionnalité du moteur WildStar dont vous êtes particulièrement fiers et que les autres jeux n'ont pas ?

Comme programmeur de Carbine, ma partie préférée du moteur est que les maths sont exprimés sous une syntaxe typique. Par exemple, quand on calcule l'interpolation barycentrique d'un triangle défini par les vectors v1, v2 et v3, et les coefficients scalaires f et g, vous pouvez juste taper :

CVector3 result = v1 + (v2 – v1) * f + (v3 – v1) * g;

De mes précédentes expériences dans les studios de développement de jeu, les librairies mathématiques étaient écrites en assembleur et la ligne ci-dessus serait écrit sous cette forme :

VectorSubtract(temp1, v2, v1);
VectorScaleFloat(temp2, temp1, f);
VectorAdd(temp3, v1, temp2);
VectorSubtract(temp4, v3, v1);
VectorScaleFloat(temp5, temp4, g);
VectorAdd(result, temp3, temp5);

Cela nous permet d'exprimer les maths d'une façon qui semble et paraît naturelle, et nous avons mis au point des techniques soignées à l'aide de templates C++ pour empêcher les copies temporaires en évaluant trop lentement lors d'une assignation. J'espère que d'autres studios de jeux prennent également ce chemin, le vieux style d'écriture mathématique des appels de fonctions pue par rapport à l'écriture expressive des expressions mathématiques.

* pause *

Ainsi, les autres programmeurs ont officiellement dit que je suis trop ringard et ont besoin d'inclure leur fonctionnalité préférée au moteur, donc je voudrais aussi souligner que nous avons une couche de base de données impressionnante qui dispose d'un système de contrôle de version intégré ce qui permet d'apporter des modifications locales et de les prévisualiser avant de les valider pour que les autres les voient (ou même suspendre et transférer les changements à d'autres utilisateurs). En outre, plusieurs personnes ont dit que les sockets et les plugs (un système que nous utilisons pour remplacer les caractéristiques du terrain pour les événements dynamiques) sont vraiment géniaux car il est très facile à utiliser et donne l'impression de sentir le monde changer pendant que vous jouez. Mais pour être honnête, je suis juste heureux quand je déplace la caméra en tapant des choses comme :

CVector3 velocity = CVector3::ZAxis() * CMatrix::RotationYawPitchRoll(m_cameraYaw, 0, 0);
m_positionVelocity = velocity.Normal() * (float)cv_CameraCharMovementSpeed;
m_position += m_positionVelocity * secsPerFrame;