La 30k est une erreur qui peut frapper à tout moment en jeu, sans que vous n'y soyez pour quelque chose, généralement au pire moment. Elle est probablement la pire chose qui puisse toucher un joueur à Star Citizen, elle est source de bien des frustrations, bien au-delà du comportement puéril des Griefer, et si vous n'avez encore jamais vu ou entendu parler de la 30k, c'est que soit vous êtes du genre chanceux, soit vous ne jouez pas à Star Citizen.
Même si on est en Alpha, il arrive un moment où le joueur finit par craquer et se manifeste d'une façon ou d'une autre. C'est le cas d'un joueur qui a fait part de sa frustration sur le serveur des Développeurs du Spectrum et Clive Johnson (Lead Network Programmer) lui fait une réponse des plus instructive sur l'avenir de la 30k (Notez que je n'ai pas traduit la question du joueur, elle n'est pas nécessaire, la réponse de Clive est suffisamment complète et bien construite pour se suffire à elle-même).
Quand les serveurs seront-ils stables ?
A la fin de la bêta.
Pourquoi pas avant ?
Parce que nous devons d'abord finir de faire le reste du jeu.
Lorsqu'un jeu est en cours de développement en tant qu'alpha fermé, l'accent est mis sur le développement des fonctionnalités et du contenu. La stabilité et la correction des bugs passent au second plan et seuls les problèmes qui pourraient entraver la poursuite du développement sont abordés. Cette façon de faire peut sembler peu professionnelle, mais l'idée est d'essayer des idées aussi rapidement et à moindre coût que possible. Cela permet aux développeurs de découvrir les parties du travail de conception du jeu qui doivent être revues. Il ne sert à rien de passer du temps à corriger un bug qui peut changer ou même être complètement retiré du jeu à tout moment. Le développement se poursuivra avec le jeu dans cet état de semi-intégration, au moins jusqu'à ce que toutes les fonctionnalités et le contenu aient été verrouillés. Le jeu entre alors dans la phase bêta du développement, où la correction des bugs, l'optimisation, l'équilibre et le peaufinage sont au premier plan. Dans l'idéal, aucune fonctionnalité n'est prévue pendant la phase bêta, mais il y a presque toujours des changements de dernière minute.
Star Citizen est bien sûr un développement ouvert, donc même si l'accent est mis en Alpha sur l'expérimentation de différentes idées, nous avons besoin que le jeu soit suffisamment stable et fonctionnel pour que les bailleurs de fonds puissent le tester et donner leur avis. Le mot clé est "suffisant", ce qui ne veut pas dire parfait, bien sûr. Il est important que nous trouvions le bon équilibre entre la correction des bugs et la poursuite du développement : trop de corrections de bugs et le développement ralentit, trop peu et nous n'avons pas assez de retours ou les bugs entravent la poursuite du développement.
CIG a-t-il trouvé le bon équilibre entre la correction des bogues et le développement ?
Le problème pour déterminer si un build est "assez" stable est que nous ne pouvons que regarder comment la stabilité affecte la base de joueurs dans son ensemble, c'est-à-dire la moyenne. Il y aura donc des joueurs chanceux qui auront beaucoup moins de crashs ou d'autres problèmes que la moyenne, tandis qu'il y aura de pauvres âmes pour qui le build semble être un festival de crashs avec des bugs. Demandez aux joueurs chanceux si nous avons trouvé le bon équilibre et ils vous diront peut-être que non, le jeu est suffisamment stable et que nous devons nous concentrer davantage sur l'expansion du jeu. Demandez aux joueurs malchanceux et ils diront peut-être non, mais ils veulent que nous arrêtions de travailler sur de nouvelles fonctionnalités jusqu'à ce que tous les bugs actuels soient corrigés. Très peu de gens diront oui.
En règle générale, avant de publier un patch pour le Live, nous essayons de nous assurer qu'il est au moins aussi stable que la précédente version Live. Certains patchs peuvent être plus ou moins stables que les précédents pour des styles de jeu particuliers mais, dans l'ensemble, la stabilité devrait s'améliorer de patch en patch. Bien sûr, il arrive parfois que les choses ne se passent pas comme on le souhaiterait et la stabilité moyenne finira par ne pas être aussi bonne que celle de la version précédente.
Pourquoi ne corrigeons-nous pas les plantages serveur qui causent des erreurs 30k de déconnexion ?
Nous le faisons. Il semble seulement que nous ne le faisons pas parce que, quelle que soit la cause, tous les crashs de serveur entraînent la même déconnexion 30000 sur les clients. Cette déconnexion se produit parce qu'une fois que le serveur a planté, les clients cessent soudainement de recevoir du trafic réseau de celui-ci. Ils attendent alors 30 secondes pour voir si le trafic va reprendre (au cas où le serveur serait bloqué temporairement ou s'il y avait une courte panne de réseau) avant d'abandonner, en retournant aux menus du front de page et en affichant l'erreur de déconnexion. Pendant ces 30 secondes, les clients verront que les portes ne s'ouvrent pas et que l'IA, les terminaux et autres entités ne répondent plus. Les commanditaires prennent parfois ces symptômes pour un signe que le serveur est sur le point de planter, et vous pouvez voir dans le jeu un chat disant que le serveur est en train de planter, mais la vérité est que le serveur est déjà mort. Il s'agit d'un ex-serveur. Il a cessé de l'être. Si nous ne l'avions pas cloué sur son perchoir, il ferait pousser les marguerites (Le chat en jeu ne continue à fonctionner que parce qu'il est géré par un autre serveur).
Lorsqu'un nouveau patch est en préparation sur le PTU, de nouvelles versions sont disponibles au téléchargement presque quotidiennement. Une fois que DevOps de l'ATX a poussé le nouveau build vers les serveurs et l'a rendu disponible au téléchargement, ils surveillent le build pendant les premières heures, travaillant souvent tard pour le faire, cherchant tout ce qui indique un problème à traiter immédiatement. Pendant les heures qui suivent, les gens jouent au jeu, téléchargent leurs rapports d'accident, les soumettent au Conseil des problèmes, répondent aux forums de discussion, etc.
Les pannes de serveur sont toutes automatiquement enregistrées dans une base de données. Lorsque les studios de l'UE se réveillent, le service d'assurance qualité technique examine les pannes des clients téléchargés et les pannes serveur enregistrées et procède à une première évaluation des pires contrevenants, en fonction de leur fréquence et de leur délai d'apparition dans le jeu. Les pannes serveur se retrouvent presque toujours en haut de la pile, pour la simple raison qu'elles touchent plus de personnes que les pannes des clients individuels. Les jiras sont créés et transmis à la production. La production fait trois choses ici : premièrement, elle envoie les rapports Jiras de crash aux responsables pour triage, deuxièmement, elle confirme les priorités et les crashs que l'AQ devrait essayer de reproduire ou auxquels elle devrait apporter son aide, troisièmement, elle signale tout crash particulièrement grave aux directeurs pour les appels prioritaires au cas où des personnes supplémentaires devraient être réaffectées pour essayer d'assurer une résolution rapide. Pendant ce temps, les responsables trient les accidents en s'assurant qu'ils sont attribués aux bons programmeurs dans les bonnes équipes. Ensuite, les programmeurs enquêtent sur les bogues, travaillant souvent avec l'assurance qualité pour trouver le plus d'informations possible sur le bogue. La plupart du temps, les programmeurs peuvent livrer un correctif le jour même, mais cela peut parfois prendre un jour ou deux de plus. Dans de rares cas, il faut parfois plusieurs semaines pour trouver le problème et trouver une solution. Dans de très rares cas, le bogue est le symptôme d'une faille plus profonde qui nécessitera la restructuration d'un système pour qu'il fonctionne différemment, ne peut pas être fait à temps ou sans risque important pour le correctif actuel, et doit être ajouté à un arriéré à programmer pour une prochaine version. Au fur et à mesure que l'ATX sera mis en ligne, la communauté et DevOps publieront leurs rapports sur la version précédente à partir des informations recueillies au cours de la journée précédente. La production lance un build avec tous les derniers correctifs et rencontre l'assurance qualité, la communauté et DevOps pour évaluer si le nouveau build est susceptible d'être meilleur que le précédent ou si des correctifs supplémentaires sont nécessaires. La production transmet sa recommandation aux cadres qui prennent une décision de poursuivre ou non la construction du nouveau build du PTU ce jour-là. Si c'est le cas, ATX QA et DevOps commencent à travailler sur une liste de contrôle pré-lancement qui prend plusieurs heures à remplir. Lorsque LA est en ligne, les programmeurs de l'UE peuvent transmettre tous les problèmes qui étaient spécifiquement destinés aux équipes de LA ou sur lesquels les équipes de l'UE travaillaient mais qui ne sont pas résolus et qui bénéficieraient d'une poursuite de l'enquête après la fin de LA pour la journée. Lorsque l'ATX a terminé la liste de contrôle avant la mise en ligne, et si la construction est terminée, le cycle recommence.
Si nous réparons les crashs, pourquoi y a-t-il toujours des déconnexions 30k ?
Entre chaque publication trimestrielle, nous changeons beaucoup de code. Certains sont complètement nouveaux et d'autres ne sont que des modifications du code existant. Chaque modification que nous apportons peut contenir des bogues. Nous ne sommes que des êtres humains et nous faisons tous des erreurs de temps en temps, donc chaque trimestre il y a la possibilité d'avoir ajouté beaucoup de nouveaux bugs. Il existe des processus pour réduire les risques que cela se produise, mais il y en a toujours qui passent inaperçus. Une fois qu'un bogue est découvert, il doit être corrigé. Il arrive qu'une correction ne fonctionne pas. Parfois, il ne corrige le problème que dans certains cas, mais pas tous. Parfois, le correctif lui-même contient un bogue qui peut causer d'autres problèmes. Une des choses que nous voyons souvent, c'est qu'une fois qu'un crash fréquent est corrigé, un ou plusieurs autres crashs vont apparaître plus souvent. Cela se produit parce que le crash qui vient d'être corrigé bloquait les autres crashs autant qu'ils l'auraient fait autrement. Comme mentionné ci-dessus, il y a aussi des crashs qui ne peuvent pas être réparés immédiatement et qui doivent attendre qu'il y ait plus de temps pour les réparer correctement ou qu'un autre travail prévu soit terminé. La majorité des accidents les plus fréquents finissent par être réparés. Il ne nous reste plus que les rares accidents, ceux qui ne se produisent qu'une fois par mois et pour lesquels nous n'avons pas encore suffisamment d'informations pour les réparer ou les reproduire. Un de ces rares bogues ne fera pas une grande différence à lui seul, mais une centaine de ces bogues suffiraient pour au moins trois plantages de serveur par jour.
Si nous ne pouvons pas rendre les serveurs stables, pourquoi ne pas prévoir une sorte de récupération ?
Il a été suggéré que la possibilité de fournir d'une sorte d'assurance des marchandises pourrait éviter aux joueurs de perdre des sommes importantes d'UEC lorsque leur serveur tombe en panne au milieu d'un transport de marchandises. Je pense que cela a été envisagé, mais le potentiel d'abus de cette assurance en tant qu'exploit est évident. Tant que ce problème n'est pas résolu, l'assurance des marchandises n'apparaîtra probablement pas dans le jeu.
Une autre suggestion est d'ajouter une sorte de récupération du serveur en cas de panne. L'idée ici est que lorsqu'un serveur tombe en panne, tous les clients seraient renvoyés aux menus avec un 30k comme ils le sont maintenant, mais auraient alors la possibilité de rejoindre un serveur nouvellement lancé qui a restauré l'état de l'original à partir de la persistance. C'est en fait quelque chose que nous espérons faire, mais cela demande plus de travail sur le SOCS et une persistance complète avant que cela puisse se produire, donc on en est encore loin.
D'autres suggestions ont également été faites, telles que des clients ou des serveurs qui sauvegardent l'état du jeu dans des fichiers locaux, mais ceux-ci ne sont pas sécurisés, sinon ce serait une solution temporaire et un gaspillage de travail à mettre en œuvre et à maintenir, qui pourrait être consacré à travailler sur la solution adéquate.
Pour l'instant, la meilleure solution est de continuer à réparer les pannes au fur et à mesure que nous les trouvons et d'espérer que les serveurs soient suffisamment stables pour que la plupart des joueurs puissent tester le jeu.
Le mot de la fin
Merci à Clive pour ce temps passé sur la réponse donnée, et on l'a globalement compris, les 30k vont faire partie de notre quotidien encore un moment, voir peut-être mène nous suivre jusqu'à la béta, et je présume fort que certains joueurs qui liront le message de Clive ne vont pas vraiment apprécier sa réponse. Mais on est continuellement dans la même rengaine que le jeu en l'état est une Alpha, et non un jeu finit, que dans le cadre de Star Citizen on bénéficie même d'une Alpha ouverte alors qu'elle devrait être fermée, il faut donc accepter de subir des bugs et crashes qui peuvent vous gâcher le plaisir du jeu, et si vraiment cela est source de frustration pour vous, et bien passez à autre chose et attendez au moins la béta que le jeu soit plus stable. Mais ne vous acharnez pas sur une Alpha...
Une touche d'humour inattendue
Si nous ne l'avions pas cloué sur son perchoir, il ferait pousser les marguerites.
J'ai tenu à traduire littéralement cette phrase et non cherché à la retranscrire pour qu'elle cadre avec le contexte, Clive a manifestement fait une touche d'humour, mais je ne suis pas certains que nombreux soient ceux qui l'ait comprise.
La phrase exacte est :
If you hadn't nailed it to the perch, it would be pushing up the daisies
Elle vient du "Sketch du Perroquet", ou "Perroquet Mort", des Monty Python, dans lequel un client vient se plaindre auprès d'un vendeur d'animaux de lui avoir vendu un perroquet mort cloué sur son perchoir. A un moment, la réplique du client est, en parlant de perroquet, "si vous ne l'aviez pas cloué sur son perchoir, il ferrait pousser les marguerites".
C'est de l'humour purement Anglais, mais il est amusant de la part de Clive de le voir réutiliser cette réplique dans le cadre d'un serveur aillant subit une 30k, qui est déjà mort, mais semble encore en vie aux yeux des joueurs.
Pour les curieux, le sketch peut être vu sur YouTube, sur la chaîne des Monty Python.
