Tłumaczenie wspomagane maszynowo; nazwy przedmiotów z gry mogą pozostać w języku angielskim.
Przygotuj zwięzłe zgłoszenie z wersją gry, krótką instrukcją odtworzenia i czytelnymi zrzutami. Odróżnij błędy od uwag o balansie.
Zacznij od jednego problemu
Przydatny raport błędu opisuje pojedynczą porażkę na tyle jasno, że inna osoba może ją spróbować. Zacznij od akcji i rezultatu: na przykład otwarcie konkretnego menu ukrywa kursor, albo ładowanie sesji umieszcza postać poniżej podłogi. Unikaj zaczynania od kilku akapitów o całej grze. Osoba czytająca musi wiedzieć, co odtworzyć.
Oddziel błąd techniczny od preferencji. Przycisk, który nic nie robi, cel, który nie przesuwa się do przodu, oraz wskaźnik przetrwania, który wydaje się zbyt wymagający, to różne rodzaje informacji zwrotnej. Wszystkie mogą być warte zgłoszenia, ale wymagają innych dowodów. Skarga dotycząca balansu powinna wyjaśniać, jakiego doświadczenia chcesz; zgłoszenie błędu powinno wyjaśnić oczekiwane zachowanie i to, co się wydarzyło zamiast tego.
Wybierz miejsce docelowe raportu przez warstwę awariczną
Zadanie gry, problem z zakupem launchera oraz awaria instalacji sterownika graficznego wymagają różnych zespołów wsparcia. Opisz warstwę, która zawodzi, zanim wybierzesz miejsce docelowe. Jeśli gra działa, ale cel nie przechodzi do przodu, zacznij od kanału raportowania dewelopera. Jeśli sklep nie może zakończyć pobrania, zacznij od wsparcia platformy.
W przypadku podejrzenia problemu ze sterownikiem graficznym producent sprzętu może wymagać osobnego raportu. AMD udostępnia narzędzie Zgłaszania błędów, które zbiera szczegóły systemu oraz akceptuje kroki i dołączenia. To narzędzie przesyła informacje do AMD; nie zastępuje poinformowania twórcy gry o problemie z zadaniem lub sesją zapisaną. Używaj go, gdy dowody lub wskazówki wskazują na warstwę graficzną lub systemową.
Unikaj publikowania identycznych dużych raportów wszędzie bez kontekstu. Jeśli zaangażowane są dwa zespoły wsparcia, wyjaśnij dlaczego i zachowaj ich osobne identyfikatory spraw w prywatności. Zwięzłe porównanie może zapobiec duplikowaniu się prac, podczas gdy publiczne wyrzucenie każdego maila i załącznika może ujawnić informacje, nie pomagając nikomu zrozumieć technicznej granicy.
Zbuduj tytuł, który można znaleźć później
Dobry tytuł łączy widoczny objaw z wyzwalaczem. Na przykład „kursor menu znika po podłączeniu akcesorium lotu” jest łatwiejszy do rozpoznania niż „proszę naprawić grę”. Podawaj wersję tylko wtedy, gdy została zweryfikowana. Nie wstawiaj nieprzetestowanej teorii w tytuł tak, jakby była ustalonym faktem.
W raporcie zadania używaj widocznego celu lub nazwy obiektu i zaznacz niepowodzenie. Unikaj spoilerów w tytule, jeśli kanał raportowy pozwala na flagę spoilera lub bardziej neutralny opis. Możesz podać niezbędne szczegóły postępu w treści dla osób badających problem.
Wyszukaj kluczowe terminy przed opublikowaniem. Jeśli znajdziesz istniejący raport pasujący do tego samego wyzwalacza, porównaj jego wersję i rezultat. Dodaj tam swoje dowody, jeśli to odpowiednie, zamiast tworzyć kolejny niemal identyczny wątek. Jeśli reprodukcja różni się zasadniczo, wyjaśnij tę różnicę. Podobne objawy mogą mieć różne przyczyny, więc nie łącz automatycznie niepowiązanych raportów ani nie upieraj się, że każde nowe spostrzeżenie wymaga zupełnie osobnej dyskusji.
Napisz oczekiwany i faktyczny wynik jako parę.
Oczekiwany wynik powinien pochodzić z instrukcji interfejsu, normalnego wcześniejszego zachowania lub jasnej zasady gry, a nie jedynie z tego, czego byś chciał. Jeśli nie jesteś pewny, czy zachowanie jest zamierzone, sformułuj raport jako pytanie i wyjaśnij niejasność. Pozwala to na doprecyzowanie bez osłabiania użyteczności Twojej obserwacji.
Faktyczny wynik powinien opisywać, co pojawia się na ekranie lub jakie wejścia pozostają możliwe. Tekst celu pozostaje niezmieniony po tej interakcji, co jest bardziej użyteczne niż „misja jest całkowicie zepsuta”. Jeśli nadal możesz się poruszać, otwierać menu lub wczytać inną sesję, uwzględnij te informacje; odróżnia to blokadę postępu od zawieszenia aplikacji.
Trzymaj parę wyników razem w raporcie. Czytelnik nie powinien musieć odtwarzać oczekiwanej akcji z kilku akapitów historii. Następnie podaj kroki reprodukcji, a potem opcjonalny kontekst. Taki porządek ułatwia skanowanie raportu i pozwala badaczowi przetestować główne stwierdzenie przed rozważeniem mniej pewnych szczegółów.
Rozróżnij reprodukcję od dziennika trasy
Dziennik trasy zapisuje wszystko, co zrobiłeś. Reprodukcja zawiera najmniejszą sekwencję potrzebną do wywołania problemu. Zacznij od dziennika, jeśli to wszystko, co masz, a następnie zidentyfikuj, które kroki są zdecydowanie wymagane, być może istotne lub po prostu miały miejsce wcześniej. Nie wymazuj niepewnego kontekstu; przenieś go do osobnej notatki.
Jeśli testowanie jest bezpieczne, zmień jeden podejrzany wymóg wstępny. Na przykład porównaj interakcję przed i po podłączeniu opcjonalnego akcesorium lub porównaj jedną sesję dotkniętą z inną istniejącą. Nie zaczynaj nowej kampanii ani nie poświęcaj cennego postępu tylko po to, by uzyskać czystszy raport. Stan zapisany może być lepszym punktem wyjścia niż powtarzanie godzin działań.
Bądź wyraźny, gdy twoje odtwarzanie zależy od konkretnej sesji, której nie możesz dalej ograniczać. Badacz może potrzebować tej sesji, a nie dłuższej pisemnej trasy. Zachowaj ją, opisz natychmiastowe kroki po załadowaniu i udostępnij prywatnie na żądanie. Dzięki temu raport jest praktyczny nawet wtedy, gdy podstawowy wyzwalacz wystąpił znacznie wcześniej niż widoczna awaria.
Częstotliwość raportów bez przesadnej pewności
Korzystaj z obserwacji, które możesz policzyć lub opisać. Problem, który wystąpił przy dwóch kolejnych ładunkach, jest bardziej widoczny niż zawsze podczas awarii. Problem pojawił się raz po długiej sesji, która jest wyraźniejsza niż losowe awarie za każdym razem. Nie potrzebujesz dużej próbki, by przesłać użyteczny raport, ale musisz podać, co faktycznie zaobserwowałeś.
Jeśli późniejsza próba się powiedzie, dodaj ten wynik. Zachowanie przerywane to cenna informacja, zwłaszcza gdy różni się w zależności od sesji, lokalizacji lub podłączonego urządzenia. Nie ukrywaj udanej próby, bo obawiasz się, że sprawi, iż oryginalny problem stanie się mniej wiarygodny. Celem jest pomóc zidentyfikować warunki, a nie wygrać spor o to, czy gra jest dobra.
Gdy inny gracz zgłasza inny wynik, porównaj kontekst, zamiast traktować go jako sprzeczność. Może mieć inny build, trasę, ustawienia wejściowe lub stan zapisu. Poproś o odpowiednie szczegóły i trzymaj swój raport konkretnym. Niezgoda między dwoma udokumentowanymi ustawieniami może być użytecznym tropem; wymiana uniwersalnych roszczeń rzadko tak jest.
Przygotuj zrzuty ekranu i nagrania z określonym celem
Steam dokumentuje swoją funkcję zrzutów ekranu oraz wymóg nakładki dla tej funkcji. Jeśli twój skonfigurowany sposób przechwytywania działa, użyj go, aby pokazać odpowiedni błąd lub interfejs. Niepowodzenie przechwytywania to osobny problem; nadal możesz opisać objaw lub użyć innej standardowej metody przechwytywania dostępnej na Twoim komputerze.
Przed nagrywaniem zdecyduj, co widz potrzebuje zobaczyć: stan początkowy, sekwencję wprowadzeń i wynik. Krótki klip zawierający te elementy jest łatwiejszy do sprawdzenia niż kilka minut niezwiązanej rozgrywki. Jeśli błąd znika szybko, nagranie może pomóc zachować jego dokładne sformułowanie bez wielokrotnych ryzykownych prób.
Sprawdź plik przed jego udostępnieniem. Upewnij się, że tekst jest czytelny i że dowody faktycznie pokazują zgłoszony problem. Usuń niezwiązane prywatne treści pulpitu z udostępnionej kopii, zachowując oryginał, jeśli wsparcie będzie później potrzebować kontekstu. Nie dodawaj edycji, które zniekształcają kolejność działań lub sprawiają, że oddzielne próby wyglądają na ciągłe. Jasne dowody powinny zmniejszać niepewność, a nie tworzyć bardziej przekonującą, lecz wprowadzającą w błąd historię.
Używaj załączników i diagnostyki oszczędnie
Więcej danych nie oznacza automatycznie lepiej. Zacznij od informacji odpowiadających problemowi: szczegóły urządzenia dla wejścia, tryb wyświetlania dla rozdzielczości, cel i sesja dla postępu. Jeśli wsparcie poprosi o logi lub eksport diagnostyczny, dostarcz wymagany materiał i oznacz czas zdarzenia. Unikaj przesyłania całego folderu użytkownika jako skrótu.
Narzędzie raportowania AMD oferuje lokalną kopię przesłanych informacji oraz pole historii sterowników. Te funkcje przedstawiają przydatne nawyki nawet poza tym narzędziem: zachowaj własny raport i zanotuj, czy problem pojawił się dopiero po zmianie oprogramowania. Ten artykuł nie twierdzi, że każdy awaria wymaga raportu AMD ani że narzędzie może diagnozować sprzęt nie-AMD.
W przypadku jakiegokolwiek prywatnego załącznika, sprawdź kanał odbioru i uprawnienia dostępu. Udostępniaj tylko zamierzonemu odbiorcy wsparcia i unikaj publicznych linków, gdy plik może zawierać dane osobowe. Zachowaj oryginalne dowody niezmienione i wyślij kopię. Jeśli zespół wsparcia zażąda innego formatu, zanotuj to żądanie, aby móc odróżnić ich wymóg diagnostyczny od dowolnego obejścia znalezionego gdzie indziej.
Kontynuuj z wynikiem, nie tylko kolejną skargą
Gdy wsparcie zasugeruje test, podaj wersję początkową, wykonany krok i wynik. Jeśli objaw się zmieni, opisz jak. Dotarcie do menu, ale nadal niezaładowanie, to inny wynik niż niepowodzenie przed otwarciem okna. Te rozróżnienia pozwalają badaczowi zdecydować, czy kolejne pytanie należy do tej samej ścieżki niepowodzenia.
Jeśli aktualizacja rozwiąże problem, podaj którą aktualizację i jak sprawdziłeś. Jeśli problem pozostaje, zapewnij minimalne powtórzenie w nowej wersji zamiast przepisywać całą historię. Zachowaj wcześniejsze dowody, aby można było porównać zmianę.
Jeśli nie masz już sesji, którą dotyczysz, lub nie możesz powtórzyć problemu, podaj to ograniczenie. Nie tworz czystej kopii, aby utrzymać raport aktywny. Prawdziwa notatka końcowa pomaga przyszłym czytelnikom zrozumieć, ile zostało zweryfikowane. Pozwala także zachować zaufanie do użytecznych informacji, które już podałeś, nawet gdy śledztwo zakończy się bez jednoznacznego wyjaśnienia pierwotnego zdarzenia.
Zapisz najmniejszą, wiarygodną sekwencję
Zapisz warunek początkowy, a następnie akcje w kolejności. Uwzględnij tylko kroki, które mają znaczenie dla niepowodzenia. Jeśli nie wiesz, czy wcześniejsze zdarzenie ma znaczenie, umieść je w krótkiej uwadze kontekstowej zamiast ukrywać odtworzenie w pełnym opisie sesji gry.
Spróbuj sekwencji ponownie tylko wtedy, gdy nie narazisz się na ważny postęp. Jeśli zdarzy się to dwa razy z tego samego stanu, powiedz to. Jeśli zdarzyło się to raz i nie możesz tego odtworzyć, powiedz to zamiast tego. Uczciwy, jednorazowy raport jest bardziej przydatny niż pewne twierdzenie, że każdy gracz napotka ten sam problem.
Dołącz build, sklep i istotne informacje o urządzeniu. W przypadku problemu z wejściem nazw kontroler i inne dołączone akcesoria. W przypadku problemu z wyświetlaniem zapisz wybraną rozdzielczość i to, co faktycznie wyświetla gra. W przypadku zadania podaj widoczny cel oraz interakcję, która nie pomogła go posunąć dalej.
Sprawdź, czy nie ma odpowiedniej notatki deweloperskiej
Przeczytaj ostatnie oficjalne ogłoszenia przed złożeniem duplikatu raportu. Znana poprawka może zaoszczędzić czas, jeśli instalacja jest opóźniona, a znany problem może już mieć wymagany format diagnostyczny. Jeśli problem pozostanie po odpowiedniej aktualizacji, wyraźnie o tym wspomnij i opisz ponowny test.
Notatki z 4 września kierują graczy doświadczających zapisów z przechodzenia przez świat do info@breathedge.com. Zachowaj dotkniętą sesję i udostępnij ją prywatnie na żądanie. W przypadku innych objawów sprawdź oficjalne centrum dyskusyjne pod kątem odpowiednich aktualnych instrukcji; kontakt dla jednego zgłoszonego problemu nie zastępuje wszystkich innych ścieżek wsparcia.
Dołącz dowody odpowiadające na pytanie
Zrzut ekranu powinien wyraźnie pokazać odpowiedni interfejs lub błąd. Krótkie nagranie powinno zacząć się wystarczająco wcześnie, by pokazać działanie wyzwalające i zatrzymać się, gdy pojawi się wynik. Nie potrzebuje też całego pulpitu, strony konta ani niepowiązanej rozmowy. Przejrzyj załącznik przed jego opublikowaniem.
Zachowaj oryginalny plik podczas przygotowywania przyciętego obrazu. Jeśli wsparcie będzie potrzebować więcej kontekstu, możesz go podać bez próby odtwarzania problemu. W logach i archiwach przeglądaj zawartość i udostępniaj tylko to, o co proszono. Nigdy nie umieszczaj haseł, plików uwierzytelniających ani niepowiązanych osobistych folderów w raporcie publicznym.
Gdy opisujesz błąd, zachowaj jego dokładny tekst. Gdy opisujesz teorię, oznacz ją jako teorię. Stwierdzenie, że problem zaczął się po podłączeniu kontrolera, jest obserwacją; twierdzenie, że sterownik kontrolera na pewno uszkodził zapis, to twierdzenie przyczynowe, które wymaga znacznie silniejszych dowodów.
Zamknij pętlę po odpowiedzi
Jeśli wymagany krok działa, zgłoś wynik i wybraną wersję. Jeśli nie, podaj, co się zmieniło, a co pozostało bez zmienienia. Pozwala to programiście odróżnić częściową poprawę od braku efektu i pomaga innym czytelnikom uniknąć powtarzania nieudanej ścieżki.
Utrzymuj komentarze uzupełniające w tej samej dyskusji, gdy to możliwe. Zakładanie nowego wątku przy każdej próbie oddziela dowody i utrudnia zrozumienie historii. Krótka ostatnia notatka wskazująca działającą aktualizację lub pozostałą reprodukcję jest cenna dla kolejnego gracza, który szuka tego samego objawu.
Zachowaj ostateczną kopię tytułu raportu, daty i testowanej wersji w swoich notatkach. Jeśli ten sam objaw powróci po kilku miesiącach, ten zapis pozwala opisać go jako możliwy nawrót z znaną historią, zamiast zaczynać od mglistej pamięci. Podlinkuj wcześniejszą dyskusję i wyjaśnij, co zostało nowo zaobserwowane.
Jeśli odkryjesz, że Twój raport używał niewłaściwej wersji gry, popraw to wprost. Pozostawienie starego twierdzenia bez kwalifikacji może wprowadzać graczy w błąd, którzy później szukają w tej wersji znanych problemów.
Źródła i weryfikacja
Ten artykuł łączy cytowane fakty z praktycznymi poradami redakcyjnymi. Przed zastosowaniem starszej trasy sprawdź wersję i uwagi dotyczące niepewności.
