Plantages et retours : rassemblez les bonnes preuves avant de modifier les fichiers

Ce que le développeur a réellement recommandé

Un fil du 5 septembre Steam rapporte des plantages du jeu suivis de redémarrages complets du système. L’éditeur a demandé au joueur d’utiliser Envoyer un retour (Give Feedback) dans le jeu afin d’envoyer des journaux, et d’inclure une adresse de contact pour un suivi. Le développeur Danga a suggéré Low graphics, qui désactive le brouillard volumétrique, comme moyen possible de réduire le problème. La réponse mentionnait un cas précédent impliquant d’éventuelles limitations de chaleur ou de puissance, et non un diagnostic confirmé pour tous les joueurs.

Utilisez ces affirmations dans leur champ d’application approprié. Low est un réglage documenté pour vérifier si le jeu est suffisamment stable pour accéder à son menu. Envoyer un retour (Give Feedback) est la voie de signalement prise en charge mentionnée dans la discussion. Aucune des deux affirmations ne prouve que tous les plantages ont une seule cause, que votre matériel est défectueux, ou qu’une réparation particulière résoudra le problème.

Cette page fournit un flux de travail original pour décrire la défaillance et recueillir un contexte utile. Elle ne prétend pas avoir reproduit le plantage ni examiné vos journaux. L’objectif est de préserver ce qui s’est passé, d’effectuer un petit nombre de vérifications appropriées, et de fournir au support un rapport qu’il peut examiner sans que vous ayez à deviner la cause interne.

D’abord, distinguez le type d’échec

Un jeu qui se ferme sur le bureau est différent d’une image figée, d’une erreur du système d’exploitation ou du redémarrage de l’ordinateur. Notez l’événement qui s’est produit. Si un message d’erreur apparaît, copiez sa formulation exacte ou capturez-le quand c’est possible. S’il n’y a pas eu de message, dites-le plutôt que d’en inventer un à partir d’un rapport en ligne similaire.

Notez aussi si l’audio a continué, si le jeu a toujours répondu aux entrées, et si le système d’exploitation est resté utilisable. Ce sont des observations, pas des diagnostics. Elles aident à séparer la fin d’un processus de jeu d’une interruption système plus large. Une description générale, comme « tout a planté », laisse ces distinctions importantes non résolues.

Si l’ordinateur entier redémarre ou s’éteint à plusieurs reprises, cessez de provoquer cette condition à répétition comme test de jeu. Conservez les informations que vous possédez déjà et cherchez un support approprié du système ou de l’appareil ainsi qu’un rapport du contexte du jeu. Un redémarrage n’est pas un problème ordinaire de fréquence d’images, et cet article ne doit pas remplacer l’évaluation matérielle.

Enregistrer la dernière action normale

Écrivez ce que vous faisiez juste avant la panne. Incluez le nom de la chambre ou de la salle, si vous étiez en train de charger, d'ouvrir un menu, de vous déplacer ou d'effectuer une interaction particulière avec un puzzle, et approximativement depuis combien de temps la session avait commencé. Une durée approximative est utile lorsqu'elle est clairement étiquetée comme approximative.

Évitez de transformer prématurément la dernière action en cause. Un plantage après être entré dans une salle ne prouve pas que la salle en soit la cause. Cependant, ce timing donne au développeur un point de départ. Le rapport le plus solide décrit la séquence de manière simple et laisse de la place à l'investigation plutôt que de nommer un défaut du moteur ou une fuite de mémoire sans preuve.

Si la panne s'est produite plus d'une fois, comparez les événements. Étaient-ils dans la même scène, après une durée similaire ou pendant différentes activités ? Indiquez le nombre d'occurrences que vous avez réellement observées. N'écrivez pas "toujours" si cela s'est produit deux fois dans des conditions que vous n'avez pas entièrement comparées.

Conservez le contexte utile.

Enregistrez la plateforme de vente, l'entrée démo ou du jeu complet, le système d'exploitation, le périphérique graphique, le processeur, la mémoire et toute information sur la build locale que le client expose. Ces détails aident le développeur à faire correspondre le rapport à un environnement. Si un champ est inconnu, laissez-le inconnu jusqu'à ce que vous puissiez vérifier plutôt que de deviner à partir de la marque de l’ordinateur.

Incluez le préréglage graphique et toutes les valeurs de paramètres pertinentes que vous avez modifiées. Un rapport rédigé après des expériences doit indiquer quelle configuration était active au moment de la panne. Sinon, le support pourrait interpréter vos paramètres actuels comme ceux qui ont produit l'événement d'origine, même s'ils diffèrent.

Gardez une courte chronologie si vous effectuez plusieurs vérifications. Elle peut indiquer que la première panne est survenue sur un certain préréglage, que vous avez ensuite mis à jour le jeu, et qu'une tentative ultérieure s'est comportée différemment. L'ordre est important car il montre quels changements ont précédé quelles observations. Une liste de tous les paramètres que vous avez essayés ne fournit pas la même information.

Utilisez Envoyer un retour (Give Feedback) lorsque le jeu s'ouvre.

Si vous pouvez accéder au jeu et à son option de retour d'expérience, utilisez le chemin nommé par l'éditeur. Expliquez le type de panne, la dernière action normale et l'environnement. L'éditeur indique que le chemin de retour d'expérience envoie des journaux qui peuvent aider. Ne supposez pas que les journaux seuls expliquent votre intention ou le moment exact où vous avez remarqué le problème.

Incluez une adresse de contact si vous souhaitez un suivi, comme demandé dans la réponse du support. Gardez le rapport centré sur le problème et évitez d'ajouter des informations personnelles non liées. Un détail de contact utile aide le développeur à demander une observation supplémentaire spécifique sans que vous ayez à publier cette information dans une discussion publique.

Si le problème est une pause répétable plutôt qu’un plantage, le fil de performance séparé demande un retour pendant que le lag se produit. Pour un plantage qui a déjà fermé le jeu, expliquez ce timing lors de la rouvre. Ne prétendez pas qu’un journal précédent particulier était attaché à moins que l’interface de retour ou le développeur ne le confirme.

Si le jeu ne peut pas accéder à son menu

com, pour expliquer que la route de signalement en jeu n’est pas disponible. Indiquer si le jeu échoue avant qu’une fenêtre n’apparaisse, lors du chargement, ou après avoir atteint l’écran titre. Ces niveaux sont plus utiles que la phrase unique ne se lance pas.

Commencez par un rapport concis et les informations que vous pouvez vérifier. N’associez pas chaque fichier de l’installation ni n’envoyez une grande archive de données système non liées. Attendez une demande de matériel supplémentaire spécifique lorsque les fichiers ou chemins nécessaires ne sont pas documentés. Les sources recherchées n’établissent pas de journal commercial actuel ni de chemin de sauvegarde à copier ici.

Si une boutique affiche une erreur, conservez ce message séparément de toute erreur du jeu. Un problème de téléchargement manquant ou client peut survenir avant que le processus du jeu ne s’exécute. Nommer la couche où apparaît la défaillance aide à éviter de traiter un problème d’installation de boutique comme un plantage d’un moteur de puzzle.

Vérifiez une mise à jour disponible du jeu

Utilisez le mécanisme de mise à jour habituel de la boutique et laissez les téléchargements en attente ou les travaux d’installation se terminer avant de comparer le comportement. C’est une pratique générale du support, pas une preuve qu’une mise à jour He Who Watches particulière corrige votre plantage. Notez si une mise à jour était disponible et si le symptôme a changé par la suite.

Ne supposez pas que la dernière annonce décrit chaque changement local de compilation, et n’inventez pas un numéro de version à partir de cette date. Si le client expose un identifiant, utilisez-le. Sinon, fournissez la date de mise à jour et la boutique que vous pouvez réellement voir. Des informations exactes incomplètes sont préférables à une étiquette que le support ne peut pas correspondre.

Une mise à jour qui modifie des énigmes ou le texte du menu ne doit pas être annoncée comme un correctif de plantage à moins que le développeur ne le reconnaisse ou qu’une observation soigneusement décrite confirme le résultat plus restreint sur votre machine. Gardez la question de la fraîcheur de l’installation séparée de celle de savoir si le problème a été résolu.

Essayez Low uniquement pour une comparaison contrôlée

La suggestion du développeur pour les graphismes bas est un test raisonnable si le jeu reste suffisamment stable pour être utilisé. Notez le préréglage précédent, sélectionnez Low, et revenez au jeu normal ou à une courte scène comparable. Notez si le symptôme initial revient. Ne forcez pas à répétition un redémarrage du système uniquement pour comparer les presets.

Si Low aide, décrivez le résultat comme une solution locale sous les conditions observées. Vous n'avez pas besoin d'inférer si le brouillard, la charge, la chaleur ou un autre facteur l'explique. Le développeur peut utiliser le changement de comportement sans que vous fournissiez un diagnostic matériel spéculatif.

Si Low n'aide pas, cette information est également utile. Incluez-la dans le rapport avec le type de défaillance et le moment où elle survient. Un test négatif ne signifie pas que la suggestion du développeur était déraisonnable ; cela signifie que votre cas a besoin de plus de preuves. Évitez de passer en revue de nombreux réglages non liés après que la première comparaison ciblée a échoué.

Vérifiez les fichiers Steam lorsque le symptôme correspond.

Valve documente une vérification de fichier via la zone Propriétés et Fichiers installés de la bibliothèque Steam du jeu. Cela peut être approprié pour des fichiers installés manquants ou endommagés. C'est un dépannage général de Steam, pas une solution démontrée pour le problème de redémarrage signalé pour ce jeu. Utilisez l'interface du client plutôt que de supprimer manuellement le contenu de l'installation.

Laissez la vérification se terminer et notez ce que le client rapporte. Si des fichiers sont récupérés, enregistrez ce fait sans supposer qu'il prouve qu'ils ont causé la panne. Ensuite, comparez le symptôme d'origine lors d'un lancement normal. Si rien ne change, incluez ce résultat dans les notes de support plutôt que de relancer la vérification indéfiniment.

Ne confondez pas la vérification de l'installation avec la validation de la progression de votre puzzle. Cela ne permet pas de résoudre un niveau ou de prouver qu'un ancien guide devrait correspondre à une nouvelle disposition. Gardez cette vérification liée aux symptômes techniques tels que les fichiers manquants ou les échecs de lancement, où elle a un but clair.

Évitez les suppositions destructrices.

Les réponses disponibles des développeurs n'instruisent pas les joueurs à supprimer des sauvegardes, retirer des dossiers de configuration, modifier le registre ou utiliser des commandes de lancement non documentées. Ne faites pas de ces actions la réponse par défaut à un plantage incertain. Elles peuvent effacer un état utile ou créer un deuxième problème sans expliquer le premier.

De même, ne désactivez pas les protections du système et ne téléchargez pas un réparateur tiers parce qu'un résultat de recherche promet une solution universelle. Utilisez le jeu, la boutique et les canaux de support de l'appareil pertinents pour la défaillance observée. Une instruction vérifiée et restreinte est plus utile qu'une procédure spectaculaire sans lien clair avec le symptôme.

Si le support demande ultérieurement un fichier ou un changement spécifique, gardez une trace de l'instruction et conservez les données pertinentes selon le besoin. Le but n'est pas d'éviter chaque modification. Il s'agit de faire des modifications pour une raison indiquée et de conserver suffisamment de contexte pour déterminer si elles ont aidé.

Capturez un petit exemple significatif.

Si la défaillance peut être observée sans provoquer un événement dangereux ou disruptif du système, un court enregistrement ou une capture d'écran peut clarifier le rapport. Montrez le message d'erreur ou l'action qui précède immédiatement le problème. Expliquez ce que le spectateur doit remarquer. Une longue session non annotée peut masquer le moment pertinent.

Gardez le contenu privé du bureau hors de la capture et marquez le matériel de fin de jeu lors du partage public. Vous pouvez souvent montrer le comportement technique sans révéler un chemin secret entier. Si la scène elle-même est un spoiler, indiquez-le avant l'image ou la vidéo plutôt que de placer la réponse dans le titre.

Ne prétendez pas qu'une reproduction est minimale à moins que vous ne l'ayez réellement réduite. Il est acceptable de dire que vous avez observé le plantage après plusieurs actions et que vous ne savez pas lesquelles sont importantes. Cette honnêteté empêche le support de supposer qu'une seule entrée visible est le déclencheur complet.

Écrivez séparément le comportement attendu et le comportement réel.

Le comportement attendu décrit ce que vous pensiez qui devait se produire : la salle devait se charger, le menu devait se fermer ou le jeu devait rester ouvert après un mouvement ordinaire. Le comportement réel décrit la défaillance visible. Les garder séparés rend le rapport compréhensible même si le développeur ne partage pas votre interprétation de l'état du puzzle.

Lorsque l'attente provient d'un guide, incluez le lien et la date. Un décalage avec la configuration ancienne d'une salle peut être un problème de version plutôt qu'un plantage. Lorsque l'attente concerne le comportement de base de l'application, indiquez-le clairement. Il n'est pas nécessaire d'orner un rapport simple de terminologie technique que vous ne pouvez pas justifier.

Ajoutez ce que vous avez essayé et le résultat de chaque étape. Jeu mis à jour, ferme toujours au chargement est utile. Tout essayé ne l'est pas. Une liste concise des vérifications réelles fait gagner du temps en montrant quelles comparaisons évidentes ont déjà été effectuées et lesquelles restent non testées.

Faites un suivi avec de nouvelles preuves.

Si le développeur demande un test ou un journal particulier, répondez directement à cette demande. Conservez la référence du rapport initial afin que les nouvelles informations restent attachées au même problème. Commencer plusieurs fils non liés peut fragmenter le contexte et rendre plus difficile de voir comment le comportement a changé au fil du temps.

Si le problème s'arrête après un changement, signalez ce qui a changé et depuis combien de temps ou sous quelles conditions vous avez testé depuis. Évitez de déclarer une solution universelle après un seul lancement réussi. Une déclaration plus précise indiquant que le jeu a terminé plusieurs sessions normales en faible est à la fois utile et honnête si c'est ce que vous avez observé.

Si elle revient, mettez à jour le même récit du problème avec les nouvelles conditions. Une récurrence n’efface pas l’amélioration précédente ; elle ajoute des informations sur ses limites. Cette distinction peut aider à aider à déterminer si le changement a réduit la fréquence, n’a affecté qu’une seule scène ou n’était pas lié.

Décidez quand arrêter les tests

Une fois que vous avez une description claire de l’échec, des détails basiques de l’environnement et les résultats de quelques vérifications appropriées, envoyez le rapport. Vous n’avez pas besoin de diagnostiquer le jeu vous-même avant de demander du soutien. Plus de tests ne valent la peine que lorsqu’ils répondent à une question spécifique restante ou suivent une instruction pertinente.

Si la machine elle-même est instable, priorisez ce problème plus large et évitez les lancements répétés qui le déclenchent. Si le jeu seul se ferme mais que votre système est autrement utilisable, conservez le rapport et attendez une étape suivante ciblée plutôt que de remplacer votre installation à plusieurs reprises. La réponse doit correspondre à la défaillance réelle que vous subissez.

Un bon rapport est une petite preuve : ce qui s’est passé, où, dans quel montage, et ce qui a changé lorsque vous avez essayé une étape documentée. Cela suffit à lancer une enquête productive tout en évitant les spéculations, les ajustements sans rapport et les modifications inutiles de fichiers.

Transformez un rapport vague en un rapport exploitable

Un rapport indiquant que le jeu plante laisse parfois plusieurs questions essentielles sans réponse. Vous pouvez l’améliorer sans spéculation technique en ajoutant le type de défaillance, le stade de jeu, la fréquence approximative et la dernière action normale. Par exemple, distinguez un retour sur le bureau lors du chargement d’un redémarrage complet du système après une longue session. Ce sont des schémas de rapport, pas des événements prétendument survenus sur votre machine.

Ajoutez ensuite l’environnement et le petit ensemble de vérifications que vous avez réellement effectuées. Indiquez si vous avez utilisé le jeu complet ou la démo, quel site l’a fourni, et quel préréglage graphique était actif. Si vous avez essayé la vérification Low ou Steam, signalez les résultats séparément de chacun. N’écrivez pas que toutes les corrections ont échoué alors que vous n’avez effectué qu’une seule vérification.

Expliquez si le comportement est répétable sous une séquence connue ou simplement récurrent dans le temps. Une défaillance répétable donne au support une séquence à tenter. Une défaillance récurrente reste importante, mais son déclencheur reste incertain. Étiqueter la différence aide le développeur à décider s’il souhaite demander une reproduction, des journaux ou plus d’informations sur la session.

Si un message d'erreur est disponible, conservez sa formulation exacte au lieu de le paraphraser en une cause. Un code inconnu peut être plus utile pour le support qu'un résumé confiant affirmant qu'il s'agit d'un problème graphique. Si vous n'avez pas capturé le message, indiquez-le et décrivez ce dont vous vous souvenez sans inventer les détails manquants.

Terminez avec l'état actuel. Pouvez-vous lancer le jeu maintenant ? Le problème persiste-t-il après la comparaison des paramètres documentée ? Le canal de retour d'information en jeu est-il accessible ? Ces réponses indiquent au support quel type de prochaine étape vous pouvez réellement effectuer. Une demande de soumission depuis le menu n'est pas utile si votre rapport explique déjà que le menu n'apparaît jamais.

Gardez le rapport original et les suivis ultérieurs connectés. Lorsqu'une nouvelle observation arrive, ajoutez-la avec sa date et ses conditions au lieu de réécrire le passé comme si vous connaissiez la cause depuis le début. Cela préserve la séquence utile de l'investigation : symptôme, vérification, résultat, et la prochaine question. Cela facilite également une évaluation honnête d'un changement réussi ultérieurement.

Le rapport amélioré n'a pas besoin d'être long. Il doit exposer les faits qui étaient cachés dans le mot parfois. Une portée claire et quelques détails observés peuvent faire gagner plus de temps qu'une page d'explications supposées du moteur, et ils donnent au développeur une base solide pour demander la pièce suivante de preuve.

Sources et preuves

1. Plantages et redémarrages : réponses de l’éditeur et du développeur ↗
2. Performances de la zone centrale : demande de retours en jeu ↗
3. Assistance Steam : vérifier les fichiers du jeu ↗
4. Contact officiel du jeu ↗