Traduzione assistita da macchina; i nomi degli oggetti di gioco possono rimanere in inglese.
Prepara una segnalazione concisa con versione, passaggi minimi e immagini chiare, distinguendo bug e bilanciamento.
Inizia con un problema
Un rapporto di bug utile descrive un singolo errore abbastanza chiaramente da permettere a un'altra persona di provarlo. Inizia con l'azione e il risultato: ad esempio aprire un menu particolare nasconde il cursore, oppure caricare una sessione mette il personaggio sotto il pavimento. Evita di iniziare con diversi paragrafi sull'intero gioco. La persona che legge deve sapere cosa riprodurre.
Separare un guasto tecnico da una preferenza. Un pulsante che non fa nulla, un obiettivo che non avanza e un indicatore di sopravvivenza che sembra troppo impegnativo sono tipi diversi di feedback. Tutti possono valere la pena di essere segnalati, ma richiedono prove diverse. Un reclamo di bilanciamento dovrebbe spiegare l'esperienza che desideri; un bug report dovrebbe spiegare il comportamento atteso e cosa è successo invece.
Scegli la destinazione del report tramite il livello fallitore
Una missione di gioco, un problema di acquisto di un launcher e un fallimento nell'installazione del driver grafico richiedono team di supporto diversi. Descrivi il livello che sta fallendo prima di scegliere una destinazione. Se il gioco gira ma un obiettivo non avanza, inizia con il canale di segnalazione dello sviluppatore. Se lo store non riesce a completare un download, inizia dal supporto della piattaforma.
Per un sospetto problema del driver della scheda grafica, il fornitore dell'hardware potrebbe avere bisogno di un rapporto separato. AMD fornisce uno Strumento di Segnalazione Bug che raccoglie i dettagli del sistema e accetta passaggi di riproduzione e allegati. Questo strumento invia informazioni ad AMD; non sostituisce la comunicazione al sviluppatore del gioco riguardo a un problema di quest o di sessione salvata. Usalo quando le prove o le indicazioni del supporto puntano al livello grafico o di sistema.
Evita di pubblicare ovunque rapporti identici e voluminosi senza contesto. Se sono coinvolti due team di supporto, spiega il motivo e conserva privatamente i loro identificativi di caso separati. Un riferimento incrociato conciso può prevenire lavoro duplicato, mentre un dump pubblico di ogni email e allegato può esporre informazioni senza aiutare a capire il confine tecnico.
Crea un titolo che possa essere trovato successivamente
Un buon titolo combina il sintomo visibile con il trigger. Per esempio, 'il cursore del menu scompare dopo la connessione di un accessorio di volo' è più facile da riconoscere rispetto a 'per favore, correggi il gioco'. Includi una versione solo quando l'hai verificata. Non mettere una teoria non testata nel titolo come se fosse un fatto accertato.
Per un rapporto su una quest, usa l'obiettivo visibile o il nome dell'oggetto e indica il fallimento. Evita spoiler nel titolo quando il canale di segnalazione permette un flag per spoiler o una descrizione più neutra. Puoi inserire i dettagli necessari della progressione nel corpo per chi indaga sul problema.
Cerca i termini chiave prima di pubblicare. Se trovi un rapporto esistente che corrisponde allo stesso trigger, confrontane la versione e il risultato. Aggiungi lì le tue prove quando opportuno invece di creare un altro thread quasi identico. Se la tua riproduzione differisce sostanzialmente, spiega la differenza. Sintomi simili possono avere cause diverse, quindi non unire automaticamente rapporti non correlati né insistere che ogni nuova osservazione richieda una conversazione completamente separata.
Scrivi i risultati attesi e reali come coppia
Il risultato atteso dovrebbe derivare da un'istruzione dell'interfaccia, un comportamento precedente normale o una regola chiara del gioco, e non semplicemente da ciò che desideri che accada. Se non sei sicuro se il comportamento sia intenzionale, formula il rapporto come una domanda e spiega l'ambiguità. Questo lascia spazio per chiarimenti senza ridurre l'utilità della tua osservazione.
Il risultato effettivo dovrebbe descrivere ciò che appare sullo schermo o quali input rimane possibile. Il testo dell'obiettivo rimane invariato dopo che questa interazione è più utile di quanto la missione sia completamente interrotta. Se puoi ancora muoverti, aprire menu o caricare un'altra sessione, includi quell'informazione; distingue un blocco di progressione da un blocco dell'applicazione.
Mantenere la coppia molto ravvicinata nel rapporto. Un lettore non dovrebbe dover ricostruire l'azione attesa da diversi paragrafi di storia. Segui con i passaggi di riproduzione e poi il contesto opzionale. Questo ordine rende il rapporto più facile da scansionare e permette all'investigatore di testare l'affermazione centrale prima di considerare dettagli meno certi.
Distinguere una riproduzione da un diario di percorso
Un diario di percorso registra tutto ciò che hai fatto. Una riproduzione contiene la sequenza più piccola necessaria per attivare il problema. Inizia dal diario se è tutto ciò che hai, poi identifica quali passaggi sono sicuramente necessari, potrebbero rilevanti o semplicemente avvenuti prima. Non cancellare il contesto incerto; spostalo su una nota separata.
Se il test è sicuro, varia un prerequisito sospetto. Ad esempio, confronta l'interazione prima e dopo la connessione di un accessorio opzionale, oppure confronta una sessione interessata con un'altra sessione esistente. Non iniziare una nuova campagna né sacrificare progressi preziosi solo per produrre un report più pulito. Uno stato salvato può essere un punto di partenza migliore rispetto a ripetere ore di azioni.
Sii esplicito quando la tua riproduzione dipende da una sessione particolare che non puoi ridurre ulteriormente. L'investigatore potrebbe aver bisogno di quella sessione piuttosto che di un percorso scritto più lungo. Conservalo, descrivi i passaggi immediati dopo il caricamento e forniscilo privatamente quando richiesto. Questo mantiene il report pratico anche quando il trigger sottostante si è verificato molto prima del guasto visibile.
Frequenza dei rapporti senza esagerare la fiducia
Usa osservazioni che puoi contare o descrivere. Il problema si è verificato su due carichi consecutivi è più chiaro che sempre rotto. Il problema è successo una volta dopo una lunga sessione è più chiaro che crasha casualmente tutto il tempo. Non serve un campione grande per inviare un report utile, ma devi indicare cosa hai effettivamente osservato.
Se un tentativo successivo funziona, aggiungi quel risultato. Un comportamento intermittente è un'informazione preziosa, specialmente quando varia a seconda della sessione, della posizione o del dispositivo collegato. Non nascondere un tentativo riuscito perché temi che renda il problema originale meno credibile. L'obiettivo è aiutare a identificare le condizioni, non vincere una discussione sul fatto che il gioco sia buono.
Quando un altro giocatore segnala un risultato diverso, confronta il contesto invece di trattarlo come una contraddizione. Potrebbero avere una costruzione, un percorso, una configurazione di input o uno stato di salvataggio diverso. Chiedi i dettagli rilevanti e mantieni il tuo rapporto specifico. Un disaccordo tra due configurazioni documentate può fornire un indizio utile; uno scambio di affermazioni universali raramente lo fa.
Prepara screenshot e registrazioni con uno scopo
Steam documenta la sua funzione screenshot e il requisito dell'overlay per quella funzione. Se il metodo di cattura configurato funziona, usalo per mostrare l'errore o l'interfaccia rilevante. Un fallimento della cattura è un problema separato; puoi comunque descrivere il sintomo o usare un altro metodo di cattura ordinario disponibile sul tuo computer.
Prima di registrare, decidi cosa deve vedere chi guarda: lo stato iniziale, la sequenza di input e il risultato. Un breve clip con questi elementi è più facile da esaminare rispetto a diversi minuti di gioco non correlato. Se l'errore scompare rapidamente, una registrazione può aiutare a conservare la formulazione esatta senza tentativi rischiosi ripetuti.
Rivedi il file prima di condividerlo. Controlla che il testo sia leggibile e che l'evidenza mostri effettivamente il problema segnalato. Rimuovi contenuti privati della scrivania non correlati dalla copia condivisa, mantenendo l'originale se il supporto in seguito necessita del contesto. Non aggiungere modifiche che oscurano l'ordine delle azioni o fanno apparire tentativi separati come continui. Evidenze chiare dovrebbero ridurre l'incertezza, non creare una storia più persuasiva ma fuorviante.
Usa allegati e diagnostica con parsimonia
Più dati non sono automaticamente migliori. Inizia con le informazioni che corrispondono al problema: dettagli del dispositivo per l'input, modalità di visualizzazione per la risoluzione, obiettivo e sessione per la progressione. Se il supporto richiede log o esportazione diagnostica, fornisci il materiale richiesto e etichetta l'orario dell'evento. Evita di caricare un'intera cartella utente come scorciatoia.
Lo strumento di report di AMD offre una copia locale delle informazioni inviate e un campo per la cronologia dei driver. Queste funzionalità illustrano abitudini utili anche al di fuori di quello strumento: conserva il tuo report e registra se il problema è apparso solo dopo una modifica del software. Questo articolo non sostiene che ogni crash richieda un report AMD o che lo strumento possa diagnosticare hardware non AMD.
Per qualsiasi allegato privato, controlla il canale di ricezione e i permessi di accesso. Condividi solo con il destinatario di supporto previsto ed evita link pubblici quando un file può contenere informazioni personali. Mantieni intatte le prove originali e invia una copia. Se un team di supporto richiede un formato diverso, annota tale richiesta in modo da poter distinguere la loro necessità diagnostica da una soluzione arbitraria trovata altrove.
Segui con un risultato, non solo con un’altra lamentela
Quando il supporto suggerisce un test, segnala la versione iniziale, il passo eseguito e il risultato. Se il sintomo cambia, descrivi come. Raggiungere il menu ma non riuscire comunque a caricare è un risultato diverso dal fallire prima che la finestra si apra. Queste distinzioni permettono all’investigatore di decidere se la prossima domanda appartiene allo stesso percorso di errore.
Se un aggiornamento risolve il problema, indica quale aggiornamento e come l’hai verificato. Se persiste, fornisci la stessa riproduzione minima sulla nuova versione invece di riscrivere l’intera cronologia. Mantieni disponibili le prove precedenti in modo che il cambiamento possa essere confrontato.
Se non hai più la sessione interessata o non puoi ripetere il problema, dichiara tale limitazione. Non creare una riproduzione pulita per mantenere attivo il report. Una nota di chiusura veritiera aiuta i lettori futuri a capire quanto è stato verificato. Preserva anche la fiducia nelle informazioni utili che hai già fornito, anche quando l’indagine termina senza una spiegazione definitiva per l’evento originale.
Registra la sequenza più piccola affidabile
Scrivi la condizione iniziale, poi le azioni in ordine. Includi solo i passaggi rilevanti per il fallimento. Se non sai se un evento precedente è importante, inseriscilo in una breve nota di contesto invece di seppellire la riproduzione all’interno di un resoconto completo della tua sessione di gioco.
Ripeti la sequenza solo quando farlo non rischia di compromettere progressi importanti. Se accade due volte dallo stesso stato, dillo. Se è successo una volta e non puoi riprodurlo, dillo invece. Un report onesto di un solo caso è più utile di un’affermazione sicura che ogni giocatore incontrerà lo stesso problema.
Includi informazioni sul build, sullo store e sul dispositivo pertinente. Per un problema di input, indica il controller e altri accessori collegati. Per un problema di visualizzazione, registra la risoluzione selezionata e ciò che il gioco mostra effettivamente. Per un problema relativo a una missione, indica l'obiettivo visibile e l'interazione che non ha permesso di avanzare.
Controlla la presenza di una nota corrispondente dello sviluppatore
Leggi gli annunci ufficiali recenti prima di inviare un report duplicato. Una soluzione nota può farti risparmiare tempo se l'installazione è arretrata, e un problema noto può già avere un formato diagnostico richiesto. Se il problema persiste dopo l'aggiornamento pertinente, menzionalo esplicitamente e descrivi la ritest effettuata.
Le note del 4 settembre indirizzano i giocatori che riscontrano salvataggi che cadono nel mondo a info@breathedge.com. Conserva la sessione interessata e fornisci essa privatamente quando richiesto. Per altri sintomi, consulta l'hub ufficiale di discussione per le istruzioni attuali appropriate; un contatto per un problema segnalato non sostituisce ogni altro canale di supporto.
Allega prove che rispondano a una domanda
Uno screenshot dovrebbe mostrare chiaramente l'interfaccia o l'errore rilevante. Una breve registrazione dovrebbe iniziare abbastanza presto da mostrare l'azione che causa il problema e fermarsi una volta visibile il risultato. Nessuno dei due deve includere l'intero desktop, la pagina dell'account o conversazioni non correlate. Rivedi l'allegato prima di postarlo.
Conserva il file originale quando prepari un'immagine ritagliata. Se l'assistenza in seguito avrà bisogno di più contesto, puoi fornirlo senza cercare di ricreare il problema. Per log e archivi, controlla il contenuto e condividi solo ciò che è stato richiesto. Non includere mai password, file di autenticazione o cartelle personali non correlate in un report pubblico.
Quando descrivi un errore, conserva il testo esatto. Quando descrivi una teoria, etichettala come teoria. Dire che un problema è iniziato dopo aver collegato un controller è un'osservazione; dire che il driver del controller ha sicuramente corrotto il salvataggio è un'affermazione causale che richiede prove molto più solide.
Chiudi il ciclo dopo una risposta
Se un passaggio richiesto funziona, segnala il risultato e la versione utilizzata. Se non funziona, indica cosa è cambiato e cosa è rimasto uguale. Questo permette allo sviluppatore di distinguere un miglioramento parziale dall'assenza di effetto e aiuta altri lettori a evitare di ripetere un percorso non riuscito.
Mantieni i commenti di follow-up nella stessa discussione quando possibile. Iniziare un nuovo thread per ogni tentativo separa le prove e rende più difficile comprendere la storia. Una breve nota finale che identifica l'aggiornamento in corso o la riproduzione rimanente è utile al prossimo giocatore che cerca lo stesso sintomo.
Conserva una copia finale del titolo del rapporto, della data e della build testata nelle tue note. Se lo stesso sintomo ritorna mesi dopo, quel record ti permette di descriverlo come una possibile ricorrenza con una storia nota invece di partire da un ricordo vago. Collega la discussione precedente e spiega ciò che è stato osservato di nuovo.
Se scopri che il tuo rapporto ha utilizzato la versione del gioco sbagliata, correggilo esplicitamente. Lasciare la vecchia segnalazione non qualificata può ingannare i giocatori che in seguito cercano quella versione per problemi noti.
Fonti e verifiche
Questo articolo combina fatti citati con consigli pratici di redazione. Seguire le note sulla versione e sull'incertezza prima di applicare un percorso più vecchio.
