La vérité sur les erreurs 30K !!

[Maarkreidi]

Problèmes de serveurs et déconnections 30k

Qui n’a pas ragé lorsqu’en plein jeu une erreur 30k venait ruiner vos efforts d’un soir ou  même plusieurs soirs de jeu ? A part ceux qui ne jouent pas, je pense que tout le monde à déjà vécu cette situation. Les plus calmes relancent le jeu en disant “c’est pas grave” et d’autres y ont déjà perdu un clavier voir les accoudoirs de leur chaise gaming !!  

Régulièrement, on voit fleurir des postes de rage sur l’état du jeu, des serveurs etc. Un développeur a pris son courage à deux mains et à décidé d’expliquer ce qui se passe au niveau des serveurs et pourquoi les 30k sont encore présentes pour les gens mal informés du déroulement d’un développement de grande envergure comme celui de Star Citizen.

Pour plus de compréhension j’ai remis la question initiale du joueur car nous aurions tous pu la poser. Et pour une fois, ce n'est pas juste un paragraphe d'insultes écrites par un rageus boutonneux, le joueur propose même des "solutions" hum. Bref je vous laisse lire ce pavé très instructif.

 

Joueur :
Y a-t-il une date limite pour la stabilité du serveur, c'est difficile de faire quoi que ce soit dans le jeu quand on perd chaque bit d'UeC dans le jeu et oui je comprends que l'on travaille dessus mais quand on perd 400k dans les jeux c'est très démoralisant surtout que c'est la 2ème fois que cela arrive, j'ai choisi de rester loin de ce jeu pendant quelques semaines et de savoir que tout est travaillé mais je pensais honnêtement que ce nouveau patch aurait corrigé l'erreur de 30k. Il faudrait mettre en place une assurance sur le transport de marchandises si vous pensez que cela fait partie du jeu, honnêtement je commence à penser qu'il n'y a pas d'avenir dans ce jeu, je l'ai acheté en 2017 et j'ai arrêté de jouer jusqu'à présent et je pense que la perspective est de ne plus jouer pendant quelques années encore, d'arrêter de faire tout le reste et de régler les problèmes. Il est difficile de voir les autres joueurs ne pas avancer dans un jeu uniquement à cause des accidents et des pertes d'argent. Je comprends qu'il s'agit d'une alpha, mais faites-la fonctionner à 100 % et promettez-nous au moins un peu plus de stabilité.

Clive Johnson CIG :
Il y a beaucoup de choses à répondre à votre question. Je vais essayer de couvrir les principaux points, mais je m'excuse si vous pensez que j'ai omis quelque chose d'important.

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 travaillé comme une alpha fermée, l'accent est mis sur le développement des caractéristiques et du contenu. La stabilité et la correction des bogues 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 quelles parties du travail de conception du jeu sont à revoir et lesquelles ne le sont pas. 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-développement 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 de développement où la correction des bugs, l'optimisation, le rééquilibrage et le polissage sont au premier plan. Dans l'idéal, aucun travail de fond n'est effectué pendant la bêta, mais il y a presque toujours des changements de dernière minute.

SC est bien sûr un développement ouvert, donc même si l'accent est toujours mis dans alpha sur l'expérimentation de différentes idées, nous avons besoin que le jeu soit suffisamment stable et fonctionnel pour que les backers puissent le tester et donner leur avis. Le mot clé est "assez", ce qui ne signifie évidemment pas parfait. Il est important que nous trouvions le bon équilibre entre la correction des bogues et la poursuite du développement : trop de corrections de bogues et le développement ralentit, trop peu et nous ne recevons pas assez de commentaires ou les bogues entravent la poursuite du développement.

Est-ce que CIG a 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 quelques chanceux qui auront beaucoup moins de plantages ou d'autres problèmes que la moyenne, tandis qu'il y aura quelques pauvres âmes pour qui la build semble être un festival de plantages truffé de bugs. Demandez aux joueurs chanceux si nous avons trouvé le bon équilibre et ils vous répondront peut-être que non, le jeu est suffisamment stable et que nous devons nous concentrer davantage sur l'expansion du jeu. Demandez aux malchanceux et ils vous diront peut-être non, mais ils veulent que nous arrêtions de travailler sur les nouvelles fonctionnalités jusqu'à ce que tous les bogues actuels soient corrigés. Très peu de gens vont dire oui.

En règle générale, avant de publier un patch pour Live, nous essayons de nous assurer qu'il est au moins aussi stable que la précédente version de 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 d'un patch à l'autre. Bien sûr, parfois les choses ne se passent pas comme on le voudrait et la stabilité moyenne finira par ne pas être aussi bonne que dans la version précédente.

Pourquoi ne corrige-t-on pas les pannes de serveur qui provoquent des erreurs de déconnexion 30 000 ?

Nous le faisons. Il semble que ce ne soit pas le cas, car, quelle qu'en soit la cause, tous les crashs de serveurs entraînent la même déconnexion 30 000 des 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 ensuite 30 secondes pour voir si le trafic va reprendre (au cas où le serveur était bloqué sur un décrochage temporaire ou s'il y a eu une courte panne de réseau) avant d'abandonner, en revenant aux menus initiaux et en affichant l'erreur de déconnexion. Pendant ces 30 secondes, les clients verront les portes ne pas s'ouvrir ainsi que l'IA, les terminaux et d'autres entités ne réagissent plus. Les backers prennent parfois ces symptômes pour un signe que le serveur est sur le point de planter, et vous pouvez voir dans le jeu des discussions disant qu'un crash du serveur est en cours, 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. (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 en téléchargement presque quotidiennement. Une fois que DevOps à Austin a poussé la nouvelle version sur les serveurs et l'a rendue disponible au téléchargement, ils surveillent la version pendant les premières heures, travaillant souvent tard pour le faire, à la recherche de tout ce qui pourrait indiquer un problème à traiter immédiatement. Pendant les heures qui suivent, les gens jouent au jeu, en téléchargeant leurs rapports d'accident, en les soumettant à l'Issue Council, en répondant 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 des serveurs enregistrés et procède à une première évaluation des pires cas, en fonction de leur fréquence et de la période qui suit la connexion à une partie. Les pannes de serveur sont presque toujours en tête de liste, pour la simple raison qu'elles touchent plus de personnes que les pannes de clients individuels. Les jiras sont créés et transmis à la production. La production fait trois choses ici : premièrement, elle envoie les Jiras de crash aux chefs de file 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 mauvais 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 chefs de file trient les pannes en s'assurant qu'elles vont aux bons programmeurs dans les bonnes équipes. Ensuite, les programmeurs étudient les bogues, travaillant souvent avec l'assurance qualité pour trouver le plus d'informations possibles sur le bogue. La plupart du temps, les programmeurs peuvent livrer un correctif le jour même, mais parfois cela peut 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é à prévoir pour une prochaine version. Au fur et à mesure que l'ATX est mis en ligne, la communauté et DevOps publient leurs rapports sur la build précédente à partir des informations recueillies au cours de la dernière journée. La production lance une nouvelle version avec toutes les dernières corrections et rencontre l'AQ, la Communauté et DevOps pour évaluer si la nouvelle version est susceptible d'être meilleure que la précédente ou si des corrections supplémentaires sont nécessaires. La production transmet sa recommandation aux cadres qui prennent une décision de poursuivre ou non la mise en place de la nouvelle build sur le PTU ce jour-là. Si oui, ATX QA et DevOps commencent à travailler sur une liste de contrôle préalable à la libération qui prend plusieurs heures à remplir. Lorsque LA est en ligne, les programmeurs de l'UE peuvent transmettre tout problème qui était spécifiquement destiné aux équipes de LA ou sur lequel les équipes de l'UE travaillaient mais qui n'est pas résolu et qui bénéficierait d'une enquête continue après la fin de LA pour la journée. Une fois que les ATX ont rempli la liste de contrôle avant la sortie, et si la construction est passée, le cycle recommence.

Si nous réparons les crashs, pourquoi y a-t-il toujours des erreurs 30 000 ?

Entre chaque publication trimestrielle, nous changeons beaucoup de code. Certains d'entre eux sont complètement nouveaux et d'autres ne sont que des modifications du code existant. Chaque changement que nous faisons a une chance de contenir des bugs. 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 certains échappent toujours à la règle. Une fois qu'un bogue est découvert, il doit être corrigé. Parfois, une solution ne fonctionne pas. Parfois, cette solution ne résout 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. L'une des choses que nous voyons souvent est qu'une fois qu'un accident fréquent est réglé, un ou plusieurs autres accidents commencent à apparaître plus souvent. Cela se produit parce que l'accident qui vient d'être réparé empêchait les autres accidents de se produire autant qu'ils l'auraient fait autrement. Comme mentionné ci-dessus, il y a aussi des accidents 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é. Finalement, même si la majorité des accidents les plus fréquents sont réparés. Il ne nous reste alors que les rares accidents, ceux qui ne se produisent qu'une fois par mois et pour lesquels nous ne disposons pas encore de 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 proposer 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 crois que cela a été envisagé, mais le risque d'en faire un exploit est évident. Tant que ce problème n'est pas résolu, il est peu probable que l'assurance des cargaisons apparaisse dans le jeu.

Une autre suggestion est d'ajouter une sorte de récupération en cas de panne de serveur. L'idée ici est que lorsqu'un serveur plante, tous les clients sont renvoyés aux menus avec un 30 000 comme ils le sont maintenant, mais ils ont alors la possibilité de rejoindre un serveur nouvellement déployé qui a rétabli l'état de l'original à partir de la persistance. C'est en fait quelque chose que nous espérons faire, mais il faut encore travailler sur le SOCS et faire preuve d'une grande persévérance avant que cela puisse se faire, donc on est encore loin du compte.

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 la mise en œuvre et la maintenance de cette solution serait temporaire et constituerait un gaspillage de travail qui pourrait être consacré à la recherche de la solution adéquate.

Pour l'instant, la meilleure option est de continuer à réparer les plantages 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.

 

source : Spectrum

Trad : @Maarkreidi SwissStarships.org