L’optimisation de la mise à jour Star Citizen alpha 3.1

[Bobmorane85]

Le Network Bind Culling est déplacé de la mise à jour Star Citizen Alpha 3.1 à la mise à jour Star Citizen Alpha 3.2

C’était une énorme déception concernant le développement du jeu et plus précisément au sujet du prochain patch Star Citizen Alpha 3.1, il n’y aura pas de Network Bind Culling. Ce dernier a été décalé jusqu’au patch Star Citizen Alpha 3.2… Si d’ici là CIG ne le repousse pas encore plus loin. Sans vouloir être parano, ceux qui suivent le développement du jeu vidéo de Chris Roberts depuis le début le savent, c’est un phénomène récurrent qui se produit quasi systématiquement à chaque patch.

Ceci étant, il faut bien garder à l’esprit que Star Citizen se construit sur la base d’un développement ouvert, il est donc très important de relativiser ce que l’on vient de dire dans la mesure où dans tous les développements de jeux vidéos, il y a des reports, des rétropédalages ou dans le meilleur des cas, des avancées significatives aussi.

Oui oui, il faut le souligner, car on a pour fâcheuse tendance à observer tout ce qui ne fonctionne pas, en oubliant presque les travaux titanesques qui ont été accomplis aussi. Parfois les développeurs prennent de l’avance sur ce qui est annoncé, c’est par exemple le cas avec les planètes procédurales ou le simple fait d’y atterrir et d’y décoller n’étaient point prévu sur le calendrier avant… pas mal de temps voir plusieurs années après la release !

C’est dire si Cloud imperium Games a pris tout le monde de contre-pied avec cette technologie made in Germany. Car il faut rendre à César ce qui est à César, c’est à partir de l’ouverture du studio Foundry 42 de Francfort dirigé par Brian Chambers que ce vieux rêve est devenu (si vite) réalité.

Doit-on rajouter encore que les lunes te planètes en question, n’étaient pas non plus censées tourner sur elles-mêmes, en tout cas pas dès le patch Star Citizen Alpha 3.0.

Donc, des progrès il y en a, des percées plus rapides que prévues dans le développement aussi.

Ceci étant, nous ne pouvons nous empêcher d’être déçus, c’est humain, la frustration a pris le dessus, car cette feature (culling) était censée déjà débarquer pour la 3.0. Or il n’en est rien, faute de temps, CIG a préféré la reporter pour la 3.1. Et suite au couac ce la 3.0 avec l’énorme frustration de la majorité des joueurs qui s’en est suivi, a fait que l’optimisation des performances était devenue d’une importance capitale pour les développeurs. Mais pas seulement pour faire plaisir aux citoyens des étoiles en fait…

 

L’optimisation du Network Bind Culling est devenue une nécessité absolue pour la suite du développement

Car le jeu se trouve actuellement dans une impasse, à savoir que, il se revendique massivement multijoueurs, mais cela fait maintenant plusieurs patchs que les développeurs peinent à augmenter le nombre de joueurs par instance. Même si peu avant le déploiement de la 3.0, on nous avait annoncé des tests en interne avec plus de 100 joueurs qui s’étaient avérés excellents et très prometteur pour la suite.

Certes le nombre de joueur à sensiblement augmenté en 3.1, mais au détriment de gros sacrifices, il n’y a qu’à voir la réduction du nombre de PNJ ainsi que leurs activités, pourtant très simples, très basiques, consistant à tourner en rond indéfiniment autour d’une pièce de la station spatiale Port Olisar par exemple.

Bien entendu il n’y a pas que ça qui compte dans l’optimisation d’un jeu et pour la 3.1 il doit y avoir quelque chose comme 50% des tâches liées à l’optimisation qui ont déjà été accomplies. Cela dit, les devs ne pourront pas ajouter de contenus et d’autres choses indéfiniment dans le jeu si le network bind culling n’est pas à jour.

Star Citizen a été développé à l’aide d’un moteur initialement prévu pour faire des jeux FPS style COD ou Battlefield, qui n’ont pas une grande surface par map, très très peu de personnalisations et des joueurs ne dépassant généralement pas les 32 personnes par équipe. Et bien qu’ils aient déjà transformé plus de la moitié du code du moteur , notamment en le passant de 32 bits à 64 bits (ce qui avait déjà fait perdre pas mal de temps à l’époque, mais qui était nécessaire pour pouvoir avoir une map plus grande que 8x8x8 Km), cela reste insuffisant au vu des ambitions qu’il reste à satisfaire.

On voit beaucoup de commentaires disant que nous sommes en alpha, c’est normal, ils ajoutent et ils optimisent après… Non, ce n’est pas forcément comme cela que ça se passe, l’univers persistant de Star Citizen est arrivé dans une impasse et ce déjà depuis quelques patchs. CIG ne peut plus repousser l’optimisation maintenant.

Nous sommes arrivé à un stade de développement où à chaque grosse technologie implantée, une optimisation doit être apporté derrière afin de pouvoir poursuivre la suite du travail et des tâches à accomplir.

Certains confondent corrections des bugs et optimisations. On ajoute des fonctionnalités et du contenu et on corrige les bugs après, mais l’optimisation elle, se fait à tout instant. Nous en avions d’ailleurs déjà eu plusieurs, comme certains reworks de vaisseaux qui de nos jours sont non seulement plus beaux, mais pèsent aussi moins lourd en terme de mémoire. L’optimisation est une priorité.

 

Pourquoi CIG n’embauche pas plus d’ingénieurs réseaux Rogntudju ?

Cloud Imperium Games ne l’ignore pas, mais refaire plein de lignes de code demande du temps, beaucoup de temps et le problème, c’est que chez CIG, des ingénieurs réseaux et bien… Il n’y en a pas beaucoup !
De mémoire nous devons avoir quelque chose comme 6 ingé réseaux au total, sur une boite comptant pas loin de 500 salariés. Ces 6 personnes sont réparties en deux groupes :

• 3 ingénieurs réseaux travaillant à Manchester sur les communications clients/serveurs.
• 3 ingénieurs réseaux travaillant à Austin sur les services backend comme le matchmaking, les amis, rejoindre une partie etc..

Vous comprenez pourquoi cela prend autant de temps, mais alors vous devez certainement vous demander, pourquoi CIG n’embauche pas plus d’ingénieurs réseaux mille sabords ?!

Et bien tout simplement car cela ne court pas les rues. C’est un peu comme sur Youtube (Par analogie), vous avez des milliers et des milliers de youtubeurs “spécialistes” des jeux vidéos, mais qui vont tout simplement faire du let’s play. Et quelques autres qui vont proposer des tutos, mais ils sont largement moins nombreux, car c’est plus long et moins marrant à faire. Et bien là c’est pareil, vous souhaitez créé un jeu vidéo, vous allez pouvoir embaucher plein de designers, il y en a à la pelle ! Mais des ingénieurs réseaux non. Il est vrai que c’est moins gratifiant de faire du network plutôt que de montrer ses jolis dessins sur les réseaux sociaux. C’est un peu comme nous sur Star Citizen, on va dire waouh à un designer qui nous aura pondu un chouette concept, mais est-ce que l’un d’entre vous a déjà dit waouh au travail de Clive Johnson ou de son équipe ?

Pourtant, on peut vous assurer qu’ils sont méritants les mecs, ils abattent un travail absolument colossal et les ingénieurs réseaux de CIG sont réputés très bons en plus… Il n’y a qu’à voir comme ils ont su transformer à plusieurs reprises le CryEngine de Crytek pour en faire un StarEngine beaucoup plus performant !

Quelques ingénieurs supplémentaires ne feraient pas de mal à CIG, ils en ont besoin comme en témoigne par exemple cette petite annonce datant de mars 2017 et toujours active !

Il faut croire que trouver des ingénieurs réseaux c’est devenu aussi compliqué que de trouver un ophtalmo… Et encore, on ne parle même pas des compétences, bref…

 

 

Des nouvelles rassurantes qui s’appellent Serialized Variable Culling

Clive Johnson est par ailleurs intervenu ce jour sur Spectrum afin de clarifier un peu la situation. L’ingénieur réseau a indiqué que l’avancement fut plus lent que prévu, en raison d’anciens systèmes qui ont été supprimés et qu’il sont à court de temps pour vérifier l’implémentation correcte du network bind culling avant la mise à jour Star Citizen Alpha 3.1..

Il précise et ça c’est très important de le souligner aussi, que le bind culling qui charge et décharge les entités selon la distance, permet de ne pas consommer de ressources pour ce qui concerne les éléments distants. C’est donc génial, mais le revers de la médaille de cette technologie est qu’il faut également charger/décharger ces entités fréquemment. L’Object Container Streaming permet de palier à ce problème, mais il est loin d’être prêt. Les devs ont donc de tester le Bind Culling afin de mesurer son impact et de décider s’il serait envisageable pour la 3.1.

Ceci étant, Clive Johnson tient à nous rassurer, si le Bind Culling n’était pas prêt pour la 3.1, ils avaient prévu le Serialized Variable Culling (initialement pour la 3.0) qui lui est déjà prêt depuis des semaines et qui selon l’ingénieur réseau, offrirait des gains de performances quasi équivalents à une bonne partie de ceux qu’apporteraient en théorie le Bind Culling.

En outre, l’équipe réseau a été assignée à d’autres tâches prioritaires pour le moment.

Ce qui signifie que, nous devrions tout de même obtenir de bonnes performances pour la mise à jour Star Citizen Alpha 3.1 entre le Serialized Variable Culling et le restant des optimisations qui sont également en cours et qui seront effectifs pour le prochain patch.

Nous sommes impatients de tester tout ça et on va croiser les doigts pour que les résultats soient à la hauteur de nos espérances…

A très vite dans les étoiles !

 

Source : starcitizenfrance.fr