Vous êtes sur la page 1sur 3

Questions / Réponses sur les crashs serveur ou client entrainant

l’erreur 30000
@cjohnson (CIG) sur Spectrum
19 mai 2020

Traduit et remanié par LeMage

Quand les serveurs seront-ils stables ?

À la fin de la bêta. Pourquoi pas avant ? Parce que nous devons finir de faire le reste
du jeu en premier.

Lorsqu'un jeu est en cours d'élaboration en tant qu'alpha fermée, l'accent est mis sur
le développement de fonctionnalités et de contenu. La stabilisation et la correction des bugs
sont en retrait. Seuls les problèmes qui entraveraient le développement sont résolus. Cela
peut sembler une manière non professionnelle de faire les choses, mais l'idée derrière cela
est d'essayer de nouvelles fonctionnalités et nouveaux contenus aussi rapidement que
possible et à moindre coût. Cela permet aux développeurs de découvrir quelles parties du jeu
doivent être revues. Il ne sert à rien de passer du temps à corriger un bug sur un contenu 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 semi-avancé au moins
jusqu'à ce que toutes les fonctionnalités et le contenu aient été ajoutés. Le jeu entrera alors
dans la phase bêta du développement où la correction de bugs, l'optimisation, l'équilibrage et
le polissage seront au premier plan. Idéalement, aucune nouvelle fonctionnalité n’est ajoutée
pendant la version bêta, mais il y a presque toujours des changements de dernière minute.
Bien sûr, Star Citizen est un développement ouvert, donc bien que l'alpha se concentre
toujours sur l'essai de différentes idées, nous avons besoin que le jeu soit suffisamment stable
et fonctionnel pour que les joueurs ayant investi dans le développement (contributeurs) le
testent et donnent leur avis. Le mot clé est « suffisamment », ce qui ne signifie pas « parfait ».
Il est important que nous trouvions le bon équilibre entre la correction de bugs et la poursuite
du développement : trop de corrections de bugs et le développement ralenti, trop peu de
corrections et nous n'obtenons pas suffisamment de commentaires sur les bugs qui entravent
le développement.

CIG trouve-t-il le bon équilibre entre correction de bugs et développement ?

Le problème de déterminer si une build est suffisamment stable est que nous ne
pouvons regarder que la façon dont la stabilité affecte la base de joueurs dans son ensemble,
c'est-à-dire l’impact sur la moyenne.

Il y aura donc des contributeurs chanceux qui connaîtront beaucoup moins de crashs
ou d'autres problèmes que la moyenne tandis qu'il y aura des pauvres âmes pour qui l’alpha
apparaît comme un festival de crashs et de bugs.

Demandez aux joueurs chanceux si nous avons le bon équilibre et ils pourraient dire
« non », le jeu est assez stable et nous devons nous concentrer davantage sur l'expansion du
jeu. Demandez aux malchanceux et ils pourraient aussi dire « non » mais veulent que nous
arrêtions de travailler sur de nouvelles fonctionnalités jusqu'à ce que tous les bugs actuels
soient corrigés. Finalement très peu de personnes diront « oui ».

En règle générale, avant de publier un patch sur le Live, nous essayons de nous assurer
qu'il est au moins aussi stable que la version précédente du Live. Certains patchs peuvent être
plus ou moins stables que les précédents pour des styles de jeu en particuliers, mais, dans
l'ensemble, la stabilité devrait s'améliorer d'un patch à l'autre. Bien sûr, parfois, les choses ne
fonctionnent pas comme nous le souhaiterions et la stabilité moyenne ne sera pas aussi bonne
que dans la version précédente.

Pourquoi CIG ne répare pas les plantages des serveurs provoquant des erreurs de
déconnexion de type 30K ?

Nous le faisons même s’il semble que ce ne soit pas le cas, car, quelle qu'en soit la
cause, tous les plantages serveurs entraînent la même erreur de déconnexion 30000 sur les
clients. Cette déconnexion se produit quand le serveur tombe en panne et que les clients
cessent soudainement de recevoir du trafic réseau de sa part. Les clients attendent ensuite 30
secondes pour voir si le trafic reprendra (au cas où le serveur serait bloqué temporairement
ou s'il y a eu une courte panne de réseau) avant d'abandonner et d'afficher l'erreur de
déconnexion. Au cours de ces 30 secondes, les joueurs verront les portes ne pas s'ouvrir ainsi
que l'IA bloquée, les terminaux et autres entités deviendront non réactifs. Les joueurs
perçoivent parfois ces symptômes comme un signe que le serveur est sur le point de planter,
et vous pouvez lire dans le chat en jeu des messages disant qu'un plantage du serveur arrive,
mais la vérité est que le serveur est déjà mort (Le chat en jeu ne fonctionne que parce qu'il
est géré par un autre serveur).
Lorsqu'un nouveau patch est en cours de préparation sur le PTU, de nouvelles versions
sont disponibles en téléchargement presque quotidiennement. Une fois que les développeurs
ont mis la nouvelle version sur les serveurs et en téléchargement, ils surveillent la mise en
place pendant les premières heures -travaillant souvent tard- et recherchent tout élément
pouvant indiquer un problème qui doit être traité immédiatement.

Pendant les heures suivantes, les contributeurs jouent au jeu, envoient leurs rapports
de plantage, soumettent à l’Issue Council des problèmes, postent des commentaires dans les
forums, etc. Les plantages de serveurs sont tous automatiquement enregistrés dans une base
de données. Lorsque les studios de l’EU démarrent l’activité, l'AQ technique examine les
plantages de clients téléchargés et les plantages de serveurs enregistrés. Il évalue d’abord
quels sont les plus problématiques, en fonction de la fréquence à laquelle ils se produisent et
du délai après avoir rejoint une partie. Les pannes de serveur atteignent presque toujours le
haut de la pile à traiter, uniquement parce qu'elles affectent plus de personnes que les pannes
individuelles de clients. Les rapports sont transmis à la production pour triage. Celui-ci
confirme les priorités et les crashs à essayer de reproduire pour les corriger.

Si CIG ne peut pas rendre les serveurs stables, pourquoi ne pas fournir une sorte de
récupération de l’état des joueurs ?

Il a été suggéré que la mise ne place d'une sorte d'assurance cargo pourrait empêcher
les joueurs de perdre d'importantes sommes d'aUEC lorsque leur serveur crashe. Je crois que
cela a été envisagé, mais les abus potentiels en exploitant les mécanismes de ce système sont
évidents. Tant que ce problème ne sera pas résolu, il est peu probable que l'assurance-
cargaison apparaisse dans le jeu.

Une autre suggestion consiste à ajouter une sorte de récupération après panne du
serveur. L'idée ici est que lorsqu'un serveur tombe en panne, tous les clients seraient renvoyés
sur le menu du jeu avec un 30K comme maintenant, mais auraient alors la possibilité de
rejoindre un serveur nouvellement créé avec une restauration de l'état de persistance de
l'original. C'est en fait quelque chose que nous espérons faire, mais cela nécessite plus de
travail sur le système SOCS et une persistance complète, donc c'est encore loin.

Il y a également eu d'autres suggestions telles que des clients ou des serveurs


sauvegardant l'état du jeu dans des fichiers locaux. Mais ceux-ci ne seraient pas sécurisés, ou
seraient une solution temporaire entrainant une perte de temps de travail pour mettre en
œuvre et maintenir ce système au lieu de travailler directement sur la bonne solution.

Pour l'instant, pour nous la meilleure option est de continuer à corriger les plantages
au fur et à mesure que nous les trouvons en espérant que les serveurs soient suffisamment
stables pour que le plus grand nombre de joueurs puissent tester le jeu.

Vous aimerez peut-être aussi