Clive Johnson, programmeur réseau en chef chez Cloud Imperium Games, a écrit un long pavé sur Spectrum en réponse à une “question” se plaignant des déconnexions serveurs (code 30000) et les conséquences fâcheuses sur le portefeuille. Il évoque, entre autres, leur philosophie de développement actuel et leur équilibre constant entre continuer à développer des nouveautés et corriger des bugs du build joueur, les codes 30000 ainsi que la façon dont les crashs et les bugs sont gérés en interne. Un grand merci à Insosama qui, en plus de la relecture, a ajouté quelques annotations dans le texte. Pour les afficher, passez votre souris sur les chiffres (exemple : [0]).
Question par Seira Wolf
Y a-t-il une échéance pour la stabilité du serveur? C’est difficile de faire quoi que ce soit dans le jeu quand on perd tous nos UEC dans le jeu et oui, je comprends que l’on travaille dessus mais quand on perd 400k dans le jeu, 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 je sais que tout est en cours de travail mais je pensais honnêtement que ce nouveau patch allait corriger les erreurs 30k. Vous devriez implémenter une assurance cargo si vous prévoyez que cela soit prévu ingame. Honnêtement, je commence à penser qu’il n’y a pas d’avenir pour ce jeu, je l’ai acheté en 2017 et j’ai arrêté d’y jouer jusqu’à présent. Je sens que l’attente, sans jouer, va durer pendant quelques années encore. Arrêtez de faire tout le reste et réglez les problèmes. Il est difficile de voir les autres joueurs ne pas avancer dans un jeu uniquement à cause des crashs et des pertes d’argent. Je comprends qu’il s’agisse d’une alpha, mais faisons en sorte qu’elle fonctionne à 100 % et promettons au moins un peu plus de stabilité.
Réponse par Clive Johnson
Il y a beaucoup de choses à répondre dans 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 phase bêta. Pourquoi pas avant ? Parce que nous devons d’abord finir de faire le reste du jeu.
Lorsqu’un jeu est travaillé 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 résolus plus tôt. Cette façon de faire peut sembler peu professionnelle, mais le principe est d’essayer des idées aussi rapidement que possible et à moindre coût. Cela permet aux développeurs de découvrir quelles parties du design du jeu fonctionnent et lesquelles doivent être revues. Il ne sert à rien de passer du temps à corriger un bug sur une fonctionnalité qui peut changer ou même être complètement retirée du jeu à tout moment. Le développement se poursuivra avec le jeu dans cet état de dégradation partielle, au moins jusqu’à ce que toutes les fonctionnalités et le contenu aient été verrouillés. Le jeu entrera alors dans la phase bêta du développement, où la correction des bugs, l’optimisation, l’équilibre et le peaufinage seront à ce moment-là au premier plan. Dans l’idéal, aucune fonctionnalité n’est prévue pendant une phase 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 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 “backers” puissent le tester et donner leur avis. Le mot-clé est “suffisamment”, 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 du jeu et de ses fonctionnalité ralentit. Trop peu et nous n’avons pas assez de retours sur l’expérience et certains bugs critiques, et cela entrave aussi la poursuite du développement.
CIG a-t-il trouvé le bon équilibre entre la correction des bugs et le développement ?
Pour déterminer si un build est “assez” stable, nous ne pouvons que regarder comment les bugs affectent la base de joueurs dans son ensemble, c’est-à-dire “en 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 des joueurs accablés pour qui le build semblera être un véritable festival de plantages avec son carnaval de bugs. Demandez aux joueurs chanceux si nous avons trouvé le bon équilibre, et ils vous diront probablement que “non, le jeu est suffisamment stable, nous devons nous concentrer davantage sur l’enrichissement du jeu”. Au contraire, demandez aux seconds, la réponse sera aussi négative, mais ils voudront 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 monde diront “oui, l’équilibre du développement de jeu leur convient”.
En générale, avant de publier un patch pour le serveur 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 corrige-t-on pas les pannes serveur qui provoquent des erreurs de déconnexion 30000 ?
Nous le faisons. Il semble seulement que ce n’est pas le cas parce que, quelle que soit la nature du problème, tous les plantages serveur entraînent la même déconnexion 30000. Cette déconnexion se produit parce qu’une fois que le serveur a planté, les clients cessent soudainement de recevoir le 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 au menu et en affichant cette fameuse 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 “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 messages 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é d’être. Si il n’avait pas été cloué sur son perchoir, il aurait mangé les marguerites par la racine[1]. (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, les nouvelles versions sont disponibles au téléchargement presque quotidiennement. Une fois que l’équipe DevOps à Austin 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, à la recherche de tout ce qui pourrait indiquer un problème à traiter immédiatement. Pendant les heures qui suivent, les gens jouent au jeu et envoient leurs rapports de crash, soumettent leurs problèmes à l’Issue Council, répondent aux forums de discussion, etc. Les plantages serveur sont tous automatiquement enregistrés dans une base de données. Lorsque les studios européens se réveillent, le service d’assurance qualité technique examine les crashs client téléchargés et les crashs serveur enregistrés, puis procède à une première évaluation des pires cas, en fonction de leur fréquence et du délai d’attente après avoir rejoint un jeu. Les crashs serveur sont presque toujours en tête de liste, pour la simple raison qu’ils touchent plus de personnes que les crashs client individuels. Les jiras[2] sont créés et transmis à la production. La production fait trois choses ici : premièrement, elle envoie les jiras de crash aux responsables pour triage, deuxièmement, elle confirme les priorités et les crashs que l’Assurance qualité devrait essayer de reproduire ou auxquels elle devrait apporter son soutien, troisièmement, elle signale tout plantage particulièrement grave aux directeurs pour les appels prioritaires au cas où des personnes supplémentaires devraient être réaffectées afin d’essayer de parvenir à une résolution rapide. Pendant ce temps, les responsables trient les crashs en s’assurant qu’ils vont aux bons programmeurs dans les bonnes équipes. Ensuite, les programmeurs enquêtent sur les bugs, travaillant souvent avec l’Assurance qualité pour trouver le plus d’informations possibles dessus. 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 bug est le symptôme d’une défaillance plus profonde qui nécessitera la restructuration d’un système pour qu’il fonctionne différemment, ce qui ne peut pas être fait à temps, ou sans risque important, pour le patch actuel, et doit être ajouté à un “backlog” à programmer pour une prochaine version. Au fur et à mesure qu’Austin revient en ligne au matin suivant, la communauté et l’équipe DevOps publieront leurs rapports sur la version précédente à partir des informations recueillies au cours de la journée passée. La production lance un build avec tous les derniers correctifs et rencontre l’Assurance qualité, la communauté et DevOps pour évaluer si celui-ci est susceptible d’être meilleur que le précédent ou si des correctifs supplémentaires sont nécessaires. La production transmet leur recommandation aux directeurs qui prennent une décision d’acceptation ou de refus de la nouvelle version sur le PTU le jour même. Si c’est accepté, l’Assurance qualité d’Austin et DevOps commencent à travailler sur une check-list de pré-lancement qui prend plusieurs heures à compléter. Lorsque Los Angeles est à son tour en ligne, les programmeurs en Europe peuvent transmettre tous les problèmes qui étaient spécifiquement destinés aux équipes californiennes ou sur lesquels les équipes européennes travaillaient mais qui ne sont pas encore résolus, et qui bénéficieraient d’une poursuite de l’enquête après que l’Europe ait terminé sa journée. Lorsqu’Austin a terminé la check-list de pré-lancement, et si le build est passé, le cycle recommence.
Si nous réparons les crashs, pourquoi y a-t-il toujours des déconnexions 30 000 ?
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 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é que nous ayons 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 restent inaperçus. Une fois qu’un bug 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 bug qui peut causer d’autres problèmes. Il est ainsi assez récurrent qu’une fois qu’un crash fréquent est corrigé, un ou plusieurs autres apparaissent plus souvent. Cela se produit parce que le plantage qui vient d’être corrigé empêchait les autres de se produire aussi fréquemment 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 plantages les plus fréquents finissent par être réparés. Il ne nous reste plus que les rares crashs, ceux qui ne se produisent qu’une fois par mois et pour lesquels nous n’avons pas encore assez d’informations pour les réparer ou les reproduire. Un de ces rares bugs ne fera pas une grande différence à lui seul, mais une centaine de ces bugs suffisent pour justifier 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 création d’une sorte d’assurance cargo pourrait éviter aux joueurs de perdre des sommes importantes d’aUEC lorsque leur serveur tombe en panne au milieu d’une course de transport de fret. Je pense que cela a été envisagé, mais le potentiel d’abus de cette assurance en tant que “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 en cas de panne de serveur. L’idée ici est que lorsqu’un serveur tombe en panne, tous les clients seraient renvoyés au menu avec un code 30 000 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[3] et la persistance complète[4] 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ûrs, et ce ne serait qu’une solution temporaire ainsi qu’un gaspillage de temps et de travail pour le mettre en œuvre puis le maintenir. Temps et travail qui pourraient être consacrés plus intelligemment à travailler sur une solution plus appropriée à la place.
Pour l’instant, la meilleure solution 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.