Journal de développeur 3 : Faire fonctionner l'univers d'EVE et Dust 514.

Salut, c'est CCP Lin et je suis architecte serveur sur DUST 514.

Dans ce journal de développeur, j'aimerais aborder les aspects techniques du online de DUST, les défis que nous avions à relever et comment nous les avons abordés.

En tant qu'architecte serveur en chef du projet, je suis responsable de l'intégration des batailles du FPS DUST dans l'univers d'EVE mais aussi de l'optimisation des serveurs de jeux utilisés pour ces batailles.
A l'inverse des FPS multijoueurs classiques, DUST a de solides éléments de MMO dans son gameplay. Et a l'inverse des MMOFPS classiques à l'univers propre, DUST intéragit également très largement avec l'un des MMO spatiaux les plus connus : EVE online.



Cela présentait donc un important challenge concernant le choix des technologies a utiliser pour conserver ces interactions PC-PS3 tout en sauvegardant la fluidité de la partie FPS.
Certains savent que EVE est bâti sur un langage de programmation Python, "Stackless Python", qui permet de faire du multi-threading coopératif au niveau du langage. (attention, je ne comprends pas tout ca rend la traduction épineuse)
La technologie de CCP est donc adaptée a ce langage de programmation et il existe donc grâce a EVE des outils online que DUST peut et doit utiliser pour permettre une communication rapide et simple avec l'univers de New Eden.

Si nous nous sommes appuyés sur l'unreal engine 3 pour le gameplay FPS de DUST, les interactions avec le reste de l'univers EVE devaient logiquement s'appuyer sur l'existant pour profiter de l'expérience et de l'optimisation déjà effectué sur ces outils développés au départ pour EVE.
Ainsi, un joueur DUST apparaitra dans l'univers d'EVE comme une simple classe spéciale du jeu EVE. Egalement, le réseau de serveur EVE devrait traité les joueurs DUST de la même manière qu'il traite les joueurs EVE de facon a ce que la bande passante du réseau et les performances des serveurs soient équilibrés entre les deux titres.
Les serveurs EVE n'auraient donc qu'a activer des services liés à DUST afin d'accueillir les nouveaux joueurs DUST sans le moindre problème.
Cependant, la limitation technologique de la PS3 par rapport au language PYTHON imposait que nous utilisions des technologies poids plumes pour le client PS3, qui sont moins gourmandes en mémoire et en utilisation du CPU


Un autre aspect de l'interaction DUST-EVE vient des interactions entre les batailles prenants place dans les deux univer en simultané.

Prenons un exemple simple : Une corporation EVE lance un contrat pour la prise d'un territoire controlée par une corporation adverse sur une planète X (*1).
Un groupe de mercenaires accepte ce contrat en tant qu'attaquant. Un autre groupe choisi de défendre, avec une prime a la clé si ils réussissent. Lorsque les deux équipes sont prêtes et en nombre suffisants, le serveur EVE devrait ordonner au cluster de serveurs DUST de lancer une bataille avec tels joueurs, et a tel endroit.
Ceci permet d'obtenir le serveur de bataille avec toutes les infos nécessaires avant que les joueurs DUST n'y  soient propulsés comme prévu pour se battre.

Puis la partie se déroule jusqu'a la fin de cette dernière et l'intégration des conséquences liées au résultat.
=> gain/perte d'argents, équipements, véhicules etc... ; cession de territoire, batiments détruits etc..

Le serveur de bataille DUST est ensuite fermé.

(*1: Ce Devblog est un peu particulier, très axé technique et pas vraiment abordable.
Seul chose importante a preciser : Les corporations DUST ne seront pas dépendantes des contrats des corpos EVE. (Voir interview sorti plus tard))

Donc, l'univers d'EVE doit gérer la durée de vie des serveurs de bataille DUST tout en communiquant avec eux lorsque c'est nécessaire ET tout en faisant en sorte que les latence des joueurs dans la bataille soient équilibrées et non handicapantes. Je ne rentrerais pas dans des discussions techniques profondes (euh c'est pas déjà fait ?) sur comment résoudre ces problemes puisque nous explorons encore diverses possibilités pour trouver le meilleur équilibre.

A l'inverse des serveurs FPS traditionnels, nous hébergerons l'ensemble des serveurs.(pas de P2P).
Cependant, comme notre serveur central a des ressources limitées, nous devons trouver un moyen d'utiliser les ressources serveurs existantes autant que possible.
Ainsi, au lieu d'héberger un serveur par machine, nous avons pour but d'avoir une machine multi-coeur dédiée à l'hébergement du plus grand nombre de serveurs possible en simultané.

Nous avons réalisés tout un tas d'optimisations de performances significatives au moteur du FPS que nous utilisons aussi bien coté serveur, que coté client de telle sorte que chaque serveur de bataille est désormais capable d'accueillir un nombre très satisfaisant de joueurs DUST.
Malgré tout, pour que de multiples serveurs de batailles puissent co-exister sur la même machine multi-coeur, nous devons minimiser tout gachis de CPU et de mémoire. La encore je ne rentrerai pas dans les détails.

Sachez juste que les serveurs de batailles seront très "adaptables (*2)"
(*2 => En VO "Scalable". Ca se traduit par la capacité d'un système électronique a encaisser une augmentation du volume de fonctionnement. Par exemple passer de 32 à 64 joueurs.
Ou passer d'un système économique léger, à un système plus lourd etc...)


Comme toujours, nous continuons a améliorer chaque aspect de DUST afin d'en faire une expérience aussi incroyable que possible.

Voila, si quelqu'un a tout compris, qu'il me fasse signe . Rassurez vous les autres articles sont plus funs.

VO: CCP Lin

http://www.dust514.com/en/news/article/3053/scaling-the-universe