- 01Prima di tutto, distinguere il tipo di guasto
- 02Registra l'ultima azione normale
- 03Preservare il contesto utile
- 04Usa Invia un commento (Give Feedback) quando il gioco si apre
Basandosi sulle fonti collegate e sull'analisi originale. Non si afferma alcun playtest diretto.
Localizzato dall'edizione di ricerca inglese; i nomi propri in gioco vengono mantenuti per la ricerca.
Cosa ha effettivamente consigliato lo sviluppatore
Un thread del 5 settembre Steam segnala crash del gioco seguiti da riavvii dell'intero sistema. L'editore ha chiesto al giocatore di usare Invia un commento (Give Feedback) nel gioco per inviare i log e di includere un indirizzo di contatto per il follow-up. Lo sviluppatore Danga ha suggerito la grafica bassa, che disabilita la nebbia volumetrica, come possibile modo per ridurre il problema. La risposta menzionava un caso precedente riguardante possibili limitazioni di calore o potenza, non una diagnosi confermata per ogni giocatore.
Usa queste affermazioni nel loro giusto ambito. Low è un'impostazione documentata per verificare se il gioco è abbastanza stabile da accedere al suo menu. Invia un commento (Give Feedback) è la via di segnalazione supportata indicata nella discussione. Nessuna delle due affermazioni dimostra che tutti i crash abbiano una sola causa, che il tuo hardware sia difettoso o che una particolare riparazione risolva il problema.
Questa pagina fornisce un flusso di lavoro originale per descrivere il guasto e raccogliere un contesto utile. Non afferma di aver riprodotto il crash o di aver esaminato i tuoi log. L'obiettivo è preservare quanto accaduto, effettuare un piccolo numero di controlli appropriati e fornire al supporto un rapporto che possa indagare senza che tu debba indovinare la causa interna.
Prima di tutto, distinguere il tipo di guasto
Un gioco che si chiude sul desktop è diverso da un'immagine bloccata, un errore del sistema operativo o il riavvio del computer. Registra quale evento si è verificato. Se appare un messaggio di errore, copiane la formulazione esatta o catturalo quando possibile. Se non c'era alcun messaggio, di' questo invece di inventarne uno da un report online simile.
Nota anche se l'audio è continuato, se il gioco ha ancora risposto agli input e se il sistema operativo è rimasto utilizzabile. Queste sono osservazioni, non diagnosi. Aiutano a separare la fine di un processo di gioco da un'interruzione più ampia del sistema. Una descrizione ampia, come tutto crashato, lascia queste importanti distinzioni irrisolte.
Se l'intero computer si riavvia o si spegne ripetutamente, smetti di provocare ripetutamente la condizione come test di gioco. Conserva le informazioni che già possiedi e cerca il supporto appropriato di sistema o dispositivo, oltre a segnalare il contesto del gioco. Un riavvio non è un problema ordinario di frame rate, e questo articolo non dovrebbe essere usato come sostituto della valutazione hardware.
Registra l'ultima azione normale
Scrivi cosa stavi facendo poco prima del guasto. Includi la camera o il nome della stanza, se stavi caricando, aprendo un menu, spostandoti o svolgendo una particolare interazione con un puzzle, e approssimativamente da quanto tempo la sessione era durata. Una durata approssimativa è utile quando chiaramente etichettata approssimativa.
Evita di trasformare prematuramente l'ultima azione in una causa. Un incidente dopo essere entrato in una stanza non prova che la stanza lo abbia causato. Tuttavia, quel tempismo dà allo sviluppatore un punto di partenza. Il rapporto più solido descrive la sequenza in modo chiaro e lascia spazio per l'indagine invece di indicare un difetto del motore o una perdita di memoria senza prove.
Se il guasto è avvenuto più di una volta, confronta gli eventi. Si sono svolti nella stessa scena, dopo una durata simile o durante attività diverse? Indica il numero di eventi che hai effettivamente osservato. Non scrivere sempre se è successo due volte in condizioni che non hai ancora confrontato completamente.
Preservare il contesto utile
Registra la presentina, la demo o l'intera voce del gioco, il sistema operativo, il dispositivo grafico, il processore, la memoria e qualsiasi informazione locale di build esposta dal client. Questi dettagli aiutano lo sviluppatore ad abbinare il report a un ambiente. Se un campo è sconosciuto, lascialo sconosciuto finché non puoi controllare invece di indovinare dal marchio del computer.
Includi il preset grafico e eventuali valori di impostazione rilevanti che hai modificato. Un report fatto dopo esperimenti dovrebbe indicare quale configurazione era attiva al momento del guasto. Altrimenti il supporto potrebbe interpretare le tue impostazioni attuali come quelle che hanno prodotto l'evento originale, anche se differiscono.
Tieni una breve tempistica se fai più controlli. Può dire che il primo guasto è avvenuto su un preset, poi hai aggiornato il gioco e un tentativo successivo si è comportato diversamente. L'ordine conta perché mostra quali cambiamenti hanno preceduto quali osservazioni. Una lista di tutte le impostazioni che hai provato non fornisce le stesse informazioni.
Usa Invia un commento (Give Feedback) quando il gioco si apre
Se riesci a raggiungere il gioco e la sua opzione feedback, usa la strada indicata dall'editore. Spiega il tipo di guasto, l'ultima azione normale e l'ambiente. L'editore dice che la via del feedback invia log che potrebbero aiutare. Non dare per scontato che i log da soli spieghino la tua intenzione o il momento esatto in cui hai notato il problema.
Includi un indirizzo di contatto se desideri un follow-up, come richiesto nella risposta di supporto. Mantieni il rapporto focalizzato sul problema ed evita di aggiungere informazioni personali non correlate. Un dettaglio di contatto utile aiuta lo sviluppatore a chiedere un'osservazione aggiuntiva specifica senza richiedere che tu pubblichi quell'informazione in una discussione pubblica.
Se il problema è una pausa ripetibile piuttosto che un crash, il thread separato delle prestazioni chiede un feedback mentre il lag sta avvenendo. Per un crash che ha già chiuso il gioco, spiega quel momento quando lo riapri. Non affermare che un particolare log precedente fosse allegato a meno che l'interfaccia di feedback o lo sviluppatore non lo confermi.
Se il gioco non riesce ad accedere al menu
spiega che la modalità di segnalazione in-game non è disponibile. Indica se il gioco fallisce prima che appaia una finestra, durante il caricamento o dopo aver raggiunto la schermata del titolo. Queste fasi sono più utili della semplice frase "non si avvia".
Inizia con un rapporto conciso e le informazioni che puoi verificare. Non allegare ogni file dall'installazione o inviare un grande archivio di dati di sistema non correlati. Attendi una richiesta di materiale aggiuntivo specifico quando i file o i percorsi necessari non sono documentati. Le fonti ricercate non stabiliscono un log retail o un percorso di salvataggio attuale da copiare qui.
Se un negozio mostra un errore, conserva quel messaggio separatamente da qualsiasi errore del gioco. Un problema di download mancante o del client può verificarsi prima che il processo del gioco venga eseguito. Indicare lo strato in cui si verifica il fallimento aiuta a evitare di trattare un problema di installazione del negozio come se fosse un crash del motore di gioco.
Controlla se è disponibile un aggiornamento del gioco
Usa il meccanismo di aggiornamento normale del negozio e lascia completare i download o l'installazione in corso prima di confrontare il comportamento. Questa è una pratica generale di supporto, non una prova che un particolare aggiornamento He Who Watches risolva il tuo crash. Registra se era disponibile un aggiornamento e se il sintomo è cambiato dopo.
Non dare per scontato che l'annuncio più recente descriva ogni cambiamento di build locale, e non inventare un numero di versione dalla data. Se il client mostra un identificatore, usalo. Altrimenti fornisci la data dell'aggiornamento e il negozio che puoi effettivamente vedere. Informazioni incomplete ma accurate sono preferibili a un'etichetta che il supporto non può verificare.
Un aggiornamento che modifica puzzle o testo del menu non dovrebbe essere pubblicizzato come una correzione di crash a meno che lo sviluppatore non lo dica o un'osservazione accuratamente descritta supporti il risultato più specifico sulla tua macchina. Mantieni separata la questione della freschezza dell'installazione dalla questione se il problema sia stato risolto.
Prova Solo "Basso" come confronto controllato
Il suggerimento dello sviluppatore di usare i grafici Bassi è un piccolo test ragionevole se il gioco rimane abbastanza stabile da poter essere usato. Nota il preset precedente, seleziona Basso e ritorna al gioco normale o a una breve scena comparabile. Registra se il sintomo originale ritorna. Non forzare ripetutamente un riavvio del sistema solo per confrontare i preset.
Se Low aiuta, descrivi il risultato come una soluzione locale nelle condizioni osservate. Non è necessario dedurre se nebbia, carico, calore o un altro fattore lo spiegano. Lo sviluppatore può usare il cambiamento di comportamento senza che tu fornisca una diagnosi hardware speculativa.
Se il livello basso non aiuta, anche quell'informazione è utile. Includilo nel rapporto con il tipo di guasto e il tempismo. Un test negativo non significa che il suggerimento dello sviluppatore sia stato irragionevole; significa che il tuo caso ha bisogno di più prove. Evita di passare da molte impostazioni non correlate dopo che il primo confronto focalizzato è fallito.
Verifica Steam file quando il sintomo si adatta
Valve documenta un controllo di verifica file tramite l'area Proprietà del gioco e File installati della libreria Steam. Questo può essere appropriato per file installati mancanti o danneggiati. Si tratta di una risoluzione generale Steam problemi, non una soluzione dimostrata per il problema di riavvio segnalato di questo gioco. Usa l'interfaccia client invece di eliminare manualmente il contenuto dell'installazione.
Lascia che la verifica finisca e annota cosa riporta il cliente. Se i file vengono riacquisiti, registra quel fatto senza presumere che provi che siano stati la causa del guasto. Poi confronta il sintomo originale con un avvio normale. Se nulla cambia, includi quel risultato nelle note di supporto invece di rieseguire la verifica indefinitamente.
Non confondere la verifica dell'installazione con la validazione dei progressi del tuo puzzle. Non stabilisce una soluzione per una stanza né dimostra che una vecchia guida debba corrispondere a un nuovo layout. Mantieni il controllo legato a sintomi tecnici come file mancanti o fallimenti di avvio, quando ha uno scopo chiaro.
Evita le ipotesi distruttive
Le risposte disponibili dagli sviluppatori non istruiscono i giocatori a cancellare i salvataggi, rimuovere cartelle di configurazione, modificare il registro o usare comandi di avvio non documentati. Non rendere queste azioni la risposta predefinita a un crash incerto. Possono cancellare uno stato utile o creare un secondo problema senza spiegare il primo.
Allo stesso modo, non disattivare le protezioni di sistema né scaricare un fixer di terze parti perché un risultato di ricerca promette una soluzione universale. Usa i canali di supporto per giochi, store e dispositivo rilevanti per il guasto osservato. Un'istruzione verificata e ristretta è più utile di una procedura drastica senza un collegamento chiaro al sintomo.
Se in seguito il supporto richiede un file o una modifica specifica, conserva un registro dell'istruzione e conserva i dati rilevanti quando necessario. L'obiettivo non è evitare ogni modifica. È apportare modifiche per una ragione dichiarata e mantenere abbastanza contesto per capire se hanno aiutato.
Cattura un piccolo esempio significativo
Se il malfunzionamento può essere osservato senza provocare un evento di sistema pericoloso o dirompente, una breve registrazione o uno screenshot può chiarire il rapporto. Mostra il messaggio di errore o l'azione che precede immediatamente il problema. Spiega cosa dovrebbe notare chi guarda. Una sessione lunga senza annotazioni può nascondere il momento rilevante.
Tieni fuori dal cattura il contenuto privato del desktop e segnala il materiale tardivo del gioco quando condividi pubblicamente. Spesso puoi mostrare il comportamento tecnico senza rivelare un intero percorso segreto. Se la scena stessa è uno spoiler, dillo prima dell'immagine o del video anziché mettere la risposta nel titolo.
Non affermare che una riproduzione sia minima a meno che tu non l'abbia effettivamente resa più ristretta. È corretto dire che hai osservato il crash dopo diverse azioni e non sai quale di esse importi. Quella onestà impedisce all'assistenza di presumere che un singolo input visibile sia il trigger completo.
Scrivi separatamente il comportamento previsto e quello effettivo.
Il comportamento previsto descrive ciò che pensavi dovesse succedere: la stanza dovrebbe caricarsi, il menu dovrebbe chiudersi o il gioco dovrebbe rimanere aperto dopo una mossa ordinaria. Il comportamento effettivo descrive il malfunzionamento visibile. Tenerli separati rende il rapporto comprensibile anche se lo sviluppatore non condivide la tua interpretazione dello stato del puzzle.
Quando l'aspettativa proviene da una guida, includi il link e la data. Una discrepanza con una vecchia disposizione della stanza potrebbe essere un problema di versione piuttosto che un crash. Quando l'aspettativa è un comportamento base dell'applicazione, dillo chiaramente. Non c'è bisogno di decorare un rapporto semplice con terminologia tecnica che non puoi dimostrare.
Aggiungi ciò che hai provato e il risultato di ogni passaggio. Aggiornato il gioco, chiusura ancora al caricamento è utile. Ho provato di tutto non lo è. Una lista concisa dei controlli reali risparmia tempo mostrando quali confronti ovvi sono già stati completati e quali rimangono da testare.
Segui con nuove prove.
Se lo sviluppatore chiede un test o un log particolare, rispondi direttamente alla richiesta. Mantieni il riferimento al rapporto originale in modo che le nuove informazioni restino collegate allo stesso problema. Iniziare diversi thread non correlati può dividere il contesto e rendere più difficile vedere come il comportamento è cambiato nel tempo.
Se il problema si interrompe dopo una modifica, segnala cosa è cambiato e per quanto tempo o in quali condizioni hai testato da allora. Evita di dichiarare una soluzione universale dopo un solo avvio riuscito. Una dichiarazione più ristretta che il gioco ha completato diverse sessioni normali a Basso è sia utile sia onesta se è ciò che hai osservato.
Se ritorna, aggiorna lo stesso resoconto del problema con le nuove condizioni. Una ricorrenza non cancella il miglioramento precedente; aggiunge informazioni sui suoi limiti. Questa distinzione può aiutare l'assistenza a identificare se la modifica ha ridotto la frequenza, ha interessato solo una scena o non era correlata.
Decidi quando interrompere i test
Una volta che hai una descrizione chiara del guasto, i dettagli base dell'ambiente e i risultati di alcuni controlli appropriati, invia il report. Non è necessario diagnosticare il gioco da soli prima di chiedere supporto. Ulteriori test hanno senso solo se rispondono a una specifica domanda restante o seguono un'istruzione rilevante.
Se la macchina stessa è instabile, dai priorità a quel problema più ampio ed evita ripetuti avvii del gioco che lo scatenano. Se il gioco da solo si chiude ma il sistema è altrimenti utilizzabile, conserva il report e attendi un passo successivo mirato invece di reinstallare continuamente il gioco. La risposta dovrebbe adattarsi al guasto che si verifica realmente.
Un buon report è un piccolo pezzo di prova: cosa è successo, dove, con quale configurazione e cosa è cambiato quando hai seguito un passo documentato. Questo è sufficiente per iniziare un'indagine produttiva evitando speculazioni, modifiche non correlate e cambiamenti di file non necessari.
Trasforma un report vago in uno azionabile
Un report che dice che il gioco crasha a volte lascia senza risposta diverse domande essenziali. Puoi migliorarlo senza speculazioni tecniche aggiungendo il tipo di guasto, la fase di gioco, la frequenza approssimativa e l'ultima azione normale. Ad esempio, distingui tra un ritorno al desktop durante il caricamento e un riavvio dell'intero sistema dopo una lunga sessione. Questi sono modelli di report, non eventi dichiarati come avvenuti sulla tua macchina.
Poi aggiungi l'ambiente e il piccolo set di controlli che hai effettivamente completato. Indica se hai usato il gioco completo o la demo, da quale store è stato fornito e quale preset grafico era attivo. Se hai provato la verifica Low o Steam, riporta il risultato di ciascuna separatamente. Non scrivere che tutte le soluzioni hanno fallito se hai effettuato solo un controllo.
Spiega se il comportamento è ripetibile seguendo una sequenza nota o semplicemente ricorrente nel tempo. Un guasto ripetibile fornisce all'assistenza una sequenza da provare. Un guasto ricorrente è comunque importante, ma il suo innesco resta incerto. Etichettare la differenza aiuta lo sviluppatore a decidere se richiedere una riproduzione, i log o ulteriori informazioni sulla sessione.
Se è disponibile un messaggio di errore, conserva la sua formulazione esatta invece di riformularlo come causa. Un codice sconosciuto può essere più utile per l'assistenza rispetto a un riassunto sicuro che significhi un problema grafico. Se non hai registrato il messaggio, dì questo e descrivi ciò che ricordi senza inventare i dettagli mancanti.
Termina con lo stato attuale. Puoi avviare il gioco ora? Il problema persiste dopo il confronto dei settaggi documentati? È accessibile la modalità di feedback in gioco? Queste risposte dicono al supporto quale tipo di passo successivo puoi effettivamente eseguire. Una richiesta di invio dal menu non è utile se il tuo rapporto spiega già che il menu non appare mai.
Mantieni il rapporto originale e i successivi aggiornamenti collegati. Quando arriva una nuova osservazione, aggiungila con la data e le condizioni invece di riscrivere il passato come se conoscessi la causa dall'inizio. Questo preserva la sequenza utile dell'indagine: sintomo, controllo, risultato e la domanda successiva. Rende inoltre più facile valutare onestamente una modifica riuscita in seguito.
Il rapporto migliorato non deve essere lungo. Deve esporre i fatti che a volte erano nascosti nelle parole. Una chiara definizione del campo e pochi dettagli osservati possono far risparmiare più tempo di una pagina di spiegazioni ipotetiche sul motore, e forniscono allo sviluppatore una solida base per richiedere il prossimo elemento di evidenza.