- 01Najpierw rozróżnij rodzaj awarii
- 02Zapisz ostatnią normalną akcję
- 03Zachowaj użyteczny kontekst
- 04Użyj Przekaż opinię (Give Feedback) po uruchomieniu gry
Na podstawie podlinkowanych źródeł i oryginalnej analizy. Nie twierdzono, że testowano gry bezpośrednio.
Zlokalizowane z angielskiego wydania badawczego; w grze zachowano nazwy własne do wyszukiwania.
Co deweloper faktycznie zalecił
W wątku Steam z 5 września zgłoszono awarie gry, po których następowały restarty całego systemu. Wydawca poprosił gracza o użycie Przekaż opinię (Give Feedback) w grze, aby można było wysłać logi, oraz o podanie adresu kontaktowego do dalszego postępowania. Deweloper Danga zasugerował ustawienie grafiki Low (niskie), która wyłącza efekt objętościowej mgły, jako możliwy sposób ograniczenia problemu. W odpowiedzi wspomniano o wcześniejszym przypadku związanym z możliwymi ograniczeniami cieplnymi lub energetycznymi, a nie o potwierdzonej diagnozie dla każdego gracza.
Używaj tych stwierdzeń w odpowiednim zakresie. Low jest udokumentowanym ustawieniem do wypróbowania, jeśli gra jest na tyle stabilna, by dojść do menu. Przekaż opinię (Give Feedback) jest wspieraną drogą raportowania wymienioną w dyskusji. Żadne ze stwierdzeń nie dowodzi, że wszystkie awarie mają ten sam powód, że Twój sprzęt jest uszkodzony ani że konkretna naprawa rozwiąże problem.
Ta strona przedstawia oryginalny przepływ pracy do opisu awarii i zbierania użytecznego kontekstu. Nie twierdzi, że odtworzono awarię ani że sprawdzono Twoje logi. Celem jest zachowanie tego, co się wydarzyło, wykonanie niewielkiej liczby odpowiednich kontroli i dostarczenie wsparciu raportu, który może zbadać bez konieczności zgadywania przyczyny wewnętrznej.
Najpierw rozróżnij rodzaj awarii
Zamknięcie gry na pulpit różni się od zamrożonego obrazu, błędu systemu operacyjnego lub restartu komputera. Zapisz, jakie zdarzenie wystąpiło. Jeśli pojawił się komunikat o błędzie, skopiuj jego dokładną treść lub zrób zrzut, gdy to możliwe. Jeśli żadnego komunikatu nie było, napisz o tym zamiast wymyślać jeden na podstawie podobnego zgłoszenia online.
Zauważ także, czy dźwięk był kontynuowany, czy gra nadal reagowała na wejście i czy system operacyjny pozostawał użyteczny. To są obserwacje, nie diagnozy. Pomagają one odróżnić zakończenie procesu gry od szerszej przerwy systemowej. Ogólny opis, taki jak wszystko się zepsuło, pozostawia te ważne rozróżnienia nieokreślone.
Jeśli cały komputer wielokrotnie się restartuje lub wyłącza, przerwij wielokrotne wywoływanie tego stanu jako test gry. Zachowaj już posiadane informacje i szukaj odpowiedniego wsparcia systemowego lub urządzeniowego, a także zgłoś kontekst gry. Restart nie jest zwykłym problemem z liczbą klatek na sekundę, a ten artykuł nie powinien być używany w miejsce oceny sprzętowej.
Zapisz ostatnią normalną akcję
Zapisz, co robiłeś tuż przed porażką. Dodaj nazwę komory lub pokoju, czy ładowałeś ją, otwierałeś menu, przesuwałeś się lub wykonywałeś konkretną interakcję z zagadką, oraz mniej więcej jak długo trwała sesja. Przybliżony czas trwania jest przydatny, gdy jest wyraźnie oznaczony jako przybliżony.
Unikaj przedwczesnego zamieniania ostatniej akcji w przyczynę. Awaria po wejściu do pomieszczenia nie dowodzi, że to pomieszczenie go spowodowało. Niemniej jednak ten moment daje programiście punkt wyjścia. Najmocniejszy raport opisuje tę sekwencję jasno i pozostawia pole do zbadania, zamiast wskazywać wadę silnika czy wyciek pamięci bez dowodów.
Jeśli awaria zdarzyła się więcej niż raz, porównaj wydarzenia. Czy były w tej samej scenie, po podobnym czasie lub podczas różnych aktywności? Podaj liczbę faktycznie obserwowanych zdarzeń. Nie pisz zawsze, jeśli zdarzyło się to dwa razy w warunkach, których nie porównałeś w pełni.
Zachowaj użyteczny kontekst
Zapisz sklep, demo lub pełny wpis gry, system operacyjny, urządzenie graficzne, procesor, pamięć oraz wszelkie lokalne informacje o budowie udostępniane przez klienta. Te szczegóły pomagają programiście dopasować raport do środowiska. Jeśli pole jest nieznane, pozostaw je nieznane, dopóki nie będziesz mógł sprawdzić, zamiast zgadywać na podstawie marki komputera.
Dołącz preset graficzny oraz wszelkie istotne wartości ustawień, które zmieniłeś. Raport sporządzony po eksperymentach powinien wskazywać, która konfiguracja była aktywna w chwili awarii. W przeciwnym razie wsparcie może interpretować Twoje obecne ustawienia jako te, które wywołały pierwotne zdarzenie, nawet jeśli się różnią.
Zachowaj krótką oś czasu, jeśli wykonasz kilka testów. Może pokazać, że pierwsza awaria miała miejsce na jednym ustawieniu, potem zaktualizowałeś grę, a kolejna próba zachowywała się inaczej. Kolejność ma znaczenie, bo pokazuje, które zmiany poprzedzały jakie obserwacje. Lista wszystkich ustawień, które kiedykolwiek próbowałeś, nie daje tych samych informacji.
Użyj Przekaż opinię (Give Feedback) po uruchomieniu gry
Jeśli możesz dotrzeć do gry i jej opcji zwrotnej, skorzystaj z trasy wskazanej przez wydawcę. Wyjaśnij typ awarii, ostatnią normalną akcję i środowisko. Wydawca mówi, że ścieżka feedbacku wysyła logi, które mogą pomóc. Nie zakładaj, że same logi wyjaśniają twoje intencje lub dokładny moment, w którym zauważyłeś problem.
Dołącz adres kontaktowy, jeśli chcesz uzyskać dalszą informację, jak prosiło w odpowiedzi wsparcia. Utrzymuj raport skupiony na problemie i unikaj dodawania niezwiązanych z tym danych osobowych. Przydatny kontakt pomaga programistowi poprosić o konkretną dodatkową obserwację bez konieczności publikowania jej w publicznej dyskusji.
Jeśli problemem jest powtarzalna pauza, a nie awaria, osobny wątek wydajności prosi o informację zwrotną podczas opóźnień. W przypadku awarii, która już zamknęła grę, wyjaśnij ten moment przy ponownym otwarciu. Nie twierdz, że dołączono konkretny wcześniejszy log, chyba że interfejs feedbacku lub deweloper tego potwierdzi.
Jeśli gra nie może dotrzeć do swojego menu
com, aby wyjaśnić, że ścieżka raportowania w grze jest niedostępna. Oznacz, czy gra nie działa przed pojawieniem się okna, podczas ładowania lub po dotarciu do ekranu tytułowego. Te etapy są bardziej użyteczne niż pojedyncza fraza nie zostanie uruchomiona.
Zacznij od zwięzłego raportu i informacji, które możesz zweryfikować. Nie dołączaj wszystkich plików z instalacji ani nie wysyłaj dużej kopii niezwiązanych ze sobą danych systemowych. Czekaj na prośbę o konkretne dodatkowe materiały, gdy potrzebne pliki lub ścieżki nie są udokumentowane. Źródła z badań nie ustanawiają aktualnego dziennika detalicznego ani ścieżki zapisu do kopiowania tutaj.
Jeśli sklep pokazuje błąd, zachowaj ten komunikat oddzielnie od błędów gry. Problem z brakującym pobraniem lub klientem może wystąpić przed uruchomieniem procesu gry. Nazwanie warstwy, na której pojawia się awaria, pomaga uniknąć traktowania problemu instalacji sklepu jak awarii silnika logicznego.
Sprawdź dostępną aktualizację gry
Użyj normalnego mechanizmu aktualizacji w sklepie i pozwól, by oczekujące pobrania lub prace instalacyjne się zakończyły, zanim porównasz zachowanie. To ogólna praktyka wsparcia, a nie dowód, że dana aktualizacja He Who Watches naprawia awarię. Zanotuj, czy aktualizacja była dostępna i czy objaw się zmienił później.
Nie zakładaj, że najnowsze ogłoszenie opisuje każdą lokalną zmianę w buildzie i nie wymyślaj numeru wersji od daty. Jeśli klient ujawni identyfikator, użyj go. W przeciwnym razie podaj datę aktualizacji i sklep, który faktycznie widzisz. Dokładne, niepełne informacje są lepsze niż etykieta, której wsparcie nie jest w stanie dopasować.
Aktualizacja, która zmienia zagadki lub tekst menu, nie powinna być reklamowana jako naprawa na awarię, chyba że programista tak zatwierdzi lub starannie opisana obserwacja potwierdza węższy wynik na Twoim komputerze. Oddziel kwestię świeżości instalacji od tego, czy problem został rozwiązany.
Spróbuj Low tylko jako kontrolowane porównanie
Sugestia dewelopera dotycząca niskiej grafiki to rozsądny, mały test, czy gra pozostaje wystarczająco stabilna do użycia. Zanotuj poprzednie ustawienie, wybierz Low i wróć do zwykłej gry lub krótkiej porównywalnej sceny. Zarejestruj, czy pierwotny objaw powraca. Nie wymuszaj wielokrotnego restartu systemu tylko po to, by porównać presety.
Jeśli Low pomaga, opisz wynik jako lokalne obejście w obserwowanych warunkach. Nie musisz wnioskować, czy mgła, obciążenie, ciepło czy inny czynnik to wyjaśnia. Programista może wykorzystać tę zmianę zachowania bez podawania spekulacyjnej diagnozy sprzętowej.
Jeśli Low nie pomaga, to również przydatna informacja. Dołącz ją do raportu wraz z typem awarii i czasem zaliczenia. Negatywny test nie oznacza, że sugestia dewelopera była nierozsądna; oznacza to, że Twój przypadek potrzebuje więcej dowodów. Unikaj przechodzenia przez wiele niezwiązanych ustawień po tym, jak pierwsze porównanie zakończyło się niepowodzeniem.
Weryfikuj Steam pliki, gdy objaw pasuje
Valve dokumentuje weryfikację plików w sekcji Właściwości i Zainstalowane pliki biblioteki Steam. Może to być odpowiednie dla brakujących lub uszkodzonych plików zainstalowanych. Jest to ogólne Steam rozwiązywanie problemów, a nie udowodniona poprawka zgłoszonego problemu z restartem tej gry. Korzystaj z interfejsu klienta zamiast ręcznie usuwać zawartość instalacji.
Pozwól, by weryfikacja się zakończyła i zanotuj, co zgłasza klient. Jeśli pliki zostaną ponownie pozyskane, zapisz ten fakt, nie zakładając, że to on dowodzi na przyczynę awarii. Następnie porównaj oryginalny objaw przy normalnym uruchomieniu. Jeśli nic się nie zmieni, uwzględnij ten wynik w notatkach wsparcia zamiast powtarzać weryfikację w nieskończoność.
Nie myl weryfikacji instalacji z potwierdzeniem postępów w rozwiązywaniu zagadki. Nie ustanawia rozwiązania pokoju ani nie dowodzi, że stary przewodnik powinien pasować do nowego układu. Trzymaj test powiązany z objawami technicznymi, takimi jak brakujące pliki czy niepowodzenia przy uruchamianiu, jeśli ma on jasny cel.
Unikaj destrukcyjnych zgadywań
Dostępne odpowiedzi deweloperów nie nakazują użytkownikom usuwania zapisów, usuwania folderów konfiguracyjnych, edytowania rejestru ani używania nieudokumentowanych poleceń uruchamiania. Nie rób, by te działania były domyślną odpowiedzią na niepewną awarię. Mogą one usunąć użyteczny stan lub spowodować drugi problem bez wyjaśnienia pierwszego.
Podobnie, nie wyłączaj zabezpieczeń systemowych ani nie pobieraj zewnętrznych naprawiaczy tylko dlatego, że wynik wyszukiwania obiecuje uniwersalne rozwiązanie. Korzystaj z kanałów wsparcia gry, sklepu i urządzenia istotnych dla zaobserwowanej awarii. Wąska, zweryfikowana instrukcja jest bardziej przydatna niż dramatyczna procedura bez wyraźnego związku z objawem.
Jeśli wsparcie później zażąda konkretnego pliku lub zmiany, należy prowadzić zapis instrukcji i zachować odpowiednie dane. Nie chodzi o unikanie każdej zmiany. Chodzi o wprowadzenie zmian z określonego powodu i zachowanie wystarczającego kontekstu, by ocenić, czy pomogły.
Zrób mały, znaczący przykład
Jeśli awaria może być obserwowana bez wywoływania niebezpiecznego lub zakłócającego zdarzenia systemowego, krótkie nagranie lub zrzut ekranu może wyjaśnić raport. Pokaż komunikat o błędzie lub działanie bezpośrednio poprzedzające problem. Wyjaśnij, co widz powinien zauważyć. Długa sesja bez adnotacji może ukryć odpowiedni moment.
Trzymaj prywatne treści desktopowe z dala od przechwytywania i oznaczaj materiały z późnej fazy gry podczas publicznego udostępniania. Często możesz pokazać techniczne zachowanie, nie ujawniając całej tajnej trasy. Jeśli sama scena jest spoilerem, powiedz to przed zdjęciem lub filmem, zamiast umieszczać odpowiedź w tytule.
Nie twierdz, że reprodukcja jest minimalna, chyba że faktycznie ją zawęziłeś. Można powiedzieć, że zaobserwowałeś awarię po kilku działaniach i nie wiesz, co jest ważne. Ta szczerość uniemożliwia wsparciu założenie, że pojedyncze widoczne wejście jest kompletnym wyzwalaczem.
Zapisz osobno oczekiwane i rzeczywiste zachowanie
Oczekiwane zachowanie opisuje to, co myślałeś, że powinno się wydarzyć: pokój powinien się załadować, menu zamknąć lub gra powinna pozostać otwarta po zwykłym ruchu. Rzeczywiste zachowanie opisuje widoczną porażkę. Trzymanie ich osobno sprawia, że raport jest zrozumiały, nawet jeśli deweloper nie podziela twojej interpretacji stanu zagadki.
Gdy oczekiwanie pochodzi z przewodnika, dołącz link i datę. Niezgodność ze starym układem pokoju może być problemem wersji, a nie awarią. Jeśli oczekiwanie dotyczy podstawowego zachowania aplikacji, powiedz to wprost. Nie ma potrzeby dekorować prostego raportu techniczną terminologią, której nie możesz uzasadnić.
Dodaj to, co próbowałeś i wynik każdego kroku. Zaktualizowana gra, nadal zamyka się przy ładowaniu, jest przydatna. Próbowałem wszystkiego nie. Zwięzła lista prawdziwych testów oszczędza czas, pokazując, które oczywiste porównania są już zakończone, a które pozostają nieprzetestowane.
Uzupełnienie nowych dowodów
Jeśli deweloper poprosi o konkretny test lub log, odpowiedz na to żądanie bezpośrednio. Zachowaj oryginalne odniesienie do raportu, aby nowe informacje pozostały powiązane z tym samym problemem. Rozpoczynanie kilku niepowiązanych wątków może podzielić kontekst i utrudnić dostrzeżenie, jak zmieniało się zachowanie w czasie.
Jeśli problem ustaje po zmianie, zgłoś to, co się zmieniło i jak długo lub w jakich warunkach testowałeś od tamtej pory. Unikaj deklarowania uniwersalnej poprawki po jednym udanym uruchomieniu. Węższe stwierdzenie, że gra ukończyła kilka normalnych sesji na niskim poziomie, jest zarówno użyteczne, jak i uczciwe, jeśli to zaobserwowałeś.
Jeśli problem powraca, zaktualizuj tę samą relację o nowe warunki. Ponowne wystąpienie nie wymazuje wcześniejszej poprawy; dodaje informacje o jej ograniczeniach. To rozróżnienie może pomóc wsparciu w identyfikacji, czy zmiana zmniejszyła częstotliwość, wpłynęła tylko na jedną scenę, czy była bez znaczenia.
Zdecyduj, kiedy zakończyć testowanie
Gdy masz już jasny opis awarii, podstawowe informacje o środowisku i wyniki kilku odpowiednich sprawdzeń, wyślij raport. Nie musisz samodzielnie diagnozować gry przed zgłoszeniem problemu do wsparcia. Dalsze testy są wartościowe tylko wtedy, gdy odpowiadają na konkretne, pozostające pytanie lub wynikają z odpowiedniej instrukcji.
Jeśli sam komputer jest niestabilny, priorytetowo zajmij się tym szerszym problemem i unikaj powtarzanych uruchomień gry, które go wywołują. Jeśli sama gra się zamyka, ale system nadal jest użyteczny, zachowaj raport i poczekaj na ukierunkowany kolejny krok, zamiast wielokrotnie reinstalować grę. Odpowiedź powinna odpowiadać rzeczywistej awarii.
Dobry raport to mały kawałek dowodu: co się stało, gdzie, w jakiej konfiguracji i co się zmieniło, gdy wykonałeś udokumentowany krok. To wystarczy, aby rozpocząć produktywne dochodzenie, unikając spekulacji, bez związanych modyfikacji i niepotrzebnych zmian w plikach.
Zamień niejasny raport w raport możliwy do działania
Raport stwierdzający, że gra czasami się zawiesza, pozostawia kilka istotnych pytań bez odpowiedzi. Możesz go poprawić bez technicznej spekulacji, dodając typ awarii, etap gry, przybliżoną częstotliwość i ostatnią normalną akcję. Na przykład, odróżnij powrót na pulpit w trakcie ładowania od restartu całego systemu po długiej sesji. To są wzorce raportów, a nie zdarzenia mające miejsce na Twoim komputerze.
Następnie dodaj środowisko i mały zestaw sprawdzeń, które faktycznie wykonałeś. Podaj, czy używałeś pełnej wersji gry czy dema, która platforma ją dostarczyła i jaki był aktywny preset graficzny. Jeśli wykonałeś weryfikację Low lub Steam, podaj wynik każdej oddzielnie. Nie pisz, że wszystkie poprawki zawiodły, jeśli wykonałeś tylko jedno sprawdzenie.
Wyjaśnij, czy zachowanie jest powtarzalne w znanej sekwencji, czy po prostu ponownie występuje w czasie. Powtarzalna awaria daje wsparciu sekwencję do próby. Powracająca awaria wciąż ma znaczenie, ale jej wyzwalacz pozostaje niepewny. Oznaczenie różnicy pomaga deweloperowi zdecydować, czy poprosić o powtórzenie, logi lub więcej informacji o sesji.
Jeśli dostępny jest komunikat o błędzie, zachowaj jego dokładne brzmienie zamiast przerabiać je na przyczynę. Nieznany kod może być bardziej pomocny dla wsparcia niż pewne podsumowanie, że oznacza problem z grafiką. Jeśli nie uchwyciłeś komunikatu, powiedz o tym i opisz, co pamiętasz, bez wymyślania brakujących szczegółów.
Zakończ opisanie obecnego stanu. Czy możesz teraz uruchomić grę? Czy problem pozostaje po udokumentowanym porównaniu ustawień? Czy trasa zgłaszania przez grę jest dostępna? Te odpowiedzi informują wsparcie, jaki następny krok naprawdę możesz wykonać. Prośba o przesłanie zgłoszenia z menu nie jest przydatna, jeśli Twój raport już wyjaśnia, że menu nigdy się nie pojawia.
Utrzymuj oryginalny raport i późniejsze uzupełnienia połączone ze sobą. Gdy pojawi się nowe obserwacja, dodaj ją wraz z datą i warunkami, zamiast przepisywać przeszłość, jakbyś od początku znał przyczynę. Zachowuje to użyteczną sekwencję śledztwa: objaw, sprawdzenie, wynik i następne pytanie. Ułatwia to także późniejszą, rzetelną ocenę skutecznej zmiany.
Ulepszony raport nie musi być długi. Musi ujawniać fakty, które czasem były ukryte w słowach. Jasny zakres i kilka zaobserwowanych detali może zaoszczędzić więcej czasu niż strona zgadywanych wyjaśnień silnika i dają deweloperowi solidną podstawę do żądania kolejnego dowodu.