Traduction assistée par machine ; les noms des objets du jeu peuvent rester en anglais.
Prépare un rapport concis : version, étapes minimales, captures utiles et distinction entre bug et avis sur l’équilibrage.
Commencez par un problème
Un rapport de bug utile décrit un échec suffisamment clairement pour qu’une autre personne puisse l’essayer. Commencez par l’action et le résultat : ouvrir un menu particulier cache le curseur, par exemple, ou charger une session place le personnage sous le sol. Évitez de commencer par plusieurs paragraphes sur l’ensemble du jeu. La personne qui lit doit savoir quoi reproduire.
Séparer une défaillance technique d’une préférence. Un bouton qui ne fait rien, un objectif qui n’avance pas et une jauge de survie qui semble trop exigeante sont différents types de retours. Tous peuvent valoir la peine d’être signalés, mais ils nécessitent des preuves différentes. Une plainte d’équilibre doit expliquer l’expérience que vous souhaitez ; un rapport de bug doit expliquer le comportement attendu et ce qui s’est passé à la place.
Choisissez la destination du rapport par la couche défaillante
Une quête de jeu, un problème d’achat de lanceur et une erreur d’installation du pilote graphique nécessitent des équipes de support différentes. Décrivez la couche qui est en panne avant de choisir une destination. Si le jeu s’exécute mais qu’un objectif n’avance pas, commencez par le canal de signalement du développeur. Si la boutique ne peut pas terminer un téléchargement, commencez par le support de la plateforme.
Pour un problème suspect de pilote graphique, le fabricant du matériel peut avoir besoin d’un rapport distinct. AMD fournit un outil de rapport de bugs qui collecte les détails système et accepte les étapes de reproduction et les pièces jointes. Cet outil envoie des informations à AMD ; il ne remplace pas le fait d’informer le développeur d’un problème de quête ou de session sauvegardée. Utilisez-le lorsque les preuves ou les directives de soutien pointent vers la couche graphique ou système.
Évitez de publier des rapports identiques et volumineux partout sans contexte. Si deux équipes de support sont impliquées, expliquez pourquoi et conservez leurs identifiants de cas séparés en privé. Un recoupement concis peut éviter des travaux en double, tandis qu’un dump public de chaque email et pièce jointe peut exposer des informations sans aider quiconque à comprendre la limite technique.
Créez un titre que vous pourrez retrouver plus tard
Un bon titre combine le symptôme visible avec le déclencheur. Par exemple, le curseur du menu disparaît après avoir connecté un accessoire de vol est plus facile à reconnaître que de corriger le jeu. Incluez une version seulement lorsque vous l’avez vérifiée. Ne mettez pas une théorie non testée dans le titre comme si c’était un fait établi.
Pour un rapport de quête, utilisez l’objectif visible ou le nom de l’objet et déclarez l’échec. Évitez les spoilers dans le titre lorsque le canal de signalement autorise un drapeau spoiler ou une description plus neutre. Vous pouvez mettre les détails de progression nécessaires dans le corps pour les personnes enquêtant sur le problème.
Recherchez les termes clés avant de publier. Si vous trouvez un rapport existant correspondant au même déclencheur, comparez sa construction et son résultat. Ajoutez vos preuves lorsque cela est approprié au lieu de créer un autre fil presque identique. Si votre reproduction diffère matériellement, expliquez la différence. Des symptômes similaires peuvent avoir des causes différentes, donc ni ne fusionnez automatiquement les rapports sans rapport ni n’insistez pour que chaque nouvelle observation nécessite une conversation totalement séparée.
Écrire les résultats attendus et réels en duo
Le résultat attendu doit venir d’une instruction d’interface, d’un comportement antérieur normal ou d’une règle claire du jeu, pas seulement de ce que vous souhaitez voir arriver. Si vous n’êtes pas sûr que le comportement soit voulu, formulez le rapport comme une question et expliquez l’ambiguïté. Cela laisse place à la clarification sans affaiblir l’utilité de votre observation.
Le résultat réel doit décrire ce qui apparaît à l'écran ou quelles entrées restent possibles. Le texte objectif reste inchangé après cette interaction est plus utile que la mission est complètement cassée. Si vous pouvez encore vous déplacer, ouvrir des menus ou charger une autre session, incluez cette information ; elle permet de distinguer un blocage de progression d’un gel de l’application.
Gardez la paire rapprochée dans le rapport. Un lecteur ne devrait pas avoir besoin de reconstituer l'action attendue à partir de plusieurs paragraphes d'historique. Suivez avec les étapes de reproduction, puis le contexte optionnel. Cet ordre rend le rapport plus facile à parcourir et permet à l'enquêteur de tester l'affirmation centrale avant de considérer des détails moins certains.
Distinguez une reproduction d’un journal de route
Un journal de route enregistre tout ce que vous avez fait. Une reproduction contient la plus petite séquence nécessaire pour déclencher le problème. Commencez par votre journal si c’est tout ce que vous avez, puis identifiez quelles étapes sont définitivement nécessaires, éventuellement pertinentes ou simplement survenues plus tôt. N’effacez pas le contexte incertain ; déplacez-le dans une note séparée.
Si le test est sûr, variez un prérequis suspecté. Par exemple, comparez l’interaction avant et après la connexion d’un accessoire optionnel, ou comparez une session affectée avec une autre session existante. Ne commencez pas une nouvelle campagne ou ne sacrifiez pas des progrès précieux uniquement pour produire un rapport plus propre. Un état enregistré peut être un meilleur point de départ que de rejouer des heures d’actions.
Soyez explicite lorsque votre reproduction dépend d’une session particulière que vous ne pouvez pas réduire davantage. L’enquêteur peut avoir besoin de cette session plutôt que d’un itinéraire écrit plus long. Préservez-la, décrivez les étapes immédiates après le chargement et fournissez-la en privé sur demande. Cela rend le rapport pratique même lorsque le déclencheur sous-jacent est survenu bien avant l’échec visible.
Signalez la fréquence sans surestimer la confiance
Utilisez des observations que vous pouvez compter ou décrire. Le problème est survenu lors de deux chargements consécutifs est plus clair que toujours cassé. Le problème est survenu une fois après une longue session est plus clair que des plantages aléatoires tout le temps. Vous n'avez pas besoin d’un grand échantillon pour soumettre un rapport utile, mais vous devez indiquer ce que vous avez réellement observé.
Si une tentative ultérieure fonctionne, ajoutez ce résultat. Un comportement intermittent est une information précieuse, surtout lorsqu’il diffère selon la session, l’emplacement ou l’appareil connecté. Ne cachez pas une tentative réussie parce que vous craignez que cela rende le problème initial moins crédible. L’objectif est d’aider à identifier les conditions, pas de gagner un argument sur la qualité du jeu.
Lorsqu’un autre joueur signale un résultat différent, comparez le contexte plutôt que de le traiter comme une contradiction. Il peut avoir une configuration, un parcours, un paramétrage de contrôle ou un état de sauvegarde différent. Demandez les détails pertinents et gardez votre propre rapport spécifique. Un désaccord entre deux configurations documentées peut fournir un indice utile ; un échange d’affirmations générales le fait rarement.
Préparez captures d’écran et enregistrements avec un but
Steam documente sa fonction de capture d’écran et l’exigence de superposition pour cette fonctionnalité. Si votre méthode de capture configurée fonctionne, utilisez-la pour montrer l’erreur ou l’interface concernée. Un échec de capture est un problème distinct ; vous pouvez toujours décrire le symptôme ou utiliser une autre méthode de capture ordinaire disponible sur votre ordinateur.
Avant d’enregistrer, décidez ce que le spectateur a besoin de voir : l’état de départ, la séquence d’entrées et le résultat. Un court clip incluant ces éléments est plus facile à examiner que plusieurs minutes de jeu sans lien. Si l’erreur disparaît rapidement, un enregistrement peut aider à conserver son texte exact sans répétition de tentatives risquées.
Vérifiez le fichier avant de le partager. Assurez-vous que le texte est lisible et que la preuve montre effectivement le problème signalé. Supprimez le contenu privé du bureau non lié de la copie partagée, tout en conservant l’original si le support a besoin de contexte plus tard. N’ajoutez pas de modifications qui maskent l’ordre des actions ou font apparaître des tentatives séparées comme continues. Une preuve claire doit réduire l’incertitude, pas créer une histoire plus convaincante mais trompeuse.
Utilisez les pièces jointes et diagnostics avec parcimonie
Plus de données n’est pas automatiquement mieux. Commencez par les informations correspondant au problème : détails de l’appareil pour les entrées, mode d’affichage pour la résolution, objectif et session pour la progression. Si le support demande des journaux ou une exportation de diagnostic, fournissez le matériel demandé et indiquez l’heure de l’événement. Évitez de téléverser un dossier utilisateur entier comme raccourci.
l’outil de rapport d’AMD propose une copie locale des informations soumises et un champ d’historique de pilote. Ces fonctionnalités illustrent des habitudes utiles même en dehors de cet outil : tenez votre propre rapport et notez si le problème n’est apparu qu’après un changement logiciel. Cet article ne prétend pas que chaque plantage nécessite un rapport AMD ni que l’outil peut diagnostiquer le matériel non AMD.
Pour toute pièce jointe privée, vérifiez le canal de réception et les autorisations d’accès. Partagez uniquement avec le destinataire du support prévu, et évitez les liens publics lorsqu’un fichier peut contenir des informations personnelles. Gardez les preuves originales inchangées et envoyez une copie. Si une équipe de support demande un format différent, notez cette demande afin de distinguer leur exigence de diagnostic d’une solution de contournement arbitraire trouvée ailleurs.
Faites un suivi avec un résultat, pas juste une autre plainte
Lorsque le support suggère un test, rapportez la version de départ, l’étape effectuée et le résultat. Si le symptôme change, décrivez comment. Atteindre le menu mais ne pas charger est un résultat différent de l’échec avant l’ouverture de la fenêtre. Ces distinctions permettent à l’enquêteur de décider si la question suivante appartient au même chemin de défaillance.
Si une mise à jour résout le problème, indique quelle mise à jour et comment tu as vérifié. Si elle est restée, fournit la même reproduction minimale sur la nouvelle version au lieu de réécrire tout l’historique. Garde les preuves antérieures disponibles pour comparer le changement.
Si vous n’avez plus la session concernée ou si vous ne pouvez pas répéter le problème, mentionnez cette limitation. Ne fabriquez pas une reproduction propre pour maintenir le rapport actif. Une note de clôture authentique aide les futurs lecteurs à comprendre ce qui a été vérifié. Elle préserve également la confiance dans les informations utiles que vous avez déjà apportées, même lorsque l’enquête se termine sans explication définitive de l’événement initial.
Enregistrer la plus petite séquence fiable
Écrivez la condition de départ, puis les actions dans l’ordre. N’incluez que les étapes qui comptent pour l’échec. Si vous ne savez pas si un événement antérieur compte, mettez-le dans une courte note de contexte au lieu d’enfouir la reproduction dans un récit complet de votre session de jeu.
Réessayez la séquence seulement lorsque cela ne risque pas de progrès important. Si cela se produit deux fois dans le même état, dites-le. Si cela s’est produit une fois et que vous ne pouvez pas le reproduire, dites-le à la place. Un rapport honnête unique est plus utile qu’une affirmation confiante que chaque joueur rencontrera le même problème.
Incluez les informations sur la version, la boutique et l'appareil concerné. Pour un problème de saisie, indiquez le contrôleur et les autres accessoires connectés. Pour un problème d'affichage, enregistrez la résolution sélectionnée et ce que le jeu affiche réellement. Pour un problème de quête, indiquez l'objectif visible et l'interaction qui n'a pas permis de le faire avancer.
Vérifiez s'il existe une note correspondante du développeur.
Lisez les annonces officielles récentes avant de soumettre un rapport en double. Une solution connue peut vous faire gagner du temps si l'installation est en retard, et un problème connu peut déjà avoir un format de diagnostic demandé. Si le problème persiste après la mise à jour pertinente, mentionnez-le explicitement et décrivez votre nouveau test.
Les notes du 4 septembre dirigent les joueurs rencontrant des sauvegardes où ils tombent à travers le monde vers info@breathedge.com. Conservez la session affectée et fournissez-la en privé lorsqu'elle est demandée. Pour d'autres symptômes, consultez le hub de discussion officiel pour les instructions actuelles appropriées ; un contact pour un problème signalé ne remplace pas toutes les autres voies de support.
Joignez des preuves qui répondent à une question.
Une capture d'écran doit montrer clairement l'interface ou l'erreur pertinente. Un enregistrement court doit commencer suffisamment tôt pour montrer l'action déclenchante et s'arrêter une fois le résultat visible. Ni l'un ni l'autre n'a besoin de montrer l'intégralité de votre bureau, de votre page de compte ou d'une conversation non liée. Vérifiez la pièce jointe avant de la poster.
Conservez le fichier original lors de la préparation d'une image recadrée. Si l'assistance a besoin de plus de contexte plus tard, vous pouvez le fournir sans essayer de recréer le problème. Pour les journaux et archives, inspectez le contenu et partagez seulement ce qui a été demandé. N'incluez jamais les mots de passe, fichiers d'authentification ou dossiers personnels non liés dans un rapport public.
Lorsque vous décrivez une erreur, conservez son texte exact. Lorsque vous décrivez une théorie, indiquez qu'il s'agit d'une théorie. Dire qu'un problème a commencé après la connexion d'un contrôleur est une observation ; dire que le pilote du contrôleur a définitivement corrompu la sauvegarde est une affirmation causale qui nécessite des preuves beaucoup plus solides.
Bouclez après une réponse.
Si une étape demandée fonctionne, rapportez le résultat et la version utilisée. Si elle ne fonctionne pas, indiquez ce qui a changé et ce qui est resté identique. Cela permet au développeur de distinguer une amélioration partielle d'aucun effet et aide les autres lecteurs à éviter de répéter un chemin infructueux.
Gardez les commentaires de suivi dans la même discussion lorsque possible. Ouvrir un nouveau fil à chaque tentative sépare les preuves et rend l’historique plus difficile à comprendre. Une courte note finale identifiant la mise à jour fonctionnelle ou la reproduction restante est précieuse pour le joueur suivant qui cherchera le même symptôme.
Conservez une copie finale du titre du rapport, de la date et de la version testée dans vos propres notes. Si le même symptôme revient des mois plus tard, ce dossier vous permet de le décrire comme une possible récidive avec un historique connu au lieu de partir d’un souvenir vague. Mettez le lien entre la discussion précédente et expliquez ce qui est nouvellement observé.
Si vous découvrez que votre rapport utilisait la mauvaise version du jeu, corrigez-le explicitement. Laisser l'ancienne affirmation sans qualification peut induire en erreur les joueurs qui recherchent plus tard cette version pour des problèmes connus.
Sources et vérification
Cet article combine des faits cités avec des conseils éditoriaux pratiques. Suivez la version et les notes d’incertitude avant d’appliquer une voie plus ancienne.
