Salut la compagnie ! Ici Snedhepl, en direct de la grand-messe sur l’état de l’Union technique dans RIFT. Dans mon discours épistolaire, je ferai part des évolutions de l’année dernière, à la fois en termes de fonctionnalités et de processus internes, ainsi que de ce que nous espérons accomplir l’année prochaine. Dans mon discours, j’aborderai en outre en profondeur une discussion qui porte sur une fonctionnalité des plus enthousiasmantes : le soutien multicœur pour le rendu.

L’an dernier, nous avons ajouté une série de fonctionnalités inédites. Certaines d’entre elles étaient plus visibles que d’autres, comme les aventures instantanées en mode intrépide et le mode assaut. D’autres fonctionnalités, qui ont par exemple permis d’optimiser la salle des ventes et d’améliorer ce que nous appelons le « chargement des guildes à la demande », sont moins ressorties du lot. D’autres batailles menées sur le front de l’ingénierie, telles que la lutte contre les bots, les améliorations de performance liées aux scores et classements, ou encore le système de signalement de joueurs, ne sont visibles que de façon indirecte.

Les Aventures intrépides ont été un franc succès ! Même si nous avons rencontré quelques difficultés techniques mineures avec ces dernières (comme c’est souvent le cas avec de nouvelles fonctionnalités), les améliorations effectuées au final en ont vraiment valu la peine. Les optimisations liées à la salle des ventes se sont elles aussi bien déroulées ; nous avons ainsi pu améliorer le temps consacré à la recherche d’objets.

Il est également important pour nous de reconnaître que les fonctionnalités introduites n’ont pas forcément toutes été exemptes de problèmes plus sérieux : le chargement de guildes à la demande a manifestement connu un début relativement laborieux ! Nous avons enregistré de nombreux crashs de serveur, ainsi que de bugs de grande sévérité. Malgré toutes ces quelques souffrances, les améliorations ont produit des résultats tangibles : l’utilisation de la mémoire sur certains serveurs a connu une réduction d’environ 25 %, et permis une amélioration des performances.

Nous n’avons pas non plus abandonné notre chasse aux bots, qui porte ses fruits ! Chaque jour, nous détectons de plus en plus de bots, et les supprimons du jeu. Cet aspect peut paraître anodin. Pourtant, les bots ont une influence néfaste sur l’économie ; leur suppression améliore ainsi l’équilibre du jeu.

Parmi nos autres progrès notables, je compte le système des tenues. Notre système précédent était correct, mais depuis sa réorganisation il est devenu, à mon humble avis, le meilleur qui existe actuellement. Vous avez désormais un choix de 99 couleurs de teintures pour vos vêtements. Vous n’avez plus besoin de conserver les objets que vous obtenez dans votre inventaire pour pouvoir les utiliser, et vous pouvez équiper toutes sortes d’armes et armures, sans restriction.

De plus, cette année, nous avons accompli une grande première dans RIFT, avec l’ajout d’une nouvelle classe. Le Primaliste a constitué un exploit impressionnant, bien que les ingénieurs ne puissent s’en attribuer tout le mérite : l’équipe de Conception système a sorti d’innombrables versions différentes, en s’appuyant sur les commentaires des joueurs et de leurs collègues, et sacrifié bien des soirées et des week-ends pour que cette nouvelle vocation voie le jour.

Dernière amélioration, mais pas des moindres : nous avons modifié le système de signalement de joueurs. Il y a quelques mois, nous avons discrètement effectué des changements. Avant cela, lorsque vous signaliez quelqu’un, cette personne était placée sur votre liste de joueurs à ignorer. Désormais, le signalement appose une « marque noire » virtuelle sur la personne, liée à son compte de jeu. Si le joueur change de personnage ou même de serveur, la marque reste. Et si cette personne cumule un certain nombre de marques noires, l’information remonte à l’Assistance à la clientèle, qui étudie le cas et peut prendre des mesures. Si d’autres signalements ont lieu, le joueur est bloqué par le système jusqu’à ce qu’un agent de l’Assistance à la clientèle décide des mesures à appliquer.

Avant de parler de procédures d’ingénierie, j’aimerais vous expliquer le terme de « dette technique ». C’est un terme générique qui englobe non seulement les bugs, mais aussi tout le travail technique effectué présentant des difficultés de maintenance ou de propagation. La maintenance est importante : créer un programme, quel qu’il soit, c’est comme construire une maison… mais une maison qui a constamment besoin qu’on la réagence, qu’on tire des câbles, qu’on ajoute des pièces. Ce qui est dommage dans la programmation, c’est que parfois, on n’a pas le temps d’établir de bonnes « fondations » avant de bâtir une nouvelle « pièce ». Et en faisant cela, on contracte une dette technique, ce qui implique qu’il faudra travailler plus dur à l’avenir pour s’assurer que tout fonctionne correctement.

Chaque équipe d’ingénieurs a ses méthodes de gestion des fonctionnalités, des bugs et de la communication entre les disciplines. Au cours de l’année écoulée, nous avons redoublé d’efforts pour régler le problème de la dette technique. C’est quelque chose qui a toujours été important, et effectué, mais afin d’améliorer les choses, nous formalisons le processus. Par exemple, presque tout le travail sur les fonctionnalités est désormais suivi de deux semaines consacrées à la dette technique. L’avantage, c’est que nous pouvons désormais nous concentrer sur ces éléments sur de larges périodes. Différentes études ont montré que les gens, et en particulier les ingénieurs logiciels, ont de grandes difficultés à changer de tâche en cours de route. En réservant de larges plages horaires, nous leur permettons de mieux se concentrer sur ces problèmes et d’être plus efficaces.

À présent, passons à la nouveauté la plus intéressante : la prise en charge des processeurs multicœurs ! C’est vraiment une nouvelle de taille, et cela fait plus d’un an que nous gardons le secret ! C’est en quelque sorte le plus grand changement que nous puissions effectuer sur RIFT. Pour résumer, cela modifie la façon dont tout le moteur de jeu calcule les rendus. Si nous étions allés plus loin, il aurait fallu réécrire le jeu de A à Z.

En quoi est-ce important ? RIFT fonctionne à l’aide d’une API graphique appelée DirectX 9 (DX9). Elle permet au client de RIFT de communiquer avec la carte graphique de votre ordinateur. Le problème est que DX9 commence à prendre des rides : elle n’avait été conçue que pour des processeurs monocœurs et leur demande beaucoup de ressources. Depuis, la technologie a évolué et les processeurs multicœurs sont devenus la norme. RIFT prendra bientôt en charge ces nouveaux processeurs et utilisera tous les cœurs pour améliorer la vitesse d’affichage et le temps de réaction, tout en évitant que la vitesse du processeur ne gêne la carte graphique.

« Hé, Snedhepl, je comprends rien à ton blabla technique. Ça donne quoi, en français ? » Imaginez : vous concevez un véhicule pour transporter des gens de Processeurville à Carte-graphique-sur-mer. Les gens, ce sont les instructions de rendu. Pour qu’ils arrivent à la mer, vous fabriquez un bus : c’est le véhicule le plus efficace pour transporter des gens d’un point à un autre. Des années plus tard, la route de Processeurville a été transformée en autoroute à quatre voies. Est-ce qu’un bus est toujours le meilleur choix ? Il faut pas mal de temps pour faire monter tous les passagers dans le bus. Il lui faut du temps pour accélérer ou pour changer de file. Alors on passe aux voitures. Ce n’est pas parfait : à l’arrivée, il faut encore que les gens s’alignent correctement, et cela demande beaucoup de travail pour leur faire respecter le Code de la route. Ils peuvent même (se) planter ! (Oui, je mourais d’envie de sortir cette vanne, pardon.) Cependant, les voitures sont beaucoup plus efficaces maintenant qu’il y a ces nouvelles voies. On peut les charger rapidement et les envoyer à toute vitesse sur l’autoroute. Voilà, c’est ce que la prise en charge du multicœur va faire pour RIFT.

La prise en charge du multicœur est actuellement en alpha privée, et nous espérons la sortir prochainement en bêta publique. Nous sommes ravis de pouvoir enfin parler des améliorations de performances sur lesquelles nous travaillons depuis un an et demi ! Et nous avons vraiment hâte d’entendre votre avis sur la question !